Re: latency.c and delay related questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 21 Jun 2006, Christophe Osuna wrote:

> (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

Exactly. Well explained.

> 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?

Yes, this buffering schema is also possible, but note that the time window 
for the data copy must satisfy the system scheduler requirements and 
capabilities to get continous playback. In the "stream linked" case this 
time window is exactly one period time.

						Jaroslav

-----
Jaroslav Kysela <perex@xxxxxxx>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-devel

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux