At Thu, 7 May 2009 14:46:51 +0200, Lennart Poettering wrote:
On Thu, 07.05.09 10:49, Takashi Iwai (tiwai@suse.de) wrote:
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.
Breaks compatibility with what exactly? OSS?
Yes, and old ALSA-native apps without PA.
We have now disabled the OSS compat stuff in F11 now, so I am not too concerned about this. Also, not sure if it would be a big loss if surround sound is only configurable with native ALSA, not OSS.
True, but the question is rather ALSA-native apps and tests with old hardwares.
Can I assume that 'Master' and 'Front' are always independant?
No.
May I assume that they always are dependant?
If both exist, then they should be dependent, and Master should be really Master. If Front doesn't exist but only Master, the surrounds could be independent from master.
Or can't I assume anything about the relation between Master and Front? That would suck.
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.
Hmm. Maybe it's time to get rid of this now? As mentioned in Fedora we now disabled OSS and didn't get any complaints about that. I mean, it might be worth keeping compat for OSS PCM, but for the OSS mixer?
Surround sound with OSS is not really workable anyway, so I wouldn't be too concerned to break it.
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.
Hmm, could you be more explicit which apps you think would break? I mean, the ALSA mixer API always allowed multichannel audio, however no driver actually made use of that. If a client is using the ALSA mixer API properly it should not break. And if it doesn't use it properly it's not ALSA's fault...
kmix surely won't work. GNOME mixer? I don't think it would. Many media players (new and old) support a mixer adjustment more or less, and certainly many of they won't work with multi channels.
Yes, they are (a kind of) broken. But, they work now. If they won't work after the change, it's called regression...
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 certainly agree with this. But this doesn't appear to be anything that will happen any time soon, or will it?
If we could agree to fix the surround sound situation within the current API as far as it allows that I'd be a much happier man.
And I'd be likely an unhappier man who is responsible to fix regressions :)
So, in my perspective, it's much desirable to create another mixer API from the scratch. Or, at least, we should add a switch to keep / change the behavior of the current mixer API.
We must be really careful about playing the API changes and silent behavior changes. An addition would be OK, but a change needs a lot care (no matter what politician said)...
thanks,
Takashi