Re: [LAD] timing the processing of queues between engine and ui threads?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Robillard <d@...>
Cc: <linux-audio-dev@...>
Date: Friday, November 4, 2011 - 1:33 am

--20cf3010ed576fedba04b0deaf14
Content-Type: text/plain; charset=ISO-8859-1

thanks Dave, that's what I was looking for! Have you used this technique
yourself? Do you have any suggestions on how that is done with non jack
systems? And any open source code that uses that technique?

thanks so much.
iain

On Thu, Nov 3, 2011 at 5:42 PM, David Robillard wrote:

> On Thu, 2011-11-03 at 16:29 -0700, Iain Duncan wrote:

--20cf3010ed576fedba04b0deaf14
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

thanks Dave, that's what I was looking for! Have you used this tec=
hnique yourself? Do you have any suggestions on how that is done with non j=
ack systems? And any open source code that uses that technique?
thanks so much.iainOn Thu, Nov 3, 2011 at 5:42 PM, David Robillard <d@drobilla.net> wrot=
e:
On Thu, 2011-11-03 a=
t 16:29 -0700, Iain Duncan wrote:

br>
br>
he
br>

>

> ( sequence or sample data )

t
ular
? I
how
ta

> clock accurate enough to check the time and see how much a sample

br>
e's

Time stamp the events as they come in (e.g. with jack_frame_tim=
e()), and
aim to execute them at (time + block_size_in_frames). =A0This avoids
jitter, and keeps the rate that you execute them bounded by the rate
they come in.

You'll also probably want some kind of hard upper limit to ensure
realtimeyness when things get crazy. =A0That truly is a Magical Mystery
Number and will depend greatly on how expensive your events are. =A0Make
one up.

-dr

--20cf3010ed576fedba04b0deaf14--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAD] timing the processing of queues between engine and..., Iain Duncan, (Fri Nov 4, 1:33 am)
Re: [LAD] timing the processing of queues between engine and..., Gabriel M. Beddingfield, (Mon Nov 7, 2:01 am)