Thanks for the tip, Jens. I found that when I put a genuine MP3 file (from Amazon MP3 store, FWIW) on my web server, I get a bunch of callbacks, including kAudioFileStreamProperty_DataFormat and kAudioFileStreamProperty_ReadyToProducePackets. So that's encouraging.
When I read my dumped Shoutcast MP3 from that same server, or connect to a live Shoutcast server, I never get any callbacks, even after reading the entire 1 MB dump.
Now I'm wondering if even creating the data format by hand (by inspecting the first MP3 frame header I find) will do any good, if the audio file stream won't packetize. Yet it worked fine when played with aqtest and the Audio File (as opposed to Audio File Stream) APIs. Probably time for some more research.
BTW, at the risk of sounding stupid (recent Java convert), I don't understand the following error. In my callback, I cast the "player state" object that the callback sends back to me:
AQPlayerState* pAqData = (AQPlayerState*) aqData;
But then when I try to put the (void *) property buffer into pAqData's member:
if (inPropertyID == kAudioFileStreamProperty_DataFormat) {
[MyLogger log: @"** got data format"];
&pAqData->mDataFormat = (AudioStreamBasicDescription*) property;
}
I get the compile-time error "invalid lvalue in assignment". What stupid thing am I doing there?
--Chris
On Apr 2, 2008, at 12:55 PM, Jens Alfke wrote:
One possibly relevant difference is that the stream I'm reading is not ShoutCast-style MP3 stream, rather an MP3 file being sent over a socket by a peer. But that shouldn't make a difference — from experience I've found you can basically chop up an MP3 file any way you like and the fragments are still playable. The decoder waits till it sees the bit pattern that starts the next MPEG frame, then begins decoding from there.