Re: crash-proof AU plugin scanning?
Re: crash-proof AU plugin scanning?
- Subject: Re: crash-proof AU plugin scanning?
- From: "Ross Bencina" <email@hidden>
- Date: Wed, 30 Jun 2010 19:18:29 +1000
Hi Dave
Thanks for getting in touch. I'll send your the beta information privately.
For that matter, if any other AU developers would like to test for
compatibility in AudioMulch (bearing in mind that my AU support is still in
beta) then I'd be happy to swap NFRs etc.
Thanks!
Ross.
----- Original Message -----
From: "Muon Software Ltd - Dave" <email@hidden>
To: <email@hidden>
Sent: Wednesday, June 30, 2010 6:21 PM
Subject: RE: crash-proof AU plugin scanning?
Ross,
I know its not related to your exact question, but it's *very* odd to see
CMplay crashing like that during your startup scan. I could do with
debugging CMplay in your host to find out what the problem is.
Kind regards
Dave Waugh
Muon Software Ltd
www.muon-software.com
-----Original Message-----
From: coreaudio-api-bounces+dave=email@hidden
[mailto:coreaudio-api-bounces+dave=email@hidden] On
Behalf Of Ross Bencina
Sent: Wednesday, June 30, 2010 7:43 AM
To: email@hidden
Subject: crash-proof AU plugin scanning?
Hi
At startup I scan AU plugins and cache some details (supported channels
etc). Pretty much
like what Logic does as far as I can tell from this:
http://developer.apple.com/mac/library/technotes/tn2007/tn2207.html
Problem is, this means running code in the plugin, which can cause a crash
when my host starts, like this one:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.futurenet.CMplay 0x1c41ee81
CMuonAudioPluginFXunit::doVolumes() + 219
1 com.futurenet.CMplay 0x1c434232
CMuonBypassFX::cookParameters(bool) + 584
2 com.futurenet.CMplay 0x1c4a47f3
CMuonTachyonSynth::cookParameters(bool) + 1069
3 com.futurenet.CMplay 0x1c4a8a2c
CMuonTachyonSynth::recallMulti() + 246
4 com.futurenet.CMplay 0x1c4aa0b1 CMuonTachyonSynth::reset(int,
int) + 593
5 com.futurenet.CMplay 0x1c531524 CMuonTachyon::initprocess() +
280
6 com.futurenet.CMplay 0x1c531991
CMuonTachyon::CMuonTachyon(ComponentInstanceRecord*) + 433
7 com.futurenet.CMplay 0x1c531d3d CMuonTachyonEntry + 73
8 ...ple.CoreServices.CarbonCore 0x92860ce5 CallComponentDispatch + 29
9 ...ple.CoreServices.CarbonCore 0x92860cc6 CallComponentOpen + 43
10 ...ple.CoreServices.CarbonCore 0x9285ef94 OpenAComponent + 433
11 ...ple.CoreServices.CarbonCore 0x92864909 OpenComponent + 24
I guess I need to implement my scanner in a separate process or use fork()
or something to avoid this kind of startup crash. Can anyone recommend a
best-practice approach for crash proofing AU scanning ? Given the problems
I'm currently seeing with PACE protected pluigns I'm a little wary of doing
the scanning in a separate process without knowing it will work.
For VST I just pre-flight the bundle to get some assurance it's real, but
for AU I need to get channel info so I have to load the plugin to query it
(would have been nice if this metadata was stored in the bundle's plist, oh
well)..
Thank you
Ross.
_______________________________________________
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
_______________________________________________
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