Uli Franke wrote:
Then the constraints should be read from the device in the PCM open callback.
No, that's not possible as the constraints will/can change in case you request a different sample rate for instance. Therefore the constraints won't be known until you set the rate for instance.
The PCM constraints can represent arbitrary dependencies between the parameters, as long as they are known to the driver.
For example, one dependency (already handled by the ALSA framework) is between buffer size (length in frames) (A), buffer time (length in seconds) (B), and sample rate (C), with A = B * C. If any of these parameters changes, the allowed range of the other two is adjusted. For example, if a device allows sample rates between 48 kHz and 96 kHz (but none has yet been chosen), and if the buffer time is set to 0.5 s, then the interval for the buffer length is set to 24000...48000 frames.
My dice driver assumes that the number of channels depends only on the sample rate (and that only 48/96/192 kHz matter). The function dice_rate_constraint() is called when the number of channels in the snd_pcm_hw_params structure changes, and adjusts the allowed sample rates accordingly; the function dice_channels_constraint() is called when the sample rate changes, and adjusts the allowed number of channels accordingly.
And you will never be able to pre-fetch this information reliably as the DICE firmware is allowed to change its setup arbitrarily.
A generic DICE driver does not know what some arbitrary firmwares does, but for Weiss devices, you know the rules, don't you?
Regards, Clemens