On Sun, Aug 12, 2012 at 1:23 AM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: >> This is not correct. If the app has proper PA support (such as all KDE >> apps, and probably all gnome apps), then PA does the app specific >> mixing, not the app itself. > > That doesn't stop the app from having its own internal volume > control that PA doesn't know about. That would not be "proper" PA support. An app can do all sorts of stupid stuff of course. >> Moreover, if only one app is playing sound >> then PA does no mixing at all, but passes it all directly to ALSA (and >> sets ALSA's controls of course). > > If that is true it is completely wrong from the start. Because > that setup can't be maintained when a second app starts playing > which can happen at any time. Suppose that first (single) app has > its volume set to some low value, and PA uses the soundcard PCM > gain control to achieve that as you claim it does. Now suddenly > there's a second app which wants a higher level. The only way to > achieve that is to raise the hardware gain - you can't compensate > for a low setting there by sending a louder signal, it would just > clip. So PA now has to adjust the hardware gain and at the same > time start scaling down the output from the first app. > It's impossible to do that in any acceptable way. That's how it works. I have not noticed any problems. How would the problems manifest themselves? I'm not an audio expert by any stretch of the imagination, but I think even I would be able to notice skipping, clipping, noise, ... What should I be listening for? > Simple fact is that most soundcards, even if they have a 'mixer', > can't mix PCM signals (i.e. signals from the software) - they can > mix in a CD player, or an external mic input etc.). So for anything > coming from the system there is just one path, which has two controls, > the 'PCM' and the 'master'. The only way to correctly use them if > there if there is software mixing is to set them once to their > correct values (which may depend on what is connected externally), > and them leave them alone and do the rest in software. So that's apparently not how it is done in PA. Why must it be done in this way? How can I verify that there is a problem? > And then we haven't even touched the matter of different sample > rates. It is correct that PA does not (cannot) change the sample rate on the fly. You have to pick one and stick to it (so if you pick the "wrong" one it will resample). > 'A lot of meta-information' LOL. It will provide some usually > meaningless and inconsistent names of controls, their min and > max values, and if you're extremely lucky maybe some indication > mapping control values to dB, which may or may not be correct > (and if it isn't that's not ALSA's fault, it just crappy and > undocumented harware). All of that is visible in alsamixer. Yes, this is exactly what PA uses. ALAS just displays it without using it. > Yes, absolutely. It may take the user some time to understand the > quirks of his soundcard (such as that it's not capable of outputting > full digital level without distortion, no matter how the controls > are set, or even crappier shortcomings). But he will usually find a > way to get things working. Which is impossible without hearing the > result. Maybe PA has some magic powers to do that. It seems to me that PA is much better than this than what I am. I used to struggle with getting my laptop to output the exact volume I wanted without clipping, but now PA does its magic and it just works. I won't claim to know everything about this topic, but I'm interested in hearing more about why you claim that what PA does is impossible. -t
