[Icecast-dev] Problem in iPhone streaming

[Michael Smith]

On Thu, Nov 13, 2008 at 1:08 AM, Pavol Grešša <pavol.gressa at ecommerce.cz> wrote:
> Hi,
>
> i'm developing an internet radio client for iPhone and as server is
> used Icecast2. My problem is that every time when client connects to
> some source(mount) Icecast2 sends correct HTTP 1.0 header and after
> header delimiter(two empty lines(\r\n\r\n))  should be data ( mp3
> samples). But every time in the first packet in the beginnig of data
> section there are some bytes to which iPhone audio parser cannot
> undestand( Becasue every mp3 sample starts with mp3 header (0xFFF) ).
> This happens only to first packet. I'm sure of that, because i have
> stream in what i'm sure that raw sound data begins with prefix 0xFFF3
> and every time when i parse whole data in first packet and get only
> those mp3 sample, stream will became stable and iPhone is playing that
> radio for rest of time without any parsing.

Icecast doesn't support mp3 - it's a non-free format, and thus not
something we really care about. However, it does pass through mp3 data
from the source client - so for many cases, mp3 streaming works fine.

Because it doesn't handle mp3 explicitly, the client gets started at
an arbitrary byte offset - not at the start of an mp3 frame,
generally. Most decoders find the next sync-point just fine, and then
decode ok - perhaps the iphone doesn't. So what you're seeing is the
expected behaviour.

You could add explicit mp3 handling to your local copy to avoid this
problem - you'd need to write an mp3 parser (pretty simple) and plug
it in using the format-specific infrastructure in icecast. We wouldn't
accept this change back upstream, of course, since mp3 is non-free.

Mike