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: Thu, 8 May 2003 12:04:52 -0700
Let me shed some light on this.
We had a problem with 10.2 where scheduling notes to the DLS synth from
a thread that wasn't its render thread would cause some bad things to
happen...
So, we added a queueing mechanism for 10.2.3 - that worked most of the
time, but there was a case where you'd get stuck notes. We fixed this
in 10.2.5...
Basically, the idea is:
MusicDevice get its render call.
A host (like the MusicPlayer/MusicSequence API) - attaches render
notifiers for ANY of its audio units that it has to schedule events for.
In the pre-render call it schedules events for that slice. This is by
far the best way to schedule events as each event can be scheduled down
to the sample...
After the pre-render call, the DLS synth then dequeues any events that
have occured since its last dequeue (its previous setup to render)
It then renders those events...
Any events that come in after this dequeueing are then queued up until
the next render call, whether the synth is in the process of rendering
or is quiescent.
Its been our intention to have a better base class for doing music
devices, but unfortunately that has fallen by the way side a bit...
This kind of queueing really should be done by any synth, so would
eventually be in this base class when we have time to do it...
If you have reports of stuck notes, make sure your user is on 10.2.5 -
there should be no problem there and no need for you to do any
additional work to avoid this problem...
Bill
On Thursday, May 8, 2003, at 12:09 AM, Yasir Assam wrote:
I'm getting stuck notes playing the DLSMusicDevice. It sounds like it
might
be same thing.
How can I use a mutex to block my MIDI playback thread while the
DLSMusicDevice is doing its thing? I've probably not understood this
right,
but when you use a mutex both threads need to call
pthread_mutex_lock() on
the same pthread_mutex_t variable don't they? This would mean both my
MIDI
playback code and the DLSMusicDevice would have to use the same
pthread_mutex_t, and as the DLSMusicDevice code is hidden from me I
can't do
this. Have I understood this right?
My question really is, how can I block my MIDI playback thread from
calling
MusicDeviceMIDIEvent() whilst the DLSMusicDevice is in a state where it
*cannot* receive MIDI events?
Thanks,
Yasir Assam
-----Original Message-----
From: email@hidden
[mailto:email@hidden]On Behalf Of Angus F.
Hewlett
Sent: Wednesday, 7 May 2003 3:47 AM
To: Robert Grant
Cc: email@hidden
Subject: Re: Stuck notes in Rax and Synthtest
It's OK, found it - was threading-related. Needed to put a mutex to
pause
delivery of MIDI events to my plug's buffer while Render() was doing
its
thing.
At 01:41 PM 5/6/2003 -0400, Robert Grant wrote:
Hi Angus,
I wouldn't put it past Rax to cock up some of the MIDI message
handling. I've just taken a look and this is the loop for passing
messages to the music device:
for ( j = 0; j < list->numPackets; ++j) {
Byte* msg = inPacket->data;
do {
if ((msg[0] & 0xF) == m_channel) {
MusicDeviceMIDIEvent(unit, msg[0],
msg[1], msg[2], 0);
if (msg[0] >> 4 == 0x09 && msg[2] > 0) noteOn = TRUE;
}
} while(msg = NextMIDIEvent(inPacket, msg));
inPacket = MIDIPacketNext(inPacket);
}
This is probably very wrong but this code is called in the
MIDIReadProc
thread.
Robert.
On Tuesday, May 6, 2003, at 11:22 AM, Angus F. Hewlett wrote:
Hi all,
Am seeing a problem in these AU hosts relating to my MIDI handling
routines.
In Rax and Synthtest, we are seeing frequent, easily-reproducible
stuck
notes when played from a MIDI keyboard. The MIDI data handling
routines in
my code look to be OK, so I'm wondering if it might be threading
related.
Are there any special precautions I need to take in the MIDI
routines
for a
MusicDevice?
Regards,
Angus.
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd - http://www.fxpansion.com
=======================================================
_______________________________________________
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.
=======================================================
Angus F. Hewlett, Technical Director
FXpansion Audio UK Ltd - http://www.fxpansion.com
=======================================================
_______________________________________________
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.