Re: Getting an AudioStreamBasicDescription from a stream, not a file
Re: Getting an AudioStreamBasicDescription from a stream, not a file
- Subject: Re: Getting an AudioStreamBasicDescription from a stream, not a file
- From: Jens Alfke <email@hidden>
- Date: Wed, 2 Apr 2008 21:53:35 -0700
On 2 Apr '08, at 7:15 PM, Chris Adamson wrote:
So now there are two things you're responsible for servicing: the
Audio Queue and the read stream. This is where I'm not sure how
it's going to work, to get the packets from the stream's "found
packets" callback back to the audio queue's "fill my buffer" callback.
It is a bit weird. It took me a while to wrap my head around it.
I think the approach is something like:
1. Start the audio queue.
2. Audio queue's callback gets called.
3. Start reading from the stream in a loop.
4. Audio File Stream's "handle packet" loop gets called. Put
assembled packet(s) in the queue state structure. (Presumably, do
this many times, until you have the number of packets required by
step 2?)
5. Exit stream-reading loop (step 3), get packets out of the queue
state structure and put them into queue with AudioQueueEnqueueBuffer
I wouldn't handle either of those tasks in a loop, frankly. Instead,
do some buffering in between. The flow of control kind of looks like
this, in a sort of made-up non-procedural pseudocode (apparently there
are languages, like Occam, that look something like this):
* WHEN there's data available on the CFReadStream AND your
intermediate packet buffer isn't full, THEN feed the bytes into the
AudioFileStream and push the output packets into the packet buffer.
* WHEN the AudioQueue has spare buffers*, AND your packet buffer has
enough packets in it, THEN fill up an AudioQueue buffer with packets
and enqueue it.
Think of the buffer callback as being the queue telling you "I'm done
with this buffer now". You don't necessarily have to fill and enqueue
that buffer before the callback returns. You can just add it to a set
of spare buffers, and fill it up and enqueue it as soon as you have
stuff to put in it.
Similarly, the CFReadStream bytes-available callback doesn't require
you to read the bytes immediately. If you don't, the socket will just
stop receiving new packets and wait for you to read them.
(I bet this is the kind of flow of control that would make perfect
sense implemented with coroutines...)
This isn't exactly the way my code works (the network thingy I'm
reading from isn't a raw socket, rather a higher-level message/
response API) but I think this should be feasible. Hope this helps.
—Jens
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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