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 > call? 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? *sigh* 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. Regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
