Re: Stuck notes in Rax and Synthtest
Re: Stuck notes in Rax and Synthtest
- Subject: Re: Stuck notes in Rax and Synthtest
- From: Bill Stewart <email@hidden>
- Date: Mon, 12 May 2003 10:27:56 -0700
Yasir
On Sunday, May 11, 2003, at 01:07 AM, Yasir Assam wrote:
Thanks Chris.
This worked. I'm actually using the V1 API which is probably why even
with
10.2.6 we were still getting stuck notes.
The implementation for this is the same for Apple's synth (V1 or V2) -
are these stuck notes occuring with the builtin DLSMusicDevice?
If so I'd love a test case if that is possible, as we thought we had
fixed all of these outstanding issues in 10.2.5
Thanks
Bill
Incidentally, we were originally using the QuickTime synth and getting
stuck
notes but now that we use the DLSMusicDevice and add MIDI events in the
render notification message it works fine.
Yasir Assam
-----Original Message-----
From: email@hidden
[mailto:email@hidden]On Behalf Of Chris Rogers
Sent: Friday, 9 May 2003 5:40 AM
To: email@hidden
Subject: RE: Stuck notes in Rax and Synthtest
Yasir,
Actually, if you go so far as to install a render notification,
you can directly schedule the notes there. In fact this was the
original intention of the pre-render notification - to schedule events
for the next render cycle. Then, you'd have to queue up events from
your other thread, to be scheduled in the notification. The
DLSMusicDevice itself is doing this if MusicDeviceStartNote()
or MusicDeviceMIDIEvent() is called from another thread (in 10.2.3)
but there is a bug (fixed in our current version) where a note-off
quickly following a note on, may be lost. You may want to check if
the stuck notes are occuring for very "short" notes like this....
mutexes are overkill for this application, and actually could be very
bad since we you don't want the real-time thread blocked because of
this mutex! In this case, because one thread is queuing events and
the real-time thread is de-queuing events, it's sufficient to simply
have an array of event structures, with a bool member which marks
the event as "in use" or not. The feeder thread marks it as "in use"
and the real-time thread clears it when it's handled that event.
I hope I haven't confused everybody ;-)
Chris Rogers
Core Audio
Apple Computer
I've just had a look at the AudioUnits docs and I think I might have
seen
where this could be done.
Do I need to use the RenderNotify callback mechanism? I.E. I'd
request a
notify callback before and after the DLSMusicDevice does its
rendering, and
it's in this callback that I lock/unlock mutex. Is this correct?
Also, do I have to lock/unlock mutex for each AU in the AUGraph,
or only the
DLSMusicDevice? Specifically, I have a simple graph - the
DLSMusicDevice
connected to the default output AU.
Thanks,
Yasir Assam
_______________________________________________
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.
_______________________________________________
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.
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.