Re: AudioQueueNewOutput and the runloop
Re: AudioQueueNewOutput and the runloop
- Subject: Re: AudioQueueNewOutput and the runloop
- From: Wil Macaulay <email@hidden>
- Date: Sat, 27 Oct 2012 18:47:50 -0400
You can use dispatch queues in iOS 5 and greater (IIRC)
On Tue, Oct 23, 2012 at 9:07 AM, patrick machielse
<email@hidden> wrote:
Op 22 okt. 2012, om 22:53 heeft Michael Miller <email@hidden> het volgende geschreven:
> I can certainly speculate. If your output settings require conversion (i.e., decoding AAC audio), AV Foundation will use AudioQueue to do that conversion. We've been seeing crashes related to AVAssetReader and AudioQueue under OS X 10.8.2 in our own code. We've now resorted to decoding the frames by hand using AudioConverter to work around the above crashes. Since AVAssetReader is relying on AudioQueues, I can certainly imagine calling copyNextSampleBuffer on the AudioQueue thread causing problems.
>
> Have you tried either specifying a runloop instead of letting AudioQueueNewOutput decide or using the dispatch queue version?
Thanks Michael,
I'm a bit weary about specifying a runloop (and I suppose this would mean managing a new/separate thread as well). I'm not sure exactly what options, runloop modes, etc. that would require. I don't know enough about AudioQueue's internals to make that work best -- especially on iOS.
Also, because I'm on iOS the dispatch queue API is not available.
p.
> On Oct 22, 2012, at 4:23 PM, patrick machielse wrote:
>
>> I'm still bitten by this issue:
>>
>>> In my (iOS) application I use an AudioQueue. It is created like this:
>>>
>>> AudioQueueNewOutput(&asbd, queueCallback, (__bridge void *)self, NULL, kCFRunLoopCommonModes, 0, &newQueue);
>>>
>>>
>>> in 'queueCallback', eventually AVAssetReader is used to decode frames from an audio file
>>>
>>> CMSampleBufferRef nextBuffer = [output copyNextSampleBuffer];
>>>
>>>
>>> Sometimes this call hangs:
>>>
>>> Thread 21 AQClient, Queue : (null)
>>> #0 0x3a0bdeb4 in mach_msg_trap ()
>>> #1 0x3a0be04c in mach_msg ()
>>> #2 0x38043044 in __CFRunLoopServiceMachPort ()
>>> #3 0x38041da2 in __CFRunLoopRun ()
>>> #4 0x37fb4ebc in CFRunLoopRunSpecific ()
>>> #5 0x37fb4d48 in CFRunLoopRunInMode ()
>>> #6 0x3842e658 in -[AVRunLoopCondition _waitInMode:untilDate:] ()
>>> #7 0x383e49b8 in -[AVAssetReaderOutput copyNextSampleBuffer] ()
>>>
>>> Is there any connection between the runloop of the main thread and the runloop configuration of the AudioQueue that might explain this?
>>>
>>> Could I configure my queue in AudioQueueNewOutput() in a different way?
>>
>> I'd be grateful if anyone can speculate on _why_ -[AVAssetReaderOutput copyNextSampleBuffer] might sometimes hang in CFRunLoopRunInMode when called on an audioqueue callback.
_______________________________________________
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
--
Products and services:
http://flagpig.comBlog:
http://flagpig.tumblr.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