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