[alsa-devel] 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