22 Sep
2009
22 Sep
'09
2:56 p.m.
Hi Clemens,
Thanks for taking a shot at this problem. I have a few questions
about the description:
on 1) When you say the output buffer is full, it is full of flatline
(dc/blank/etc), right?
on 2) At this point, the input data is read and is in the first period
(that is, it's not visible to the program yet)?
on 3) At this point, the input data is visible to the software and
immediately copied to the first output period, right? I don't
understand why the output buffer is still partially full. Since the
inputs and outputs are in synch, wouldn't the output be playing out
that flatline as the inputs receive data? Are you saying that the
input and output period boundaries don't necessarily line up?
In the recorded data, there is a silent gap of two
periods between each
two periods containing data; this is the same behaviour that you see.
I'm not hearing any audible gapping.. is this what you mean? I
believe with both devices blocking that this may happen.
To reduce the latency, you would have to keep the
output buffer more
empty. In my test program, try removing one of the writei calls before
the snd_pcm_start.
But since the input and output are synched and in my solution not
blocking on input, wouldn't adding writei just cause a buffer overrun
in the input while it writes out blank buffers? I'm not clear on how
this actually adds latency. I was under the impression that was a
function of buffer size.
Cheers,
Louis
1) At the start of the loop, the output buffer is
full, and the input
buffer contains one period of recorded data. Let's assume that the
output buffer contains two periods of silence and that the input data
contains a signal whose latency you want to measure.
2) The input data period is read and processed.
3) The data is written to the output buffer, but since the buffer is
(partially) full, this writing waits while the data of one period in
the buffer is still being played. This is one period of silence.
At the same time, one period is recorded.
4) In the next loop cycle, one period is read and written. During this
time, the second period of silence is played.
5) In the next loop cycle, one period is read and written. During this
time, the period containing the recorded signal is played.
So, between the end of the period where we recorded the signal and the
beginning of the period where the signal was played, there is an
interval of two periods, i.e., the overall latency is three periods.
This is caused be the algorithm; when we want to write one period of
data at the end of step 2) above, we still have (almost) two periods of
not-yet-played data in the buffer.
To reduce the latency, you would have to keep the output buffer more
empty. In my test program, try removing one of the writei calls before
the snd_pcm_start.
Best regards,
Clemens
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev