• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: MusicSequence MusicPlayer API questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MusicSequence MusicPlayer API questions


  • Subject: Re: MusicSequence MusicPlayer API questions
  • From: William Stewart <email@hidden>
  • Date: Thu, 12 Mar 2009 14:43:41 -0700


On Mar 12, 2009, at 2:45 AM, email@hidden wrote:

Hi to all,

I would like to know some implementation details of the
MusicPlayer/MusicSequence API:

1. Is the API thread safe? For example:
can one or more threads modify a Music Sequence without taking extra
cautions (lock a mutex) even while the sequence is being played?

the API is thread safe between whatever playing threads are in use and a calling thread. If you are using the same object concurrently on different threads yourself, then that's your problem




2. If
the API is thread safe, is it lock-free? Or better: if one thread tries
to read/modify a Music Sequence concurrently with another thread and
while the sequence is being played, is there any danger that any of the
threads will block on a mutex?



3. Is the MusicSequence implemented with some kind of linked list? Or better: can I keep pointers to MIDI events around without being worried about invalidating them with operations on the MusicSequence?

that seems like a dangerous path to take - are you really sure that you need to go to these lengths. What kind of performance problems have you measured that require this? (And I stress measure, not hypothesise about) a simple test case seems to be in order to validate your assumptions


Bill



As a consequence of the above I would
gently ask some design advices.

This is the scenario:
- one GUI
threads communicating asynchronously through a lock-free queue with a
real-time thread
- the real-time thread creates MIDI events (let’s say
randomly) just before they have to be played (with a minimal buffer)
and appends them to a MusicSequence


- a third thread (I imagine spawned by the API itself) plays the MusicSequence - both the RT thread and the GUI thread should be able to keep pointers to the MIDI events in the sequence

Questions:
1. Is the MusicPlayer/MusicSequence API usable in
this context or do you think I have to roll out my own sequencer?

2.
Would it make sense to schedule the RT thread with a higher priority
than the “playing thread”?

3. In the case of building my own sequencer
I would be inclined to use the same RT thread for creating /*and*/ for
playing out notes with the CoreMIDI low level functions. Do you think
this would be a correct approach?

Thanks in advance for any answer,
insight, whatever... :-)
Bye,
Francesco


_______________________________________________ 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
References: 
 >MusicSequence MusicPlayer API questions (From: "email@hidden" <email@hidden>)

  • Prev by Date: RenderCallbacks Disconnecting
  • Next by Date: Re: RenderCallbacks Disconnecting
  • Previous by thread: MusicSequence MusicPlayer API questions
  • Next by thread: How to fill the ioData parameter in the Audio Unit rendering call back?
  • Index(es):
    • Date
    • Thread