[alsa-devel] External samplerate changes, UAC2 clock topologies
daniel at caiaq.de
Wed Jun 9 11:16:28 CEST 2010
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
> 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
More information about the Alsa-devel