Hi everybody
We're currently working on some neat enhancements for the still experimental snd_dice driver originally initiated by Clemens Ladisch. To list some of the new and already working features: * firmware loading, backed by a user-space command line utility * generic ALSA control support for mostly all device specific settings for all our (i.e. Weiss Engineering) DICE based products and last but not least * capture support * slave mode (external clock source support).
I'm currently debugging and fine-tuning things and that's where some questions arose. The initial implementation of Clemens tried to fetch all possible configurations of a device during probe in order to have all combinations of rates and channels at hand when it comes to formulate the constraints set within the ALSA pcm substream open callback. That's a nice approach but will fail with a lot of devices as their configurations can (and mostly will) be volatile. Our devices for instance feature several switches, options and alike which have heavy influence on the channel layout and sample rates and combination of both.
I consulted Takashi's documentation on constraints which suggests to "use the source" but I couldn't find any similar situation within other drivers (in case I should have missed something, just let me know of course).
Therefore I had the idea to define some maximum constraints and let the ALSA hw_params callback fail in case some settings or combinations are determined to be not supported during its invocation.
Is this viable? Could this be/is this consistent with the specs? If yes, would EINVAL an appropriate error code to return?
Regards Uli