Re: Getting wrong data format for stream
Re: Getting wrong data format for stream
- Subject: Re: Getting wrong data format for stream
- From: Tom Harrington <email@hidden>
- Date: Wed, 22 Jul 2009 11:45:57 -0600
[Sorry, I did mean to send this to the list...]
On Wed, Jul 22, 2009 at 10:09 AM, james mccartney<email@hidden> wrote:
> On Jul 21, 2009, at 6:06 PM, james mccartney wrote:
>>
>> Are you supplying a buffer whose first byte begins an MPEG Layer 3 packet
>> (optionally preceeded by an ID3 tag), or is it a buffer that starts in the
>> middle of some random header data after which, at some point, there is MP3
>> data. If the former, then the parser may be picking up on the first bytes
>> that look like an MPEG packet header and reporting that as the format.
>
> oops. should be "if the latter". IOW starting in the middle of random data
> is the not good scenario.
I had thought that hinting would resolve this-- I know that the stream
is MP3, so I specify kAudioFileMP3Type when calling
AudioFileStreamOpen(). That helps (without it I never get "ready to
produce packets") but apparently it's not enough of a clue?
I'm not familiar enough with shoutcast to be sure but it wouldn't
surprise me if it's starting the stream in the middle of an MP3
packet. Since hinting doesn't seem to be enough, does Core Audio
provide any way for me to discard bytes until the start of the next
packet?
I thought maybe I should be passing
kAudioFileStreamParseFlag_Discontinuity to AudioFileStreamParseBytes()
when I start receiving data, but that doesn't seem to have helped.
--
Tom Harrington
email@hidden
AIM: atomicbird1
_______________________________________________
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