Re: ExtAudioFileDispose blocking
Re: ExtAudioFileDispose blocking
- Subject: Re: ExtAudioFileDispose blocking
- From: Ethan Funk <email@hidden>
- Date: Tue, 6 Apr 2010 09:01:56 -0700
More info on the ExtAudioFileRead blocking/thread killing problem: I set the thread filler thread to async cancelation and set a break point in a debug procedure I pushed on the thread cleanup stack. After 35 hours, it tripped, and here is the thread backtrace from the breakpoint:
#0 0x000370c0 in fpCleanUp at FilePlayer.cpp:513
#1 0x914be61f in _pthread_exit
#2 0x91493a0a in cthread_set_errno_self
#3 0x91488ba7 in cerror
#4 0x980d8302 in Cached_DataSource::ReadBytes
#5 0x9808c634 in AudioFileObject::ReadBytes
#6 0x9808c4cd in AudioFileObject::ReadPackets
#7 0x9808c397 in AudioFileReadPackets
#8 0x980e53d0 in ExtAudioFile::ReadInputProc
#9 0x9808a60d in AudioConverterChain::CallInputProc
#10 0x9808a1e2 in AudioConverterChain::FillBufferFromInputProc
#11 0x9808a0c1 in BufferedAudioConverter::GetInputBytes
#12 0x98089f7d in CBRConverter::RenderOutput
#13 0x98089d27 in BufferedAudioConverter::FillBuffer
#14 0x9808a09a in BufferedAudioConverter::GetInputBytes
#15 0x9808e24c in Resampler2Wrapper::RenderOutput
#16 0x98089d27 in BufferedAudioConverter::FillBuffer
#17 0x9808a09a in BufferedAudioConverter::GetInputBytes
#18 0x98089f7d in CBRConverter::RenderOutput
#19 0x98089d27 in BufferedAudioConverter::FillBuffer
#20 0x98089e8f in AudioConverterChain::RenderOutput
#21 0x98089d27 in BufferedAudioConverter::FillBuffer
#22 0x98089a9c in AudioConverterFillComplexBuffer
#23 0x980e6130 in ExtAudioFile::Read
#24 0x980dce5d in ExtAudioFileRead
#25 0x0003998f in FilePlayer::fillRingBufferThread at FilePlayer.cpp:535
#26 0x914b5fbd in _pthread_start
#27 0x914b5e42 in thread_start
Any idea what cerr and cthread_set_errno_self functions are, and why they are calling _pthread_exit? I would expect any errors encountered in Cached_DataSource::ReadBytes to get passed up the chain to the original ExtAudioFileRead. Why is it instead resulting in a _pthread_exit call? How can I prevent this? My gut instinct is to set the thread cancelation state to disable and run it again for a few days and see what happens, but it sure would be nice to know what's really going on.
Any advice from the Apple folks who can peek below the API hood?
Thanks,
Ethan...
_______________________________________________
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