At Wed, 6 May 2009 19:58:24 +0200, Lennart Poettering wrote:
Heya!
Some cards expose 'Master' volume sliders. Others expose seperate (stereo) sliders for 'Front', 'Rear' and so on. I have trouble dealing with them properly in PulseAudio:
First of all, on some cards 'Master' seems not to have any effect on the actual analog output, only 'Front' and friends do. Is this a bug or intended behaviour?
It's an old feature. AC97 spec gives the "master" volume control only for front channels. Thus, old boards with AC97 may inherit this policy. (The problem of emu10k1 is partly this.)
Fixing it isn't too difficult with vmaster stuff in the driver side, but this breaks the compatibility, and hard to find the real test machines nowadays. In short, "don't touch a working system unless it gets broken" phase.
Can I assume that 'Master' and 'Front' are always independant?
No.
Secondly, I have trouble supporting the 'Front'/'Rear'/'Side'/... elements properly, since they split up the surround channels into seperate elements. Now, this is confusing in many ways, even for "amixer" which will then show channels such as "Rear Front Left" and so on, which obviously make no sense. snd_mixer_selem_has_playback_channel() just returns bogus data for these cases. Why are those elements seperate anyway? Why aren't they combined into a single multi-channel event?
That's mainly a historical reason. In old days, there are no mixer apps supporting really multiple channels because the behavior of OSS. A stereo pair is easier to handle for apps.
Looking at the APIs I get the idea that the problem appears to be that elements can only control all channels the same are all independantly which doesn't really match 1:1 on my multichannel sound cards. However, wouldn't it be possible to use the 'index' value of a selem_id for this? I.e. have a series of controls by the same name but different indexes which would then implement snd_mixer_selem_has_playback_channel() correctly? i.e. foo,0 would do front-left/right, foo,1 would do rear, foo,2 would do lfe, and so? I have no clue how this implemented internally, so not sure how feasible this might be.
This breaks the existing apps. That's the biggest problem we face now. We can't change the stuff simply because PA isn't the only app using that API.
IMO, the best would be a total rewrite of the current mixer API, as I mentioned some times. Right now it's more complicated than needed, but not powerful enough to handle exceptional cases.
I know designing a generic and fully-working API is pretty difficult, though...
thanks,
Takashi