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@lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>
>
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Tue Sep 22 20:15:09 2009
This archive was generated by hypermail 2.1.8 : Tue Sep 22 2009 - 20:15:09 EEST