Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
LPC: Linux audio: it's a mess
Posted Sep 19, 2008 11:38 UTC (Fri) by ewan (subscriber, #5533)
Posted Sep 19, 2008 21:22 UTC (Fri) by rahvin (subscriber, #16953)
Posted Sep 20, 2008 3:41 UTC (Sat) by drag (subscriber, #31333)
Say your using something like xmms or other application that has it's own volume control.
So you have the Gnome volume control stuff. It's the icon in your task bar and the mixer control stuff in your applications menu. This provides a 'sanatized' way to interact with volume controls. So you can have that nice little icon and the sound mixer buttons on your multimedia keyboard and whatnot.
Then you have the low-level Alsamixer interface. This reflects the actual hardware capabilities of your sound card. When your mucking around with the PCM slider your interacting with the sound card's hardware. It's confusing to use and each sound card has different capabilities so it's a UI that will change depending on what sound card you have.
Then you have your 3rd mixer interface at the application level.
Then on top of that people using desktops will have another volume control on their speakers. So that makes 4 different volume controls that interact with the sound card. Different applications will go through the Gnome stuff, interact with alsamixer directly, or have their own controls. Depending on how the application is configured it can interact with controls differently at different times. (ie, some apps can be configured to use OSS vs Alsa vs ESD vs artsd vs etc)
This is confusing.
Now say your trying to do a voice recording or interact with a VoIP application. Things get _very_ confusing.
With PA you have the master controls and the application controls in the same spot. Then that eliminates the requirements for mixing controls in your browser, file manager, your terminal's beeping, etc etc.
So this _should_ lower the mixing controls down to 2 on the software side. Alsa stuff should setup correctly, but it won't be for the significant number of people. So you still need alsamixer for getting the "baseline" set. But after that you should only need to deal with one interface.
It's still very goofy, but not as goofy.
Posted Sep 22, 2008 2:11 UTC (Mon) by elanthis (guest, #6227)
Sometimes you want the same thing in multiple places to help usability.
Where you might think to look first isn't where someone else might look
first. It's pretty clear that some people are going to try to adjust the
sound volume on the thing making the sound (the individual app) and not the
mixer control on the panel.
However, PA is what makes that possible. Note that I said "the same thing"
in multiple places. The volume widget in the app should modify the volume
of the PA stream, and be reflected in the desktop mixer utility, and vice
versa. Without things like PA, this becomes much harder. It's not even
possible without a lot of crap being shoved into the drivers.
Posted Sep 22, 2008 16:55 UTC (Mon) by drag (subscriber, #31333)
Not when those multiple things do very different and conflicting actions in very very non-obvious manners.
If you have:
1. Mozilla Browser volume control and mute.
2. Gnome Volume Control and mute (that ties into your volume icon and multimedia buttons)
4. Low-level Alsa volume control and mute.
5. Speaker volume control and power.
Now you open up a youtube video. You get no audio.
Tell me, with certainty, which control, or combinations of controls, you will have to use to make the sound audible.
There is a difference between having 3-5 different places to control volume vs having 3-5 different controls you have to use.
Posted Sep 20, 2008 11:27 UTC (Sat) by dirtyepic (subscriber, #30178)
Posted Sep 21, 2008 22:10 UTC (Sun) by mezcalero (subscriber, #45103)
One of the biggest problems in volume control we have right now is that we have too many volume controls in line. The app might have one, the device has a couple, the hardware might have even more. It is very confusing to the user to find his way through this jungle and figure out which one is the one that is responsible for the low volume of the output.
The fix for this is to coalesce all those volume controls at a single place which should naturally be the sound server. If applications then want to expose a volume control slider they should expose the one maintained by the sound server -- instead that everyone implements its own.
With the "flat volumes" feature of upcoming PA 0.9.13 we even will be able to coalesce per-stream and per-device volume into one.
In summary: requesting that each app should implement its own volume controls goes in the wrong direction. Bad idea. Right in contrary exporting vol control to the sound server is the right answer here.
Posted Sep 21, 2008 23:23 UTC (Sun) by PaulWay (✭ supporter ✭, #45600)
The real point here is that having every application (hopefully) implement a volume control (and hopefully do it well), and having it in a different location for each application, is a usability nightmare. Having one set of centralised controls smooths over a multitude of minor sins.
Posted Sep 22, 2008 10:07 UTC (Mon) by hppnq (guest, #14462)
It is very confusing to the user to find his way through this
jungle and figure out which one is the one that is responsible for the low
volume of the output.
Considering that this argument is more or less the same as the one in
favour of per-app volume controls, one would be inclined to think of a
protocol as a solution for this kind of confusion. But it seems like this
has already been patented. Sigh.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds