[alsa-devel] alsa-lib: snd_pcm_delay and friends do not account for a write being currently in progress
clemens at ladisch.de
Thu Jun 3 19:03:28 CEST 2010
John Lindgren wrote:
> I understand that snd_pcm_delay and snd_pcm_writei currently "interfere
> with each other" in that snd_pcm_delay returns wrong values if called
> during snd_pcm_writei. That is the problem my patch tries to correct.
These values are not wrong; the problem is that your program does not
have enough information to interpret it correctly.
> Do you have a problem with patches that improve the current situation?
A blocking write call is an abstraction on top of the underlying
non-blocking writes. Using a blocking write implies that your program
wants to write the entire block and does not care about how the timing
of the chunks that are actually written.
I do not consider it an improvement if a patch adds complexity, if the
same functionality is already available. Non-blocking mode was designed
for the case where you want to know the actual amount of data at every
point in time.
> > > Would it work to simply call snd_pcm_wait?
> > Yes. (I usually suggest poll because the code that writes audio data
> > often wants to be informed of some other event. If your writing loop
> > doesn't need to be interrupted, snd_pcm_wait works just fine.)
> It is permissible, then, to call snd_pcm_delay during a snd_pcm_wait
It will work in practice (snd_pcm_wait is just a wrapper around poll).
> What would be the cleanest way to interrupt snd_pcm_wait when we need to
> stop the stream? Will snd_pcm_drop work?
This will _not_ work.
You have to use poll so that you can send your loop a message (through
a pipe/eventfd/whatever) that tells it to stop.
More information about the Alsa-devel