External samplerate changes, UAC2 clock topologies

External samplerate changes, UAC2 clock topologies

[Daniel Mack]

Hi,

when I implemented the basics for parsing the UAC2 clock functions, I
came across some principal questions I would like to discuss.

As I wrote in the commit log, UAC2 supports a number of clock units
which can be combined to complex topologies. The single unit types are

 - clock sources (can be fixed, variable, programmable and synced to the
   USB clock)
 - clock switches, which let the host decide which one out of many input
   pins appears on its output pin
 - clock multipliers, which have a numerator and a denominator, and both
   can be read-only or read-write, respectively

A clock source has controls for its frequency and its validity,
a clock selector has a control to control its current state, and
a clock multiplier has controls for its numerator and denominator

The driver is currently able to walk the graph of connected units in
order to find CLOCK_SOURCE descriptors as end-leafs. This is mandatory
as all requests for sample rate queries have to be sent to this unit
type.

This raises the first question, as the driver can only know which sample
rates are supported in the currently selected combination of selectors.
Once the user changes any of them (which is currently already possible
as clock selectors are exported as mixer controls), everything can
change. And this can even happen while the stream is active, because
there's currently no check about whether the clock selector is part of
the actively used path.

The second issue I see is that a clock can lose its validity. A
real-life example is an external S/PDIF connected device which provides
a clock and which is suddenly disconnected. Firmwares are expected to
notify the host about such cases, and these messages are trivial to
dispatch. However, I wonder how the driver should react on this. From
a user's perspective, it would be best to just make the driver find
another clock path which reports a valid clock source endpoint, changes
the sample rate accordingly and continues streaming. There would be
a gap in the stream of course, but at least it would not kill the
applications or require major exception handling in userspace.

I wonder which approaches are actually possible to implement, which
details in the ALSA core would need to be extended, and so on.

Any oppinions? Has this been done before for any other audio hardware
supported by ALSA?

Thanks,
Daniel

Re: External samplerate changes, UAC2 clock topologies

[Jaroslav Kysela]

On Fri, 4 Jun 2010, Daniel Mack wrote:

> Hi,
>
> when I implemented the basics for parsing the UAC2 clock functions, I
> came across some principal questions I would like to discuss.
>
> As I wrote in the commit log, UAC2 supports a number of clock units
> which can be combined to complex topologies. The single unit types are
>
> - clock sources (can be fixed, variable, programmable and synced to the
>   USB clock)
> - clock switches, which let the host decide which one out of many input
>   pins appears on its output pin
> - clock multipliers, which have a numerator and a denominator, and both
>   can be read-only or read-write, respectively
>
> A clock source has controls for its frequency and its validity,
> a clock selector has a control to control its current state, and
> a clock multiplier has controls for its numerator and denominator
>
> The driver is currently able to walk the graph of connected units in
> order to find CLOCK_SOURCE descriptors as end-leafs. This is mandatory
> as all requests for sample rate queries have to be sent to this unit
> type.
>
> This raises the first question, as the driver can only know which sample
> rates are supported in the currently selected combination of selectors.
> Once the user changes any of them (which is currently already possible
> as clock selectors are exported as mixer controls), everything can
> change. And this can even happen while the stream is active, because
> there's currently no check about whether the clock selector is part of
> the actively used path.
>
> The second issue I see is that a clock can lose its validity. A
> real-life example is an external S/PDIF connected device which provides
> a clock and which is suddenly disconnected. Firmwares are expected to
> notify the host about such cases, and these messages are trivial to
> dispatch. However, I wonder how the driver should react on this. From
> a user's perspective, it would be best to just make the driver find
> another clock path which reports a valid clock source endpoint, changes
> the sample rate accordingly and continues streaming. There would be
> a gap in the stream of course, but at least it would not kill the
> applications or require major exception handling in userspace.

But what's better? Get a wrong stream or notify application that something 
went in a different way than settled in the parameter setup phase?

> I wonder which approaches are actually possible to implement, which
> details in the ALSA core would need to be extended, and so on.
>
> Any oppinions? Has this been done before for any other audio hardware
> supported by ALSA?

If a stream parameter changes, the driver should interrupt streaming 
immediatelly. The check should be in the trigger() callback (-EIO error 
code) and if the stream is already running - it should be put to the
SNDRV_PCM_STATE_DRAINING (capture) to let the application obtain the 
captured samples until the parameter change. Just call snd_pcm_stop() with 
the new state for the substream. For playback, the stream should be put 
to the SNDRV_PCM_STATE_OPEN state to wait to settle new parameters from 
an application (it means that all I/O ops will return -EBADFD).

I implemented this behaviour in pdaudiocf driver (sound/pcmcia/pdaudiocf) 
- for the capture direction.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: External samplerate changes, UAC2 clock topologies

[Daniel Mack]

Hi Jaroslav,

On Fri, Jun 04, 2010 at 09:49:36PM +0200, Jaroslav Kysela wrote:
> On Fri, 4 Jun 2010, Daniel Mack wrote:
> >The second issue I see is that a clock can lose its validity. A
> >real-life example is an external S/PDIF connected device which provides
> >a clock and which is suddenly disconnected. Firmwares are expected to
> >notify the host about such cases, and these messages are trivial to
> >dispatch. However, I wonder how the driver should react on this. From
> >a user's perspective, it would be best to just make the driver find
> >another clock path which reports a valid clock source endpoint, changes
> >the sample rate accordingly and continues streaming. There would be
> >a gap in the stream of course, but at least it would not kill the
> >applications or require major exception handling in userspace.
> 
> But what's better? Get a wrong stream or notify application that
> something went in a different way than settled in the parameter
> setup phase?

Well, frankly, I don't know enough about the implementation details of
the userspace part of ALSA. A 'wrong stream' is certainly unacceptable,
but is there a way to inform userspace applications about changed
parameters and maybe let libasound handle such things gracefully?

> >I wonder which approaches are actually possible to implement, which
> >details in the ALSA core would need to be extended, and so on.
> >
> >Any oppinions? Has this been done before for any other audio hardware
> >supported by ALSA?
> 
> If a stream parameter changes, the driver should interrupt streaming
> immediatelly. The check should be in the trigger() callback (-EIO
> error code) and if the stream is already running - it should be put
> to the
> SNDRV_PCM_STATE_DRAINING (capture) to let the application obtain the
> captured samples until the parameter change. Just call
> snd_pcm_stop() with the new state for the substream. For playback,
> the stream should be put to the SNDRV_PCM_STATE_OPEN state to wait
> to settle new parameters from an application (it means that all I/O
> ops will return -EBADFD).

Hmm. I implemented this now, but at least aplay won't stop when this
code path is triggered. Is there anything else I should do, except for
calling snd_pcm_stop()?

> I implemented this behaviour in pdaudiocf driver
> (sound/pcmcia/pdaudiocf) - for the capture direction.

I can't find the references here either. Can you point me to the code
maybe?

Thanks,
Daniel

Re: External samplerate changes, UAC2 clock topologies

[Daniel Mack]

On Wed, Jun 09, 2010 at 11:16:28AM +0200, Daniel Mack wrote:
> On Fri, Jun 04, 2010 at 09:49:36PM +0200, Jaroslav Kysela wrote:
> > If a stream parameter changes, the driver should interrupt streaming
> > immediatelly. The check should be in the trigger() callback (-EIO
> > error code) and if the stream is already running - it should be put
> > to the
> > SNDRV_PCM_STATE_DRAINING (capture) to let the application obtain the
> > captured samples until the parameter change. Just call
> > snd_pcm_stop() with the new state for the substream. For playback,
> > the stream should be put to the SNDRV_PCM_STATE_OPEN state to wait
> > to settle new parameters from an application (it means that all I/O
> > ops will return -EBADFD).
> 
> Hmm. I implemented this now, but at least aplay won't stop when this
> code path is triggered. Is there anything else I should do, except for
> calling snd_pcm_stop()?

Strange enough, aplay doesn't even quit when the device is unplugged.
Can anyone confirm this with an UAC1 device?

Daniel

Re: External samplerate changes, UAC2 clock topologies

[Clemens Ladisch]

Daniel Mack wrote:
> On Wed, Jun 09, 2010 at 11:16:28AM +0200, Daniel Mack wrote:
> > On Fri, Jun 04, 2010 at 09:49:36PM +0200, Jaroslav Kysela wrote:
> > > If a stream parameter changes, the driver should interrupt streaming
> > > immediatelly. The check should be in the trigger() callback (-EIO
> > > error code) and if the stream is already running - it should be put
> > > to the
> > > SNDRV_PCM_STATE_DRAINING (capture) to let the application obtain the
> > > captured samples until the parameter change. Just call
> > > snd_pcm_stop() with the new state for the substream. For playback,
> > > the stream should be put to the SNDRV_PCM_STATE_OPEN state to wait
> > > to settle new parameters from an application (it means that all I/O
> > > ops will return -EBADFD).
> > 
> > Hmm. I implemented this now, but at least aplay won't stop when this
> > code path is triggered. Is there anything else I should do, except for
> > calling snd_pcm_stop()?
> 
> Strange enough, aplay doesn't even quit when the device is unplugged.
> Can anyone confirm this with an UAC1 device?

Unplugging works just fine (i.e., stops).

When unpluggin, the stream should go into XRUN state.

I doublt if it is allowed to go from RUNNING to OPEN, because then the
driver's hw_free callback might not be called.


Regards,
Clemens

Re: External samplerate changes, UAC2 clock topologies

[Alex Lee]

Daniel Mack <daniel <at> caiaq.de> writes:

> 
> Hi,
> 
> when I implemented the basics for parsing the UAC2 clock functions, I
> came across some principal questions I would like to discuss.
> 
> As I wrote in the commit log, UAC2 supports a number of clock units
> which can be combined to complex topologies. The single unit types are
> 
>  - clock sources (can be fixed, variable, programmable and synced to the
>    USB clock)
>  - clock switches, which let the host decide which one out of many input
>    pins appears on its output pin
>  - clock multipliers, which have a numerator and a denominator, and both
>    can be read-only or read-write, respectively
> 
> A clock source has controls for its frequency and its validity,
> a clock selector has a control to control its current state, and
> a clock multiplier has controls for its numerator and denominator
> 
> The driver is currently able to walk the graph of connected units in
> order to find CLOCK_SOURCE descriptors as end-leafs. This is mandatory
> as all requests for sample rate queries have to be sent to this unit
> type.
> 
> This raises the first question, as the driver can only know which sample
> rates are supported in the currently selected combination of selectors.
> Once the user changes any of them (which is currently already possible
> as clock selectors are exported as mixer controls), everything can
> change. And this can even happen while the stream is active, because
> there's currently no check about whether the clock selector is part of
> the actively used path.
> 
> The second issue I see is that a clock can lose its validity. A
> real-life example is an external S/PDIF connected device which provides
> a clock and which is suddenly disconnected. Firmwares are expected to
> notify the host about such cases, and these messages are trivial to
> dispatch. However, I wonder how the driver should react on this. From
> a user's perspective, it would be best to just make the driver find
> another clock path which reports a valid clock source endpoint, changes
> the sample rate accordingly and continues streaming. There would be
> a gap in the stream of course, but at least it would not kill the
> applications or require major exception handling in userspace.
> 
> I wonder which approaches are actually possible to implement, which
> details in the ALSA core would need to be extended, and so on.
> 
> Any oppinions? Has this been done before for any other audio hardware
> supported by ALSA?
> 
> Thanks,
> Daniel
> 

Hi Daniel et al,

In Software Defined Radio (SDR) applications, the user and user programs expect
the audio stream to continue after a samplerate change.  The samplerate change
can be initiated by hardware (ie button pressed, SPDIF cable unplugged/plugged
etc.) or by another user program - eg mixer.

When the driver is notified of an external samplerate change, ideally it should
go through the UAC2 clock topology and figure out what has changed and what is
the current clock source, clock selector position, and clock multiplier being
used.  It may have to trace from the USB output terminal backwards.

I wonder whether there is a converse scenario, whereby a user program wants to
change the samplerate, and passes that request to the driver.  The driver then
have to go through the topology and figure out the 1st valid or the "best" way
to effect the new samplerate.  It can get quite involved as the same samplerate
can be implemented by different settings of the clock source(s), clock
selector(s) and clock multiplier(s) :-)  I suspect this happens when we do a 

> arecord -r 96000 ...

and the UAC2 driver will have to figure out how this should be supported.

Alex

Re: External samplerate changes, UAC2 clock topologies

[Mark Brown]

On Fri, Jun 04, 2010 at 02:46:35PM +0200, Daniel Mack wrote:

> Any oppinions? Has this been done before for any other audio hardware
> supported by ALSA?

ASoC has similar clocking schemes supported, though it relies on the
board for a lot of the decision making since there's an element of
policy about the use cases which may need to be handled that ASoC type
systems can be used.  The ideal thing is pretty much what you describe
where the driver handles things as transparently as possible to the
applications.