23 Sep
2009
23 Sep
'09
7:49 p.m.
On Thu, Sep 24, 2009 at 12:16:45AM +0300, Jussi Laako wrote:
Clemens Ladisch wrote:
More generally,
2) Set number of periods to N (N >= 2)
3) Write N periods of silence to output.
This is exactly what Jack's backend and clalsadrv are
doing. Both use mmapped access, and also wait on both
the read and write fd's (this may be overkill if both
streams are sync-started). Both also have some extra
code do cleanly recover and restart after an xrun.
IIRC the OP wanted to use read/write access. If ALSA
allows to call read() so it block until a period is
available that would work, in that case you can probably
write() without waiting, as the output stream _should_
be ready to accept a period if both streams were started
together.
Round-trip latency is N periods, plus some extra for
the HW.
Ciao,
--
FA
Io lo dico sempre: l'Italia รจ troppo stretta e lunga.
To decrease that output buffering latency, make
sure that there is less
valid data in the buffer when you are writing. This is initially
determined by the amount of data you put into the buffer before starting
streaming, and can be later adjusted with snd_pcm_forward/rewind().
How it should work on ALSA as well as OSS for low latency:
1) Set period size to something suitable
2) Set number of periods to 2
3) Write two periods of silence to output
3.5) Optionally trigger-start both input and output
4) Block on input until period available
5) Process the input
6) Write period to the output
By this time, first of originally written periods has been played and
second is playing, now the second half of the "double buffer" gets
filled. Input buffer doesn't ever have more than one period.