(I apologize for the previous message with HTML - I am a new gmail
user and was expecting it not to send HTML for a basic text message. I
have disabled text formatting - hope it works now.)
Thanks for your help. The linking of capture and playback devices
explains everything; if I remove linking and use snd_pcm_start() on
the playback device I get the expected behaviour.
Here is a little drawing (requires fixed font) to illustrate what you
have said and what I have understood (useless for you but some people
like me might find it useful).
When capture and playback devices are linked, the following happens:
+-------------------------
Capture | C0 | C1 | C2 | C3 | ...
+-------------------------
+-------------------------
Playback | -- | -- | C0 | C1 | ...
+-------------------------
Capture and playback start simultaneously and so playback device needs
something to play. When the first capture is finished, another is
started. We would like to play the captured audio, but another
playback has already started. Only after the latter is finished can
the captured audio be played.
This explains why the playback device needs two buffers of silence.
The total delay is hw_delay + 2 * period
When the devices are not linked, we can start the playback device
after the first buffer has been captured:
+-------------------------
Capture | C0 | C1 | C2 | C3 | ...
+-------------------------
+-----------------
Playback | C0 | C1 | C2 | .
+-----------------
Starting the playback device and copying data takes some time, so the
total delay becomes hw_delay + 1 * period + start_delay + copy_delay.
For large periods, with period > start_delay + copy_delay, this can
lead to a lower latency, but who would use large periods for low
latency?
Thanks again for your help.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel
