Re: Stuck notes in Rax and Synthtest
Re: Stuck notes in Rax and Synthtest
- Subject: Re: Stuck notes in Rax and Synthtest
- From: Philippe Wicker <email@hidden>
- Date: Wed, 7 May 2003 21:42:05 +0200
On Wednesday, May 7, 2003, at 07:18 PM, Art Gillespie wrote:
Note that the case may arise where you need mutual exclusion that
*isn't* owned by the locking thread... in this case, you need to use a
semaphore instead. (Since semaphores aren't part of Pthreads, you'll
have to look into BSD's compliance with POSIX 1003.1b-1993)
Posix semaphores are good when you want to synchronize between
processes and not only between threads within a given process. However,
they miss a time-out parameter when calling sem_wait(). If you don't
have to deal with IPC but only with threads
synchronization/communication within one process, which is usually the
case for Audio/MIDI applications, mach semaphores look a better choice.
They are very efficient and require less system resources than their
POSIX counterpart (a POSIX semaphore has a name and is something like a
lightweight file for the system).
On Wednesday, May 7, 2003, at 05:54 PM, Urs Heckmann wrote:
Am Mittwoch, 07.05.03, um 15:52 Uhr (Europe/Berlin) schrieb Angus F.
Hewlett:
At 05:52 PM 5/6/2003 -0600, Chris Reed wrote:
Interesting... I was under the impression that you should really only
deliver MIDI events to a MusicDevice before the buffer is rendered.
That
way there is a clearly defined "0" sample offset.
Yes, but esp. on a dual machine, if it's not clearly defined that the
host
must performed mutexing, it's quite possible that MIDI events for the
-next- buffer might start getting delivered while Render() is still
doing
its thing.
Is there any
documentation about what a MusicDevice should do if it receives an
event
while a buffer is being rendered, and what 0 means then?
I would be inclined to say that as soon as Render() begins, any events
received are queued for the next Render().
Well, that's a pitfall I'm gonna run into as well. My stuff is thread
save (I hope), but probably only for single processors...
Using a mutex to protect the access to some list of MIDI events from
the MIDI thread and the Audio thread may have side effects. Both
threads are high priority threads, but I think that the MIDI thread has
not as high a priority than the Audio thread: I don't know if this
thread is a TIME_CONSTRAINED, and moreover if it is configured as non
preemptible. I think it is preemptible. Assume the following sequence
of events: the MIDI thread takes the CPU, locks the mutex. and then
the Audio thread is woken up, preempts the MIDI thread and try to lock
the mutex. If the Audio thread has called pthread_mutex_lock(), it will
then be blocked, and the MIDI thread will probably immediately
reacquire the CPU and end its job, yielding the CPU and enabling the
Audio thread to start again. A workaround could be to call
pthread_mutex_trylock(). This call returns an error EBUSY if the mutex
is already locked but does not block the calling thread. Doing so would
allow the Audio thread to do its rendering job without delay, at the
cost of an increased latency for the processing of MIDI events.
However, there may be a solution to avoid the mutex. This is how I
would do. "Real time" MIDI events (essentially NOTE ON/NOTE OFF)
received in the MIDI thread are pushed in a non blocking FIFO. The
Audio thread checks this fifo before it begins to render and pull
available MIDI events and process them. If you need the code of such a
non blocking FIFO you may have a look at the Kurt Revis
VirtualRingBuffer (written in ObjC) or I may provide you with the code
of a C++ class that does this (very simple, about 100 lines of code).
In both cases, the FIFOs are of fixed size, which means that MIDI
overrun may occur, although very unlikely. The period of the IOProc
calls is about 12 milliseconds for a 44.1KHz/512 frames IO buffer.
Using a large enough FIFO should avoid any overrun problem.
Regards,
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.