Re: ExtAudioFileRead fails after reaching EOF, despite new seek position
Re: ExtAudioFileRead fails after reaching EOF, despite new seek position
- Subject: Re: ExtAudioFileRead fails after reaching EOF, despite new seek position
- From: William Stewart <email@hidden>
- Date: Mon, 19 May 2008 16:17:45 -0700
On May 19, 2008, at 2:44 PM, Christopher Liscio wrote:
On May 19, 2008, at 5:14 PM, William Stewart wrote:
That's why we provide the AUFilePlayer audio unit and the PlayFile
example code, as it does these things as they should be done. I
think it provides you with enough control so that you can do seeks,
etc...
Well, I hit a few other problems with those. First off,
AUFilePlayer will not support playing in reverse as far as I can
tell. Did I miss something in the headers / documentation? I'd
much sooner switch than keep my own code, as deleting code is far
more fun than writing it...
AUFilePlayer sits on top of the AUScheduledSlicePlayer - which is an
audio unit that you push buffers of audio too from any thread and it
will play them back. It is more work, but you could certainly do what
you are talking about here.
Second, I checked out afplay, though it uses the C++ PublicUtility
classes which I was unable to get working properly in TapeDeck.
Upon calling CAAudioFileReader::Start(), I got an exception thrown
in CAAudioFile::Tell() that claims it "Couldn't get file's mark".
I didnt say afplay - I said PlayFile (which is in the SimpleSDK
directory). In any case, it may not provide what you need if you want
to reverse playback files...
This, combined with some older mailing list messages that claimed
that ExtAudioFileTell() is screwy on AAC files, worried me about
going further with the C++ PublicUtility classes.
So, I tried to use what was provided to me, but hit some road blocks
that I was able to get around at the time by rolling my own code to
do this.
You can't share an ExtAudioFile object between multiple threads
without synchronising the access. It does not do that for you (as
we decided that the user of the API should take care of these
issues and the common case is to use the object from one thread).
Right -- I hit some bugs earlier where I wasn't blocking the access
to the audio file and that resulted in crashes and not errors.
Is ExtAudioFileRead() sensitive to callers from separate threads
despite blocking access to the file, or were you alluding to the
type of locking I've done? (It's just a simple @synchronized block
in Objective-C that surrounds the Seek/Read calls, and it cleared up
the crashes completely).
sure - that's what you would need
Bill
Cheers,
Chris Liscio
http://SuperMegaUltraGroovy.com
Acoustic measurement software for Mac OS X -- http://www.FuzzMeasure.com
_______________________________________________
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