Re: Constraints and hw_params with highly configurable HW

[Clemens Ladisch <clemens@ladisch.de>]

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