Is iPad app planed?

[MxM]

Sure, one can use iPhone app, but it looks ugly on iPad. Do you plan iPad specific app?

[Mike Louth]

yep

[Lotz]

Originally Posted by Mike Louth

yep

Yay

[syclick]

Just got mine this week, definitely looking forward to a dedicated app.

[MxM]

Do we have to search for iPad version, or will the current app become iPad/iPhone version after an update?

[Mike Louth]

You'll know when it's available.

[Ricer]

Excellent

[MxM]

Originally Posted by Mike Louth

You'll know when it's available.

The reason I was asking is to know what to check to learn about it. Should I check from times to times these boards (I am not doing it usually), or should we check apple store from times to times to see iPad version appearing? Or will update happens automatically? Or will there be a popup in iPhone version running on iPad saying that you can update it? In short, what should I do in order to learn that iPad version available?

[Mike Louth]

It will be a hybrid app, if you're using the iPhone app on your iPad you will get a notification from the App Store when the iPad version is available for download.

[redscull]

So looking forward to an iPad app. Primarily because I use mine landscape, and the iPhone version landscaped is quite squished.

Any chance of adding a user-configurable option for relative buffer size? wifi where I work is fast, but very unreliable, and I have to use the lowest bitrate to achieve uninterrupted playback. If I could specify a larger buffer, it would alleviate that problem and let me listen to higher bitrates. I would buy an in-app purchase just for this feature.

[Ari]

if we do a longer buffer option, you would have to wait longer before playback starts. Is that something that would be okay?

[redscull]

Originally Posted by Ari

if we do a longer buffer option, you would have to wait longer before playback starts. Is that something that would be okay?

Because I don't want to speak for everyone, I would hope that a buffer size change is implemented as an option that defaults to whatever the current value is, that way no one's experience is changed unless they specifically go in and set it.

I fully understand how buffering works and the impacts, and yes, I would love the ability to select a larger buffer (I need about 4x the current one) at the expense of a longer initial wait.

[IanDI]

Originally Posted by redscull

I fully understand how buffering works and the impacts, and yes, I would love the ability to select a larger buffer (I need about 4x the current one) at the expense of a longer initial wait.

iPhone/Android/BB app dev here, I apologize for the long post. Ari asked me to participate directly here.

We get this request occasionally from people with bad connections but unfortunately a larger traditional buffering start-up period would not fix your audio problems. If we make you wait for two minutes to start playing it will just take an additional two minutes before the audio starts dropping out. It would not make it play smoothly. The problem in a nutshell is this:

Assume you store up 2 minutes of audio data (perhaps because a very large buffer is configured), then start playing. Now say your connection drops out for 30 seconds and then comes back. We're getting data again, but because the service is a live stream there's a 30 second "hole" in the audio where we weren't able to tune-in to the stream. 2 minutes from now the audio will skip ahead 30 seconds with an audible pop/blip. Now you have 1 minute 30 seconds of buffer remaining. A couple more 30 second dropouts (with audible glitches each time) and you suddenly have no extra buffer at all. Now every time your connection drops you will hear 30 seconds of silence instead of blips. All that initial waiting just covered up the problem, poorly, for a few minutes. This is a simplified explanation but since you are familiar with buffering you probably understand.

This experience would suck, so we added a technique that very rapidly bursts new data into the buffer when reconnecting to fill any missing audio "holes" back up. In the above example, the second connection that comes in sends with it the extra 30 seconds of audio data you missed and stitches it into where it belongs to allow seamless playback (aka 'seamless reconnect').

We also use the same very large data bursts when you first connect. With a 96kbps public stream you start with a full 30 seconds of audio data in the buffer, downloaded in just 2-5 seconds typically. After we burst down that initial 30 seconds of audio we revert to normal live streaming. If your connection drops out, we reconnect every 5 seconds and attempt to do seamless reconnect. If we cannot get any data before the 30 seconds of burst-buffered audio runs out you hear the audio fade out and a new stream begins from scratch with a new full 30 second burst.

Now to address your issue directly. You said you have better luck with 40kbps streams? This is probably because the way our streams are configured 40kbps gets up to a full 60 seconds of burst size. On premium all bursts are doubled, and we have a slightly more sophisticated hole-filling scheme in use (because we can customize our premium severs), so it's likely that with premium you could use somewhat higher bitrates and still play fine. I would suggest trying the free premium trial in-app on your wifi and let me know if that helps. Obviously fixing the wifi issues (typically by updating the router firmware, easier at home than at work) is really the ideal solution.

As an aside, this experience may be somewhat different than plain dumb buffers on streamers like WinAmp on PC. If anyone cares I can elaborate on why we can't just operate exactly like those in a mobile app.

[redscull]

Me:
I appreciate the detailed reply. Your explanation matches my understanding of buffering. For the record, I am using your premium service. At work, I drop down to 64k AAC (on my iPad) to get "uninterrupted" playback.

Using speedtest.net's iOS app, my download and upload speeds are generally 15-20Mbs (yes, Mb), but my ping is around 250ms, and I know from usage that this "fast" connection is rather unstable with lots of very brief pockets of transfer interruption (which don't impact file upload/download nearly the same way they impact audio/video streaming).

My Detailed Experience:
I can sit and watch the buffer bar, and once ever few seconds, it'll lose 1-5 of the 16 little notches (but almost immediately refill them). Any time it loses all the notches, I get a playback interruption (obviously). From what I can gather visually, it seems that all the bitrates utilize the same amount of buffer because the 1-5 notches I lose on 64k are more like 2-10 on 128k and 4-20 on 256k. It makes sense that a higher bitrate would drain that same buffer faster, and that means higher bitrates have a smaller window of time in which that "data burst" must be received.

My Confusion:
Buffering of any sort is rather pointless unless it includes a rapid burst of data to seamlessly refill the holes. A larger buffer should afford a longer window of time in which to receive that rapid burst before playback is impacted. So I don't understand why a larger buffer wouldn't help me. It seems like the buffer I have, while sufficient to cover lower bitrate playback over the duration of my connection gap, isn't big enough to cover higher bitrate playback over that duration.

30 seconds of buffer seems like it should be more than plenty. Is it 30s regardless of bitrate? Or 30s of 64k which translates to 7.5s of 256k? Either way, that info doesn't align with what the buffer bar appears to be telling me visually, so clearly I am misinterpretting what the bar in the app is conveying.

Does the periodic 5s reconnect burst refill the full 30s buffer when it's successful?

At a 15Mbs connection speed, it should only take about half a second to download 30x256Kb of data. The only way I should be experiencing the problems that I do is if my connection is only active for <0.5s out of every 30s. And I seriously doubt that's the case.

[IanDI]

Originally Posted by redscull

My Confusion:
Buffering of any sort is rather pointless unless it includes a rapid burst of data to seamlessly refill the holes. A larger buffer should afford a longer window of time in which to receive that rapid burst before playback is impacted. So I don't understand why a larger buffer wouldn't help me. It seems like the buffer I have, while sufficient to cover lower bitrate playback over the duration of my connection gap, isn't big enough to cover higher bitrate playback over that duration.

30 seconds of buffer seems like it should be more than plenty. Is it 30s regardless of bitrate? Or 30s of 64k which translates to 7.5s of 256k? Either way, that info doesn't align with what the buffer bar appears to be telling me visually, so clearly I am misinterpretting what the bar in the app is conveying.

Does the periodic 5s reconnect burst refill the full 30s buffer when it's successful?

The only way I should be experiencing the problems that I do is if my connection is only active for <0.5s out of every 30s.

While playing, the bar shows your current download speed as a % of the current bitrate. So when you see it dropping off it means download speed slowed below the 256kbps or whatever rate you have configured. No bars means the connection was lost entirely. If you see a barber-pole alternating pattern it means seamless reconnect was able to recover your connection quickly enough to avoid interruption. Given that your connection's raw speed is pretty high you must be experiencing a LOT of packet loss.

The problem is that for premium we're already bursting (and therefore buffering) up to 1 megabyte of data per connection and that's as high as we can reasonably take it for now. That works out to about 30 seconds at 256Kbps, and proportionally more for the lower bit rates (i.e. about 2 minutes at 64kbps). So it would seem that your wifi connection is bad enough to need 1-2 minutes of buffer under these conditions.

The reconnect burst refills whatever is missing (up to 1 megabyte max). So if the TCP connection was lost for 10 seconds it would download about 15 seconds worth to refill with a little margin for error. Any extra is discarded.

Unfortunately your idea about only having problems "if the connection is active for <0.5s out of every 30s" is flawed because TCP connections operate very poorly under high packet loss situations. They will throttle themselves back so far as to be unusable and then we have to re-establish a new connection, which takes a nontrivial amount of time when your best case ping time is 250ms. It would seem the only solution I have to offer for that particular wifi connection right now is to use the lower bit rate.

Feel free to post any more questions.

[redscull]

Thanks again for the additional responses. So I guess it's my work's high packet loss making it hard for the connection to burst fill me back up. That causes it to eventually give up and start a new connection (with potential playback hiccup) rather than continue trying to refill the holes.

Back on topic: I can't wait for the iPad version, even if it's just layout cleanup for the increased real-estate. Are there any other features planned? Maybe some kind of neat onscreen visualization that moves to the music?

[IanDI]

Originally Posted by redscull

Thanks again for the additional responses. So I guess it's my work's high packet loss making it hard for the connection to burst fill me back up. That causes it to eventually give up and start a new connection (with potential playback hiccup) rather than continue trying to refill the holes.

Back on topic: I can't wait for the iPad version, even if it's just layout cleanup for the increased real-estate. Are there any other features planned? Maybe some kind of neat onscreen visualization that moves to the music?

That is correct. I have some more improvements in mind for these kinds of connections, because they should in theory be able to work, but they won't be coming right away.

The iPad version will surely take advantage of all that screen space with a new layout. Can't talk much more about new features yet.

I do think a visualization (a la G-Force) would be neat personally, but the effect on battery life would be horrifying.

[Teslandroid]

Oh... and Android app too? Cool

[MxM]

Any updates?

[Martin Grey]

seems that iPad app still in the work...

...but I'm looking forward for it hope it will be released in near future.