On 05/07/2015 12:41 PM, Russell King - ARM Linux wrote: [...] >>> What I'm concerned about is that when the ALSA parameter refining >>> starts, we start with (eg) 2-8 channels, 32-192kHz. Given that, >>> if we invoke the channel restriction before the rate restriction, >>> we would end up limiting to 2 channel at 32-192kHz. If we apply >>> the restrictions in the opposite order, we'd restrict to 6 >>> channel, 32-48kHz. Neither are obviously correct in this >>> circumstance, and I don't really see a way to solve it given my >>> understanding of the way ALSA's parameter refinement works. >>> >>> I suspect this is why most HDMI drivers are implemented such that >>> they take the maximum capabilities over all SADs, which would end >>> up restricting audio in the above case to: up to 6 channels, at >>> 32, 44.1, 48, 96 and 192kHz, even though 6 channel @ 192kHz isn't >>> hasn't been indicated as supported. >>> >>> Most of this is speculation though, based off what is in the >>> documentation. As I say, I don't have enough real-world examples >>> to get a feel for what manufacturers _actually_ do to give a hint >>> as to how the documentation should be interpreted. > > ... so this is probably less than speculation. > > So, ALSA gurus, how do we handle this? How do we arrange the parameter > resolution such that ALSA can permit _either_ 2 channels at 192kHz or 6 > channels at 48kHz, but not 6 channels at 192kHz? Right now, I don't > see how that's possible.
That's pretty straight forward and can be done using custom rules linking the number of channels to the sample rate. Have a look at snd_ac97_pcm_double_rate_rules() this is pretty much the same constraint. - Lars