Re: MusicEventIterator questions

Subject: Re: MusicEventIterator questions
From: Aran Mulholland <email@hidden>
Date: Wed, 20 Mar 2013 08:30:42 +1100

Thanks Ross and Paul,

What you describe is kind of what I have started writing.

I have a structure that is an ordered linked list built from the UI thread. Then I have another routine that builds a structure for the audio thead to consume. They are slightly different structures as I wanted the audio thread to have an array so I can perform a binary search to get 'interesting' events for the current time period being rendered.

Paul's idea of having a windowed snapshot of the data is an interesting one that I may consider as I have not yet worked out how to give the audio thread the most up to date array or how to dispose of stale arrays, but I'm having fun. Best problem I've worked on in ages.

I guess I'm most interested in how to pass the audio thread the latest array. I'll have a look at that article you wrote.

Thanks

On Wed, Mar 20, 2013 at 3:26 AM, Ross Bencina <email@hidden> wrote:

On 20/03/2013 1:05 AM, Paul Davis wrote:

On Tue, Mar 19, 2013 at 7:42 AM, Ross Bencina
<email@hidden <mailto:rossb-lists@audiomulch.com>> wrote:

Hi Aran,

I agree with Paul that if the idea is to have a single mutable data
structure that is accessible from multiple threads that's kind of hard.

But the way I would do it is have two single-threaded data
structures and propogate changes via a FIFO:

there is an alternate approach too that also uses a FIFO. the "audio"
thread (running in an RT context, the one where rendering is done)
doesn't need to know about anything that, well, anything that it doesn't
need to know about. it only cares about "now", meaning specific data
required to render audio for the current block of time.

Modulo some "schedule ahead" extra safety margin. You're basically trading latency for ease of implementation.

so you can leave your fancy-pants data structure in non-RT land, and
just make sure that a "linearized" version of gets pushed into a FIFO
where the audio thread can pull from. that way, you can use mutexes or
whatever synchronization mechanisms you want in non-RT land, and the
audio thread just gets a simplified, accurate, "windowed" snapshot of it
to use for rendering.

This requires to choose the window length correctly. It needs to be long enough to anticipate any disruption in the non-real-time context, and short enough to retain interactive response.

This is going to work better for some kind of applications than others.

of course, this gets complex when you jump around on the timeline and
have to refill the FIFO correctly,

It also gets difficult if you want to have lowest latency MIDI control over algorithmic sequence generation (for example).

That said, it's what Supercollider3 does (splits lang and even scheduling into a seperate thread from audio).

and in this sense, Ross' idea has a
different kind of simplicity on its side.

It's definitely a "kind of" simplicity :)

Ross.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

Follow-Ups:
- Re: MusicEventIterator questions
  - From: Ross Bencina <email@hidden>

References:
	>Re: MusicEventIterator questions (From: Aran Mulholland <email@hidden>)
	>Re: MusicEventIterator questions (From: Ross Bencina <email@hidden>)
	>Re: MusicEventIterator questions (From: Paul Davis <email@hidden>)
	>Re: MusicEventIterator questions (From: Ross Bencina <email@hidden>)

Prev by Date: JACKiOS is here
Next by Date: Re: JACKiOS is here
Previous by thread: Re: MusicEventIterator questions
Next by thread: Re: MusicEventIterator questions
Index(es):
- Date
- Thread