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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
