Re: AudioOutputUnit and QT audio extraction - back to basics
Re: AudioOutputUnit and QT audio extraction - back to basics
- Subject: Re: AudioOutputUnit and QT audio extraction - back to basics
- From: William Stewart <email@hidden>
- Date: Tue, 4 Apr 2006 12:51:40 -0700
On 03/04/2006, at 6:59 PM, Ray Garcia wrote:
Okay, given that I went through the exercise of simplifying away my
AUGraph to just a single AudioOutputUnit, and set its output device
and stream format to match the float32 noninterleaved data coming
out of QT, added a buffer transfer module to properly pull data
from the QT buffers over to the smaller AudioUnit bufers, and have
run aground on error 1718449215 while attempting to initialize the
output AU, I went looking for more blessed sample code and a simple
approach for what I think should be a simple task.
A simpler architecture for feeding short bursts of audio to an
output audio unit is hypothetically the following..
Setup:
create default AudioOutputUnit
create QT audio extraction session
read session ASBD
revise session ASBD to be float32 format, noninterleaved
compute number of audio frames needed per video frame (effectively
burst length)
set AU's input (port 0, input context) ASBD to be QT's outgoing ASBD
set AU's input ACL to be QT's outgoing ACL
Set AU's render callback
Initialize AU
Start-Playback-At-Time:
Set QT extraction start time
Start AU
Render callback:
If extraction time (guarded by mutex) has changed, restart audio-
frame countdown and move QT extraction start time
If no more audio frames to read, fill outgoing AU buffers with 0.0;
otherwise have QT fill AU's buffers with extracted sound data
Is there anything I'm missing (or doing redundantly) that will
prevent this from working? Are there further preconditions to
initializing an output AU, for instance? I'm assuming a
ScheduledAudioPlayer AU isn't needed at all if the playback time is
always "immediately if not sooner"? I
No. You have a fundamental problem in that you cannot call QT's
extraction API from the render thread, nor should you be entering
unbounded blocking conditions (your "guarded by a mutext") conditions
on that render thread.
A better way to approach this is to use the Scheduled Slice AU - it
allows you to schedule buffers for playback (and you just connect its
output to the output AU), so you can simply have a read thread going
through and pulling data out of QT, scheduling those slices to be
played, and let the Schedule AU take care of managing the I/O proc.
It would probably be a useful piece of sample code for us to generate
- so I'll forward this on as a request! :-)
Bill
Thanks.
_______________________________________________
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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