Joerg-Cyril.Hoehle@t-systems.com wrote:
Clemens Ladisch wrote:
[...] GetPosition returns "the stream position of the sample that is currently playing through the speakers".
However, does that documentation actually make a distinction between the last sample that has been read from the buffer and the sample being played?
Er, what do you mean?
Er, that I didn't read the documentation. After Googling, I see that your interpretation is correct.
BTW, I thought dmix could be used with any card, but I found no one-liner syntax to open card 1 with dmix. It seemed hard-wired (by configuration) to card0 (not that I'm familiar with ALSA conf syntax).
Device names can have parameters; you can use "dmix:x" or "dmix:CARD=x" or "dmix:{ CARD=x; }" or whatever other syntax is allowed by ALSA's configuration system. And yes, it's mostly undocumented.
Configuring the device to stop on xruns seems to be a better fit for your requirements.
That's what Wine used to do in the former driver.
But it's precisely because dmix does(did?) not support xrun detection that I started looking into the free-running mode.
Any device _must_ stop on xrun, if so configured. Not doing so would be a bug. Could you still reproduce it now?
The meaning of ALSA's periods is as follows: 2) When ALSA is blocked (in snd_pcm_write* or in poll), it checks whether to wake up the application only when an interrupt arrives.
What about non-blocking mode? Do you mean to imply that in non-blocking mode, never using poll() causes period_size to become irrelevant from the app POV?
Yes. Recently, the possibility to disable interrupts (period_wakeup) was added to a few drivers; PulseAudio uses this. http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.h...
The new driver doesn't use poll at all. It uses a fixed rate timer signal. Is that against any recommendations? What's bad about it?
Well, that duplicates PulseAudio's code. ;-)
Regards, Clemens