On Mon, Feb 24, 2014 at 6:19 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:

The problem I guess is due to the way the HW related params
are set:

1. Allocate a hw_params struct
2. Fill in the params using set_*** functions
3. Submit the hw_params struct.

In step 2, the set_*** functions are aware of the acceptable
ranges/values and will report error if anything is not possible.
The backend code sets the sample rate before anything related
to channel counts is set or tested. So if the ALSA code still
reports that 8 channels are available after the sample rate
is set to 48 kHz, that looks to me like a bug in the driver.

No, this is based on a misconception.

The legal ALSA driver parameters form a sparse multi-dimensional space. The driver knows the legal intervals along each dimensional axis, but it does not know the shape of the intersecting space.

Thus the only way to find out if a given combination of parameters is legal is to try to set them and see if the hardware accepts them.

I only know the RME Hammerfall driver well, but in that case, where the channel count changes depending on whether you do <88.2kHz or >= 88.2kHz, there is no way that the driver can tell you that your attempt to use too many channels is wrong until you submit the entire h/w params struct.

The HW itself is not set up before step 3, so it is probably
still set to 44.1 kHz while the hw_params is filled in, and it
reports 8 channels.

No. The driver just gives you some values based on a possible (or maybe even most likely) scenario. The driver does not know the number of channels in a definitive way. This is partly an ALSA API issue and partly a h/w issue - in some cases, you just don't know (or it is very fiddly and complex to find out - e.g. is there a daughterboard present that increases the channel count in some cases).