Re: audio file bug in AudioUnitHosting
Re: audio file bug in AudioUnitHosting
- Subject: Re: audio file bug in AudioUnitHosting
- From: David Duncan <email@hidden>
- Date: Sun, 4 Jan 2004 11:35:12 -0500
On Jan 4, 2004, at 12:09 PM, Marc Poirier wrote:
I just submitted this to RADAR, but I figured I'd post it here, too
(and
my suggested fix) for anyone who might find it useful:
AudioUnitHosting has a bug with resolving the file paths of audio files
dropped onto its DataBrowser. It relies on CFStringGetCStringPtr() to
get
a C string version of the CFString file path, which is failing in this
case 100% of the time, so AUH keeps aborting with an exception thrown
right after that when FSPathMakeRef fails.
I've changed the source code to convert the CFStringRef path to a
CFURLRef
(instead of a C string) and then convert the CFURLRef to an FSRef, and
now
it works reliably. The changes need to be made to
AudioEffectHosting::SelectedFile() and
MusicDeviceHosting::SelectedFile()
in AudioUnitHosting.cpp. In both functions, you need to replace these
lines:
Unfortunately after looking at this, I think the problem runs deeper
than that. For one reason or another, they choose to store the paths as
CFStrings, but initially encode them as MacRoman and no longer than 512
characters. So even with the changes you previously sent, you will
still have badly encoded paths in some cases.
Basically a complete fix would likely involve replacing CFStringRefs
with CFURLRefs throughout AudioFileChooser.cpp where appropriate, and
changing SelectedFile() to take a CFURLRef instead.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
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.