Uli Franke wrote:
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.
Then the constraints should be read from the device in the PCM open callback.
(If the settings can be controlled by software, they should by locked as long as some PCM device is open.)
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.
It wouldn't be a nice thing to do for the driver to set constraints that it already _knows_ it will not be able to support.
In the most common case, the hw_param callback happens immediately after the open callback, so it makes sense for .open to set constraints that reflect the current state of the device. It is still possible for the device state to change between .open and .hw_params, but that's the best the driver can do.
(What happens if the user flicks a switch while the software is playing?)
would EINVAL an appropriate error code to return?
Yes.
Regards, Clemens