I think you'll find it's a bit more complicated than that
Posted May 12, 2012 11:12 UTC (Sat) by tialaramex (subscriber, #21167)
[Link]
Although this was traditionally hardware (or perhaps some firmware burned permanently onto a ROM somewhere) on modern hardware it is more often software. There are a mind-boggling variety of possible ways to have things work, and as usual in the PC industry and in embedded systems the manufacturers have chosen "all of the above" occasionally even on a model by model basis.
So there may or may not be multiple outputs, it may or may not be possible to drive more than one at once, and they may or may not be physically capable of being driven at different levels (ie independent volume controls), and each may or may not have, require or support a separate PCM stream, and the physical hardware ports used may or may not be re-used between configurations including more than two speakers ("home cinema") microphone or line in.
The ALSA drivers may, or may not, enable some or all of these features on specific hardware depending on whether somebody got the hardware reference sheets for the chipset and for the specific implementation (a lot of these chips have a handful of GPIO pins whose purpose of course the PC makers feel free to change on a whim) and then PulseAudio may or may not make use of the features exposed by ALSA.
I think that ALSA has in some cases done the work of switching amplifiers on and off automatically on jack detection, but this work on PulseAudio means that PA will notice the jack insertion too, so that my desktop volume settings (which I currently must turn up when using speakers and then quickly turn down if I plug in headphones) might some day soon Just Work⢠remembering how they were set when I last had things plugged in this way.
Another cute thing you can do in userspace is demonstrated by Android (and most similar phone software, but Android is Linux-based and I happen to have an Android handset to verify this). When you unplug the headphones from a device, it may make sense to pause playback rather than move the sound to speakers.
I think you'll find it's a bit more complicated than that
Posted May 13, 2012 0:03 UTC (Sun) by drag (subscriber, #31333)
[Link]
Yes Android is aware of your audio I/O and will try to react accordingly. When you turn off your bluetooth headset or unplug your wired headset it will try to stop the music. Depends on the app...
Another nice thing it does, of course, is when you receive a phone call it mutes all audio output and pauses music if possible. Then it will resume once you hang up.
It's not perfect. Not all applications honor the stop/start commands you can issue through bluetooth devices, or plugged-in headsets. Sometimes android will start up music after I hang up a phone call even though I didn't have music playing before the phone call. Sometimes when you issue start/stop events the default music player will grab those rather then the app that is actually making audio at the time. Just odd things like that every once and a while.
But for the most part it works.
I think you'll find it's a bit more complicated than that
Posted May 13, 2012 6:24 UTC (Sun) by alankila (subscriber, #47141)
[Link]
Yeah, this is entirely up to the application afaik. You can write a program that still continues playing music in the background while the user receives a phonecall. (I know this because this is currently a bug in one music player I have written, haven't bothered to fix it though.) There's nothing that *android* specifically does about it, I'm afraid.