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 14:14:54 -0700
On May 19, 2008, at 2:08 PM, Chris Liscio wrote:
Hello list,
I am playing AAC files using the ExtAudioFile API, and I need to read
the file's contents in forward and reverse directions. Once I reach
the end of a file, and then try seeking to anywhere else in the file,
subsequent calls to ExtAudioFileRead() fail with a result of -50
(error in user parameter list).
I have solved this problem once already by calling ExtAudioFileSeek(0)
and then ExtAudioFileSeek(mCurrentFrame) just before I call
ExtAudioFileRead(). It sounds nasty, but it worked and didn't seem to
cause any performance issues at the time. We shipped with this code,
and it worked great for the most part.
Unfortunately, my approach to playing the audio was to call
ExtAudioFileRead() in the output AU's render function, which I now
know was a bad move. Some folks are reporting gaps in audio playback
on their systems (and I'm noticing it on my machines if I force an IO
storm). The gaps are intermittent and short, but they're there and it
bugs me.
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...
I have adapted the C++ PublicUtility file reader classes to a threaded
producer/consumer implementation in Objective-C which seems to work
fine until I reach the end of the file. It would appear I'm back to
where I started, and ExtAudioFileRead() fails with a result of -50.
It doesn't matter if I'm seeking to -4096 frames from the end of the
file, or to frame 0.
The main difference with my new implementation is that I'm priming my
audio buffers on the app's main thread, and subsequent reads happen in
a separate producer thread. The failure is happening on the main
thread when the buffer is being primed again to start playback at the
new position.
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).
Bill
At any rate, the tendency for ExtAudioFileRead() to fail with a result
of -50 in a single-threaded environment after reaching the end of the
file is a problem on its own. I'm only just noticing that my 'fix' to
seek to 0, then the current position, is no longer working in a
multi-threaded environment. So now, I'm looking for a an explanation
for the -50 error code in this situation, and a way to get this
working properly.
Any help with this would be greatly appreciated.
Cheers,
Chris Liscio
http://tapedeckapp.com -- Like a real cassette recorder, only better
_______________________________________________
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