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: Chris Adamson <email@hidden>
- Date: Wed, 2 Apr 2008 22:15:51 -0400
OK, it looks like this is going to work. Let me just clear up my
earlier posts for the benefit of the future audience that Googles on
Shoutcast and Audio File Queue and finds this thread.
I'd said that when I start pulling bytes from my dumped Shoutcast
stream, I get no callbacks for properties or packets. True. But I
wasn't stripping out the Shoutcast junk at the top of the file, the
stuff that looks like this:
ICY 200 OK
icy-notice1:<BR>This stream requires <a href="http://
www.winamp.com/">Winamp</a><BR>
icy-notice2:SHOUTcast Distributed Network Audio Server/win32 v1.9.8<BR>
icy-name:Armitage's Dimension Jpop/Jrock/Anime, 25,000+ Songs,
Requests, Live Chat and more!
icy-genre:Anime, Japanese Pop, Rock
icy-url:http://www.armitunes.com
content-type:audio/mpeg
icy-pub:1
icy-br:128
I'd assumed that the parser would ignore that -- like it ignores ID3
tags -- and just keep reading until it got to the "FFFx" or "FFEx"
that signals an MP3 frame header. But just to test, I stripped out
the above header and had the work-in-progress stream reader go through
the file, and discovered I was now getting callbacks with properties
(including data format) and packets. Yay.
I'll have to strip that junk from live streams, but that's OK: I'll
have to pre-process the stream anyways to actually support Shoutcast
in-stream tagging. For those of you who haven't had a chance to play
with that stuff, the way Shoutcast works is that when you make the
initial HTTP request, you throw in an "icy-metaint" parameter, which
gives you back something like "icy-metaint: 8192", which means that
every 8192 bytes, your stream will have in-line metadata that you have
to parse out before handing it to your audio parser (it's not like ID3
which always lives between tags). I wrote up some of this stuff years
ago when I got Shoutcast and ID3 working in the Java Media
Framework... for like a month, before Sun pulled MP3 out of JMF
because they couldn't afford the license. Anyways, my old docs (an
unpublished O'Reilly article) are here:
<http://jicyshout.cvs.sourceforge.net/*checkout*/jicyshout/jicyshout1/doc/oreilly-article/java-streaming-mp3-pt2/java-streaming-mp3-pt2.html
>
I'll hit it again tomorrow, but can I ask you a question about how you
got yours working, Jens? I'm not settled on how the various callbacks
work in the streaming case. Let me sort it out...
For playing from a file, you start an Audio Queue. That periodically
gives you a callback to fill up a buffer in the queue, which you
service by calling AudioFileReadPackets to get packets from the file,
and then put them in the queue with AudioQueueEnqueueBuffer
In the streaming case, you get a CFReadStream from an HTTP request.
This requires you to have two new callbacks: for properties and
packets. You loop and call CFReadStreamRead to read bytes from the
stream, which in turn calls your callbacks. 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. 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 *think* that's going to work. Ask me in a few days. :-)
Thanks for your time, all...
--Chris
_______________________________________________
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