Re: Delivering MIDI causing crashes in some AUs
Re: Delivering MIDI causing crashes in some AUs
- Subject: Re: Delivering MIDI causing crashes in some AUs
- From: Robert Grant <email@hidden>
- Date: Thu, 7 Oct 2004 18:11:08 -0400
OK - I spoke too soon (perhaps I've been talking to myself so it
doesn't matter!). After re-reading the license agreement I find that I
can't redistribute AUValidation!
So I guess for all us non-Apple hosts we need to come up with an
alternative solution but I don't feel like re-writing AUValidation.
An XML file of known-bad AUs might be one way to do it. Be faster to
start up too. It would also allow us to let in some less-than perfect
members. And by going with the Bad AUs it would (hopefully) be a much
shorter list!
I dunno - it's all a bit depressing...
Robert.
On Oct 7, 2004, at 5:28 PM, Robert Grant wrote:
Offline discussions with a couple of folks have led me to conclude
that I'll just have to join the AUValidation bandwagon and drop AUs
that don't pass - which the AUs in question don't.
Robert.
On Oct 6, 2004, at 9:59 PM, Robert Grant wrote:
What's weird about the render callback is that it's calling
AudioUnitRender without difficulty. Those stack traces look like a
memory corruption or something. But why for this synth and not all
the others?
Looking at the code for AUMIDIBase::ComponentEntryDispatch it seems
likely that the "ComponentParameters" param is corrupted - the "This"
pointer I imagine is OK.
Various MallocXXX debugging options aren't revealing anything...
Robert.
On Oct 6, 2004, at 7:30 PM, Robert Grant wrote:
So I fixed a couple of d'oh AU initialization bugs in Rax and now
Crystal is blowing chunks as soon as it gets some MIDI - stack
fragment follows:
Thread 7 Crashed:
0 com.greenoak.AtFr 0x062dcb98
AUMIDIBase::ComponentEntryDispatch(ComponentParameters*,
AUMIDIBase*) + 0x40
1 com.greenoak.AtFr 0x062dea30
MusicDeviceBase::ComponentEntryDispatch(ComponentParameters*,
MusicDeviceBase*) + 0x8c
2 com.greenoak.AtFr 0x062e1c28 CVST2AUPluginEntry +
0x214
3 ...ple.CoreServices.CarbonCore 0x90281278 CallComponent + 0x10c
4 ...apple.audio.units.AudioUnit 0x91a90a0c MusicDeviceMIDIEvent
+ 0x34
5 com.grantedsw.rax 0x000109cc -[AUDevice
renderInputWithFlags:timeStamp:busNumber:numberFrames:ioData:] +
0x128 (AUDevice.m:808)
It also dies when receiving MIDI (such as continuous controller
data) outside of the render proc:
Thread 2 Crashed:
0 com.greenoak.AtFr 0x06427b98
AUMIDIBase::ComponentEntryDispatch(ComponentParameters*,
AUMIDIBase*) + 0x40
1 com.greenoak.AtFr 0x06429a30
MusicDeviceBase::ComponentEntryDispatch(ComponentParameters*,
MusicDeviceBase*) + 0x8c
2 com.greenoak.AtFr 0x0642cc28 CVST2AUPluginEntry +
0x214
3 ...ple.CoreServices.CarbonCore 0x90281278 CallComponent + 0x10c
4 ...apple.audio.units.AudioUnit 0x91a90a0c MusicDeviceMIDIEvent
+ 0x34
5 com.grantedsw.rax 0x0001065c -[AUDevice
processMIDIPacketList:sender:] + 0x724 (AUDevice.m:745)
This kind of thing happens with at least one other AU.
So my question is - how come? How come delivering MIDI can cause an
AU to blow chunks?
What's weird is that my fixes have made VirSyn Cube/TERA work and
all the other common synths are happy too. And what's also weird is
that Rax 1.0 and 1.1 all worked fine with Crystal!
It's very frustrating to plug one hole only to have new ones spring
up!
Robert.
_______________________________________________
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