pause/resume live audio stream causes buffer problems on B2G

[Kumar McMillan]

Hello.
I've been experimenting with a live mp3 stream on an Unagi Firefox OS device (b2g18 build) and I've noticed that pause/resume does not work as I expect. I'd expect the resume to forget anything that was buffered and simply pick up streaming the live data. Instead it tries to play from the buffer which eventually runs out and causes the stream to cut out or become garbled.

I've been able to work around this by creating a pause button that completely destroys the audio object. On resume, it recreates a new audio object. To do this I also had to bust the URL cache with a random query string value.

Is there a better way to pause/resume a live stream?


Here is my current hacky solution:

https://github.com/chirpradio/chirpradio-owa/blob/1c2a1fbd2272aa6f45e78ac83ae4acd4f88fbe65/www/js/index.js#L11-L79

There are instructions for how to install it on a B2G device:
https://github.com/chirpradio/chirpradio-owa/tree/1c2a1fbd2272aa6f45e78ac83ae4acd4f88fbe65#readme

Am I missing an audio property to treat this URL as a live stream? Is it because the server my radio station uses is crap and sends headers like this?

curl -I http://www.live365.com/play/chirpradio
...
curl -I "http://216.235.94.15:80/play?s=chirpradio&d=LIVE365&r=0&membername=&session=1364658048-415284&AuthType=NORMAL&app_id=live365%3Acurl7.24.0x8&SaneID=98.220.12.84-live365%3Acurl7.24.0x86_64appledarwin12.0libcurl7.24.0OpenSSL0.9.8rzlib1.2.5%3Atag_tracker"
HTTP/1.0 200 OK
Content-type: audio/mpeg
Content-Length: 2000000


I have not tried this anywhere except for Unagi devices because it's an mp3 stream and needs the hardware codec. It looks like Unagi is using a Qualcomm mp3 driver. If this seems like a bug let me know and I'll file it.

-Kumar

[Robert O'Callahan]

On Sun, Mar 31, 2013 at 4:54 AM, Kumar McMillan <kumar.m...@gmail.com>wrote:

> I've been experimenting with a live mp3 stream on an Unagi Firefox OS
> device (b2g18 build) and I've noticed that pause/resume does not work as I
> expect. I'd expect the resume to forget anything that was buffered and
> simply pick up streaming the live data. Instead it tries to play from the
> buffer which eventually runs out and causes the stream to cut out or become
> garbled.
>
> I've been able to work around this by creating a pause button that
> completely destroys the audio object. On resume, it recreates a new audio
> object. To do this I also had to bust the URL cache with a random query
> string value.
>
> Is there a better way to pause/resume a live stream?
>

Currently no, because we don't actually know whether your stream is "live"
or not.

Rob
--
q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq
qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq
qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq
qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q
qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq
qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"

[Robert O'Callahan]

But I think we should fix that if we can come up with a good enough
heuristic for determining whether a stream is live. Otherwise maybe we
should add an attribute to indicate liveness.

[Kumar McMillan]

On Saturday, March 30, 2013 2:31:23 PM UTC-5, Robert O'Callahan wrote:
> But I think we should fix that if we can come up with a good enough
>
> heuristic for determining whether a stream is live.

I think coming up with an heuristic would be hard. Servers like Live365 are notorious for using dumb headers (like content-length: 2000000, wat?)

> Otherwise maybe we should add an attribute to indicate liveness.

This sounds like the best solution to me. It's a common use case to open a live streaming URL and the developer is in a good position to make that decision.

Kumar

[Kumar McMillan]

On Saturday, March 30, 2013 2:31:23 PM UTC-5, Robert O'Callahan wrote:

> But I think we should fix that if we can come up with a good enough
>
> heuristic for determining whether a stream is live.

I think coming up with an heuristic would be hard. Servers like Live365 are notorious for using dumb headers (like content-length: 2000000, wat?)

> Otherwise maybe we should add an attribute to indicate liveness.

[Robert O'Callahan]

But if the developer is sending dumb headers, how can they be trusted to
use the liveness attribute correctly?

Would it be reasonable to say that we should treat an HTTP resource as live
if and only if it has no Content-Length? And then try to get providers who
are sending bogus Content-Length to stop sending Content-Length?

[Kumar McMillan]

On Sunday, March 31, 2013 7:02:17 PM UTC-5, Robert O'Callahan wrote:
>
> But if the developer is sending dumb headers, how can they be trusted to
>
> use the liveness attribute correctly?

I think the developer is in a better position to provide a liveness attribute because she is the one building the application (she can explicitly say what kind of stream it is).

In this case, as a developer, I have no control over the streaming server I am connecting to. It's not my server.

>
> Would it be reasonable to say that we should treat an HTTP resource as live
>
> if and only if it has no Content-Length? And then try to get providers who
>
> are sending bogus Content-Length to stop sending Content-Length?
>

That sounds reasonable. Again, it wouldn't help me in this case since I don't have control over the server. Contacting Live365 for any kind of technical help is extremely painful. We are trying to switch streaming providers.

-Kumar

[Kumar McMillan]

On Sunday, March 31, 2013 7:02:17 PM UTC-5, Robert O'Callahan wrote:
>
> But if the developer is sending dumb headers, how can they be trusted to
>
> use the liveness attribute correctly?

I think the developer is in a better position to provide a liveness attribute because she is the one building the application (she can explicitly say what kind of stream it is).

In this case, as a developer, I have no control over the streaming server I am connecting to. It's not my server.

>

> Would it be reasonable to say that we should treat an HTTP resource as live
>
> if and only if it has no Content-Length? And then try to get providers who
>
> are sending bogus Content-Length to stop sending Content-Length?
>

That sounds reasonable. Again, it wouldn't help me in this case since I don't have control over the server. Contacting Live365 for any kind of technical help is extremely painful. We are trying to switch streaming providers.

-Kumar


>
>

[Randell Jesup]

Response I hadn't sent...

On 3/30/2013 3:31 PM, Robert O'Callahan wrote:
> But I think we should fix that if we can come up with a good enough

> heuristic for determining whether a stream is live. Otherwise maybe we

> should add an attribute to indicate liveness

This is related to what happens in WebRTC/getUserMedia streams, which
need to play "live".

I wonder if a (hacky) workaround of assigning to a background media
element, using stream = element.captureStreamUntilEnded(), then
visible_element.mozSrcObject = stream would work.... Roc? This trick
might need access to a setting not visible in JS, though.

This of course assumes you know it's a live remote stream.

--
Randell Jesup, Mozilla

[Robert O'Callahan]

On Sat, Apr 20, 2013 at 4:23 AM, Randell Jesup <rje...@mozilla.com> wrote:

> I wonder if a (hacky) workaround of assigning to a background media
> element, using stream = element.captureStreamUntilEnded(), then
> visible_element.mozSrcObject = stream would work.... Roc? This trick
> might need access to a setting not visible in JS, though.
>

That would work, but it seems ugly.

[Randell Jesup]

On 4/19/2013 6:05 PM, Robert O'Callahan wrote:
> On Sat, Apr 20, 2013 at 4:23 AM, Randell Jesup <rje...@mozilla.com
> <mailto:rje...@mozilla.com>> wrote:
>
> I wonder if a (hacky) workaround of assigning to a background
> media element, using stream = element.captureStreamUntilEnded(),
> then visible_element.mozSrcObject = stream would work.... Roc?
> This trick might need access to a setting not visible in JS, though.
>
>
> That would work, but it seems ugly.

That's because it *is* ugly.... :-)

Randell Jesup