25 Feb
2014
25 Feb
'14
1:54 a.m.
On Mon, Feb 24, 2014 at 6:19 PM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;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).