Constraints and hw_params with highly configurable HW

Constraints and hw_params with highly configurable HW

[Uli Franke]

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

Re: Constraints and hw_params with highly configurable HW

[Clemens Ladisch]

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

Re: Constraints and hw_params with highly configurable HW

[Uli Franke]

> 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. And you will never
be able to pre-fetch this information reliably as the DICE firmware is
allowed to change its setup arbitrarily.

> (If the settings can be controlled by software, they should by locked
> as long as some PCM device is open.)

This is obvious and is implemented like this.

But you have to keep in mind that there are other things which can not
be locked. For instance the locking: If a device is synchronized to an
external clock source, this clock source can disappear or be
reconfigured at any time. How the device behaves in such situations
depends strongly on the firmware. For example some devices provide
autolocking which scans for lockable clocks in all frequency ranges.
Others simply switch to internal clock. In all those situations its very
likely that the stream layout will change. Even the clock caps can
change at any time.

>> 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.

Of course the driver should not set constraints which will never be
supported. We're discussing the constraints which can not be determined
without knowing some actual parameters.

As far as I can deduce from the call sequence the constraints are just a
convenient way to let the user space open fail before .hw_params is
actually called and free the programmer from the burden to formulate
those similar and recurring checks over and over again in case the
device constraints are static.

If the device reveals certain constraints only when some parameters are
actually set and if the parameters are only known at .hw_param time, the
constraint system must be bypassable. I don't see any drawback from this
for other parts of the system. It only shows that the ALSA API simply
can not abstract all devices perfectly. But that's OK and normal in real
world applications. The important thing is that the user space
application can assume equivalent behavior in either case. That's what's
we're heading for.

Again: If I should miss something: I'm curious to learn about it.

> 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. 

Yes, but the "current state of the device" is not valid until you set
the actual parameters which are not known at .open time.

> 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?)

If the user flicks a switch while the software is playing the driver
will get a notification and should take the appropriate measures to
handle the new setup in case it changed. The driver already has been
adapted to do so. For instance
 * react on locking events: pausing the PCM substreams in case the lock
    is lost
 * react on isochronous stream reconfiguration events: continue
    streaming when isochronous layout is compatible, kill streaming
    if not

>> would EINVAL an appropriate error code to return?
Great.

Regards
Uli

Re: Constraints and hw_params with highly configurable HW

[Clemens Ladisch]

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