Re: MusicEventIterator questions
Re: MusicEventIterator questions
- Subject: Re: MusicEventIterator questions
- From: Ross Bencina <email@hidden>
- Date: Tue, 19 Mar 2013 22:42:46 +1100
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:
UI-sequence -> Audio-thread-sequence
<- (old nodes for deallocation in UI)
(-> is a FIFO "conduit of change")
Assuming that only the UI modifies the sequence then it's a master+slave
relation, not so difficult to work out the appropriate change
transactions.* We can dig into the details of the synchronisation
protocol if you like.
Propagate change commands to the Audio thread. These could take the form
of link, modify and unlink operations on a linked data structure. For
efficiently updating a sorted list you might want to use a red-black
tree. Allocate the nodes in the GUI thread, install them in the audio
thread.
Another approach is just to send a whole new "compiled" sequence object
to the audio thread every time a change is made, swap it in, and destroy
the old one later. You could also take a middle ground approach and do a
bit of both.
Ultimately the key idea is that all operations on the audio thread side
are efficient and bounded, ideally to O(1), or maybe O(NlogN). For
sequence data you could just use a sorted array, and ship a whole new
array to the audio thread every time there's an update. You can always
seek into it using a binary search.
I run through a lot of the basic ideas here:
http://www.rossbencina.com/code/programming-with-lightweight-asynchronous-messages-some-basic-patterns
The code that updates the Audio-thread-sequence also knows about the
iterator(s) so it can re-sync them if they happen to point to nodes that
have been unlinked.
Another thing to keep in mind is that if you use a split-synced data
structure the format of each form doesn't need to be the same. The
UI-side structure can be structured for editing, the Audio-side version
can be structured for efficient sequential playback.
Ross.
[*] Synchronisation in both directions is also possible: you might want
to read about Operational Transformation.
On 19/03/2013 8:29 AM, Aran Mulholland wrote:
Does anyone have any thoughts on this? I'm in the process of writing a
lock free data structure for storing midi information and am wondering
if I might be reinventing the wheel.
On Thu, Feb 28, 2013 at 9:03 PM, Aran Mulholland
<email@hidden <mailto:email@hidden>> wrote:
I have a couple of questions regarding MusicEventIterators.
Can they be used in the render callback? It would seem like the
answer to this question is no as I'm pretty sure that the call
to NewMusicEventIterator will most probably allocate memory.
Also in the doco it states:
"If you edit a music track after associating it with a music event
iterator, you must discard iterator and create a new one."
If you were using MusicTracks to store note and controller
information what is the situation with thread safety of the
MusicEventIterator when used in a producer consumer type fashion.
When using multiple threads I have the possibility that the
MusicTrack will be edited while I am iterating. Will this throw an
exception or will I just be iterating over stale information?
https://developer.apple.com/library/mac/documentation/AudioToolbox/Reference/MusicEventIterator_Reference/Reference/reference.html#//apple_ref/c/func/NewMusicEventIterator
Aran
_______________________________________________
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