Dennis,

> This description is very perplexing to me...
>
> A usleep() before the snd_pcm_drain() implies that the OS is
> [doing] something BEFORE you invoke the snd_pcm_drain()
> call.

I would hope so !   :-)

> So focusing on that call is a red-herring

Why do you think so ?    Because there is already sound before the
snd_pcm_drain() is called ?   That doesn't seem strange to me, as I assume
it notices its internal buffer being totally filled up, and thus starts to
play that.

> It indicates, to me, that some call before the usleep() needs
> to be investigated.

I've posted the link to the code I've used, so please do tell which one you
think is involved, as I'm at the end of my rope here (remember that I
removed the reading from stdin and changed the bitrate to 8000).   FWI, the
last-called function before snd_pcm_drain() is snd_pcm_writei().

I've also just tried to make the buffer (much) larger and smaller (ofcourse
adjusting the loopcount too), but the sound kept playing for just a second
...

> Something like an asynchronous buffering operation which is returning
> before the entire buffer has been transferred, and your subsequent
> operations are interrupting/terminating the remaining transfer.

To me it feels like the internal ALSA buffer goes empty (due to task
switching ?), causing the snd_pcm_drain() function to end the sound output
and return - ignoring/discarding the rest of the data that is still waiting
to be played.

> https://github.com/raspberrypi/linux/issues/999

Found that one too.   But as it uses an usleep() where none should be
present and no explanation is given (that I can see) I skipped it.

>
https://stackoverflow.com/questions/18034132/alsa-snd-pcm-drainhandle-the-strea
m-isnt-played-to-the-end

Also found that one, and tried what happened when I included the
"snd_pcm_nonblock(handle, 0)" call.  Alas, nothing changed.

Found a few others too, but no explanation or solution in sight.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05