Subject: RE: [linux-audio-dev] Random thought on HDR latency compensation
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Tue Apr 25 2000 - 11:55:26 EEST
Yep, I meant "load" in the sense of "read audio from disk." Apologies for lack of clarity.
Interesting use of the term "event latency." Useful.
-- Richard
-----Original Message-----
From: Paul Barton-Davis [SMTP:pbd_AT_Op.Net]
Sent: Tuesday, April 25, 2000 2:20 AM
To: linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: Re: [linux-audio-dev] Random thought on HDR latency compensation
>3 & 4) [Advanced apologies if I've missed the point and am being
>particularly patronising.] This is where the elaborate debates on
>multithreading begin - while the current frame [T,T+D) is being played by
>the DSP on your audio card, another thread will be running the plugins
>required to produce the next frame [T+D,T+2D) - and one (or more) further
>thread(s) will be asking the kernel to load the frame of data [T+2D,T+3D)
>after this! [In practice D may vary and more than three frames may be
>"pipelined" at once.]
Actually, depending on what you mean by "load", this might be unlikely
in a real-time system. If all you mean is "retrieve existing data
corresponding to frame [T+ND,T+(N+1)D], then sure. In ardour, for
example, we are typically fetching up to *250* frames ahead from the
disk.
However, if you are describing the actual generation/processing of
[...]
This archive was generated by hypermail 2b28 : Tue Apr 25 2000 - 12:51:08 EEST