23

Developed an internet radio streamer using jPlayer which utilizes the html5 audio tags with jQuery and has a flash fall back for unsupported browsers. Upon testing the player on the iPhone (iOS 5.0.1), we ran into a very peculiar issue.

When the iPhone is connected to WiFi, it streams perfectly using the HE-AAC V2 stream @ 64kbps 44.1kHz (the preferred codec for apple products). However, when the iPhone is connected to the 3G mobile network, it "stutters" or stops streaming for 1-2 secs every 1-2 minutes (does not stop streaming completely). The troubling thing is when the iPhone is forced to use a separate MP3 stream at the same bit rate, it does not have this issue and works very well on 3G.

UPDATE 5

We recently acquired a 3G/4G Sprint mobile hotspot device and tested this issue with the device. When the iPhone is connected to the mobile hotspot, it shows as being connected to a wifi device and the issue does not render even tho the actual connection is via 3G/4G. This might point back to the issue being with the iPhone not handling HE-AAC via HTTP Live Streaming and when directly connected to the mobile network.

UPDATE 4

Updated the iPhone to iOS 5.1 yet the issue persists.

UPDATE 3

Read here on SO various issues of script not rendering correctly when connected to mobile networks. The finger seems to point to the mobile network carriers that may be inserting Proxy to serve webpages, e.g. for downsizing images. Also it might inject some JavaScript pages. The test page can be found HERE Note: this page is using HE-AAC so it will only work on iPhone...

UPDATE

According to Apple's HTTP Live Streaming doc for iOS devices, that "Audio-only content can be either MPEG-2 transport or MPEG elementary audio streams, either in AAC format with ADTS headers or in MP3 format." Our music server is using OddcastV3 encoder to send out three streams (MP3, HE-AAC V2, and Oggvorbis) to the icecastV2 server. Not sure if the encoder is inserting ADTS headers for the HE-AAC V2 stream. Is there a way to check for this?

RMX
  • 313
  • 5
  • 15
  • that's your business, but my advice for you is to get more reputation on SO and become able to start a bounty for the first question. you can earn reputation answering any topics, not just ios-related. – A-Live Jan 09 '12 at 01:13
  • 1
    Read from Apple's HTTP Live Streaming doc for iOS devices, that "Audio-only content can be either MPEG-2 transport or MPEG elementary audio streams, either in AAC format with ADTS headers or in MP3 format." Not sure if the stream has ADTS headers. Not sure if this is the issue... – RMX Jan 10 '12 at 00:06
  • Here http://developer.apple.com/resources/http-streaming/ on the right side you can find a tool for a stream check. After installation you use it like this: mediastreamvalidator validate --timeout=60 http://ssite.com/track.mp3 You will see the most important issues in the log. – A-Live Jan 18 '12 at 08:16

2 Answers2

1

Comming from a radio planning point of view - here are my two cents:

What you are describing sounds like bandwidth shaping - which is both a common and often neccesary design of radio networks (like 3G networks). In most 3G operators I worked at you would typically optimize your network to give high-speed burst (think downloading an image, sending one email or fetching one HTML page) - over "long-running" high bandwidth services. This is due to the simple fact that this is what most users want/need.

This shaping can on a typical 3GPP (GSM 3G) network result in that you will first get a RAB (radio access bearer) supporting 384kbit and is then downgraded as long as your your device accepts it. This means that typicall you will get switched from 384 -> 256 -> 128, then 64kbit where maybe your device starts recieving data to slowly, then the network upgrades it and again downgrade it after a while.

So why is not then the MP3 file stuttering? my guess is that the total kbit rate might differ - so you are fine in the 64kbit RAB. This is a common phenomena.

Magnus
  • 2,016
  • 24
  • 32
  • you say that "the total size might differ", however there is no total size as this is a streaming radio station and is not downloading a specific size file whether MP3 or HE-AAC. – RMX Jul 03 '12 at 18:26
  • sorry - I meant "total kbit rate". I've updated my answer. Did you do a network snoop (could easily be done using intstruments in the simulator) – Magnus Jul 04 '12 at 21:25
  • Have not done a network snoop. Dont even know what that is! lol – RMX Jul 05 '12 at 21:14
  • Have tested this issue with HE-AAC @ 128kbps and it still occurs. Would you say this is inline with your answer? – RMX Jul 07 '12 at 15:56
  • I think the way forward is to check what is going on the network here. I would propose you run instruments to see what is going on. – Magnus Jul 08 '12 at 21:23
  • I guess what Magnus could be saying that streams labeled as 64kbps may in reality be a bit more or a bit less, with headers etc taken into account, and that may make streams fall on either side of the allocated Radio Access Bearer speed. And if it's even a few more bits, in theory, it could cause the stream to get out of sync and need rebuffering. – RipperDoc Jul 10 '12 at 02:42
  • None of this seems plausible to me. The fact that MP3 works fine where HE-ACC stream fails at the same bit rates (or even lower or higher) seems to point towards the delivery mechanisms and not the mobile networks. It could be a combination of the encoder and stream server (icecast, shoutcast). – RMX Jul 10 '12 at 04:11
0

We have managed to get the exact same thing working. 64kbit AAC-v2 on mobile devices. We are streaming files and not a steady stream, I think Magnus is right when he explains how the network prioritized traffic to bursts, in our case that means we have large parts of the file right away and the player can continue to play until he next burst comes in. In your case that means the stream pauses until the next burst comes.

Either if you can switch to larger chunks in your streaming (larger buffer) or stream whole files instead?

We had a very strange phenomenon with iOS, we had to rename all files from .m4a to .aac to be able to get them streaming on iOS. If we didn't rename them iOS wouldnt play them.

Good luck.

Christian Landgren
  • 13,127
  • 6
  • 35
  • 31
  • Thanks for your input. Unfortunately, we cannot stream whole files as this is built for an internet radio station that streams steadily 24hrs a day. Also this is not an app, instead we are streaming using the HTTP Live Streaming for iOS (directly through mobile Safari), therefore we cannot control buffering. I am still very confused on the whole radio issue. Wouldn't the fact that this issue still occurs at 128k AAC-V2 negate the radio explanation? Also the fact that MP3 works fine at 64kbps...Any insight on understanding this might help us resolve the issue. Thanks again – RMX Jul 21 '12 at 18:17