You may be right. However I think it might also be how most apps are written.
Disclaimer: I am no audio expert nor am I knowledgable enough in mobile OSs to confirm it but I did manage to build myself a ROM for my unsupported phone which led me to see a lot of things under the hood.
The way Android (AOSP) is made, and Im sure the same is true for iOS, easily accessible APIs are made available for devs to implement them without thinking much about how the OS on your phone will handle it. Multiple audio streams are definitely a thing on mobile OSs, for example if I want a Youtube video playing along side a phone call and music, I can. It’s just not practical if you’re an attention grabber company to let other audio streams interrupt the very important audio that they want you to listen to.
Anyway all in all, you’re right that mobile OSs are designed to only let one app access the audio channel because Google wants to keep you on Youtube, all their partners paying for their apps to get on Android want the same thing and I can imagine the same is done on iOS and other manufacturer’s OSs.
How do you mention you can play multiple audio streams at the same time and then claim the OS is designed to let only one app access an audio channel / device? Which one is it now? Let’s dig a bit deeper into this:
Also, let’s not blame everything on the OS vendor being malicious. In most cases, playing multiple audio streams simultaneously would be annoying. In android, you can absolutely play multiple sources simultaneously, and Android will mix everything together and play it.
That being said, starting with API level 31, Android actually started to enforce a concept called audio focus at the system level. That would be around Android version 12. Audio focus is basically a token that can be requested and handed from app to app, and only the app holding the token gets to talk, everything else is faded out.
I’ll agree that enforcing this and not making it configurable for the end user was a pretty dumb move, but that was simply a UX decision, not certainly malicious.
If your phone is rooted, you can work around it, e. g. via an xposed module.
It wasn’t clear, my bad. I meant to say that by design, on the stock OS, it wasnt meant to play multiple audio streams at once but that it was possible with some modifications either to the OS or in-app (by some ways that are beyond my knowledge).
Now that you mention it, I did see something about API level 31 some time ago and haven’t paid attention to it much. Thanks for the information.
True, I did jump into conclusion way too fast, I’ll be more careful.
My phone isn’t rooted but thanks. I have no real use for using multiple audio streams at the same times anyway. I just remembered being able to at one point, wanted to point it out and went overboard with my comment.
How do you mention you can play multiple audio streams at the same time and then claim the OS is designed to let only one app access an audio channel / device? Which one is it now?
Just because it’s designed that way doesn’t mean it works that way all the time.
Basically they’re saying it’s designed so that it’s easy for an app to override your current audio stream, but allows for it to run concurrently if they want.
As most app developers wouldn’t want that, they hijack the audio by default.
You may be right. However I think it might also be how most apps are written.
Disclaimer: I am no audio expert nor am I knowledgable enough in mobile OSs to confirm it but I did manage to build myself a ROM for my unsupported phone which led me to see a lot of things under the hood.
The way Android (AOSP) is made, and Im sure the same is true for iOS, easily accessible APIs are made available for devs to implement them without thinking much about how the OS on your phone will handle it. Multiple audio streams are definitely a thing on mobile OSs, for example if I want a Youtube video playing along side a phone call and music, I can. It’s just not practical if you’re an attention grabber company to let other audio streams interrupt the very important audio that they want you to listen to.
Anyway all in all, you’re right that mobile OSs are designed to only let one app access the audio channel because Google wants to keep you on Youtube, all their partners paying for their apps to get on Android want the same thing and I can imagine the same is done on iOS and other manufacturer’s OSs.
How do you mention you can play multiple audio streams at the same time and then claim the OS is designed to let only one app access an audio channel / device? Which one is it now? Let’s dig a bit deeper into this:
Also, let’s not blame everything on the OS vendor being malicious. In most cases, playing multiple audio streams simultaneously would be annoying. In android, you can absolutely play multiple sources simultaneously, and Android will mix everything together and play it.
That being said, starting with API level 31, Android actually started to enforce a concept called audio focus at the system level. That would be around Android version 12. Audio focus is basically a token that can be requested and handed from app to app, and only the app holding the token gets to talk, everything else is faded out.
I’ll agree that enforcing this and not making it configurable for the end user was a pretty dumb move, but that was simply a UX decision, not certainly malicious.
If your phone is rooted, you can work around it, e. g. via an xposed module.
It wasn’t clear, my bad. I meant to say that by design, on the stock OS, it wasnt meant to play multiple audio streams at once but that it was possible with some modifications either to the OS or in-app (by some ways that are beyond my knowledge).
Now that you mention it, I did see something about API level 31 some time ago and haven’t paid attention to it much. Thanks for the information.
True, I did jump into conclusion way too fast, I’ll be more careful.
My phone isn’t rooted but thanks. I have no real use for using multiple audio streams at the same times anyway. I just remembered being able to at one point, wanted to point it out and went overboard with my comment.
Just because it’s designed that way doesn’t mean it works that way all the time.
Basically they’re saying it’s designed so that it’s easy for an app to override your current audio stream, but allows for it to run concurrently if they want.
As most app developers wouldn’t want that, they hijack the audio by default.