853764 - audio stutter when browsing other tabs

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Maha]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17

Steps to reproduce:

- opened our site http://radioflote.com
- played any channel
- while playing, open new tabs and browse



Actual results:

- audio stutters during playback as the web page in other tabs load


Expected results:

- audio should have been smooth(as it is in Chrome)

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

That Site seems to be broken as it doesn't play any Sound either in Firefox 22 or Chrome 27 (I'm on Win 7 x64).
Also some Channels seem to be "no available".

Comment 2

[Maha]

You may have to wait a bit before the audio starts. 

We have tested this on both Win 7 (x64) and Mountain Lion on the Mac. It works great on both Firefox and Chrome. The only issue we're facing is that when new tabs are opened, the audio tends to break a bit. 

Otherwise Playback is pretty fine. We have a pretty good user base that listens daily.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

Well, not for me.
Is that Service "geoip'ed" perhaps?

Comment 4

[Maha]

Nah, we have listeners from all over.

Anyways, what do we do now? Because its working for a lot of us all over the world,
and we'd love to be able to listen on Firefox as well :)

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

Ok, I now can reproduce the Issue with

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 ID:20130307023931 CSet: 6ffe3e9da8a8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 ID:20130320062118 CSet: 2b185ce3436a
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130322 Firefox/21.0 ID:20130322042013 CSet: c3107b4bd85a

and in Nightly with media.webaudio.enabled;false set.

* load the Site and click on one of the available Play Buttons to get Sound
* either open a second Tab and browse around or open e.g. the Dev Tools and do some Actions there
-> Notice the Stutter in the Sound

As it seems everytime a GC runs the Stutter happens like:


 ----------
CC(T+109.9) duration: 0ms, suspected: 465, visited: 600 RCed and 117 GCed, collected: 0 RCed and 0 GCed (51|764 waiting for GC)
ForgetSkippable 21 times before CC, min: 0 ms, max: 0 ms, avg: 0 ms, total: 0 ms, sync: 0 ms, removed: 3876
CC(T+123.6) duration: 0ms, suspected: 569, visited: 901 RCed and 85 GCed, collected: 0 RCed and 0 GCed (51|1429 waiting for GC)
ForgetSkippable 18 times before CC, min: 0 ms, max: 0 ms, avg: 0 ms, total: 0 ms, sync: 0 ms, removed: 8594
 ----------
GC(T+135.3) Total Time: 86,6ms, Compartments Collected: 10, Total Compartments: 372, Total Zones: 10, MMU (20ms): 0%, MMU (50ms): 0%, SCC Sweep Total: 43,0ms, SCC Sweep Max Pause: 42,3ms, Max Pause: 50,5ms, Allocated: 26MB, +Chunks: 5, -Chunks: 2
    Slice: 0, Pause: 10,2 (When: 0,0ms, Reason: MAYBEGC): Mark Discard Code: 1,4ms, Mark: 8,8ms, Mark Roots: 3,8ms
    Slice: 2, Pause: 50,5 (When: 238,7ms, Reason: REFRESH_FRAME): Sweep: 50,4ms, Mark During Sweeping: 5,5ms, Mark Weak: 0,8ms, Mark Gray: 4,2ms, Mark Gray and Weak: 0,4ms, Finalize Start Callback: 0,4ms, Sweep Compartments: 39,9ms, Sweep Discard Code: 0,8ms, Sweep Tables: 36,2ms, Sweep Cross Compartment Wrappers: 1,1ms, Sweep Base Shapes: 1,4ms, Sweep Intital Shapes: 1,1ms, Sweep Type Objects: 0,7ms, Sweep Breakpoints: 29,7ms, Discard Analysis: 1,8ms, Discard TI: 0,3ms, Free TI Arena: 0,2ms, Sweep Types: 0,3ms, Clear Script Analysis: 0,4ms, Sweep Object: 3,6ms
    Slice: 3, Pause: 5,3 (When: 397,9ms, Reason: INTER_SLICE_GC): Sweep: 5,3ms, Mark During Sweeping: 0,2ms, Finalize Start Callback: 0,2ms, Sweep Atoms: 0,6ms, Sweep Compartments: 0,3ms, Sweep Tables: 0,2ms, Sweep Object: 0,2ms, Sweep String: 0,1ms, Sweep Script: 0,2ms, Sweep Shape: 1,0ms, Finalize End Callback: 1,1ms, Deallocate: 1,2ms
    Totals: Mark Discard Code: 1,4ms, Mark: 29,4ms, Mark Roots: 3,8ms, Sweep: 55,6ms, Mark During Sweeping: 5,6ms, Mark Weak: 0,8ms, Mark Gray: 4,3ms, Mark Gray and Weak: 0,4ms, Finalize Start Callback: 0,6ms, Sweep Atoms: 0,6ms, Sweep Compartments: 40,1ms, Sweep Discard Code: 0,8ms, Sweep Tables: 36,3ms, Sweep Cross Compartment Wrappers: 1,1ms, Sweep Base Shapes: 1,5ms, Sweep Intital Shapes: 1,1ms, Sweep Type Objects: 0,7ms, Sweep Breakpoints: 29,7ms, Discard Analysis: 1,8ms, Discard TI: 0,3ms, Free TI Arena: 0,2ms, Sweep Types: 0,3ms, Clear Script Analysis: 0,5ms, Sweep Object: 3,8ms, Sweep String: 0,2ms, Sweep Script: 0,2ms, Sweep Shape: 1,1ms, Finalize End Callback: 1,1ms, Deallocate: 1,2ms
 ----------
CC(T+137.5) duration: 0ms, suspected: 946, visited: 5011 RCed and 505 GCed, collected: 4500 RCed and 386 GCed (4886|127 waiting for GC)
ForgetSkippable 20 times before CC, min: 0 ms, max: 10 ms, avg: 0 ms, total: 10 ms, sync: 0 ms, removed: 4568
 ----------
GC(T+141.9) Total Time: 76,9ms, Compartments Collected: 10, Total Compartments: 372, Total Zones: 10, MMU (20ms): 0%, MMU (50ms): 13%, SCC Sweep Total: 37,9ms, SCC Sweep Max Pause: 37,4ms, Max Pause: 43,1ms, Allocated: 20MB, +Chunks: 0, -Chunks: 2
    Slice: 0, Pause: 10,1 (When: 0,0ms, Reason: CC_WAITING): Mark Discard Code: 1,0ms, Mark: 9,0ms, Mark Roots: 3,2ms
    Slice: 2, Pause: 43,1 (When: 233,9ms, Reason: INTER_SLICE_GC): Sweep: 43,0ms, Mark During Sweeping: 3,1ms, Mark Weak: 0,7ms, Mark Gray: 2,0ms, Mark Gray and Weak: 0,3ms, Finalize Start Callback: 0,4ms, Sweep Compartments: 38,0ms, Sweep Discard Code: 0,7ms, Sweep Tables: 34,3ms, Sweep Cross Compartment Wrappers: 0,8ms, Sweep Base Shapes: 1,2ms, Sweep Intital Shapes: 0,9ms, Sweep Type Objects: 0,7ms, Sweep Breakpoints: 28,6ms, Discard Analysis: 1,8ms, Discard TI: 0,3ms, Free TI Arena: 0,2ms, Sweep Types: 0,4ms, Clear Script Analysis: 0,5ms, Sweep Object: 0,7ms
    Slice: 3, Pause: 4,3 (When: 380,9ms, Reason: INTER_SLICE_GC): Sweep: 4,2ms, Finalize Start Callback: 0,2ms, Sweep Atoms: 0,6ms, Sweep String: 0,1ms, Sweep Script: 0,2ms, Sweep Shape: 0,9ms, Finalize End Callback: 0,8ms, Deallocate: 1,2ms
    Totals: Mark Discard Code: 1,0ms, Mark: 28,4ms, Mark Roots: 3,2ms, Sweep: 47,2ms, Mark During Sweeping: 3,2ms, Mark Weak: 0,8ms, Mark Gray: 2,0ms, Mark Gray and Weak: 0,3ms, Finalize Start Callback: 0,6ms, Sweep Atoms: 0,6ms, Sweep Compartments: 38,0ms, Sweep Discard Code: 0,7ms, Sweep Tables: 34,3ms, Sweep Cross Compartment Wrappers: 0,8ms, Sweep Base Shapes: 1,2ms, Sweep Intital Shapes: 0,9ms, Sweep Type Objects: 0,7ms, Sweep Breakpoints: 28,6ms, Discard Analysis: 1,8ms, Discard TI: 0,3ms, Free TI Arena: 0,2ms, Sweep Types: 0,4ms, Clear Script Analysis: 0,5ms, Sweep Object: 0,7ms, Sweep String: 0,2ms, Sweep Script: 0,2ms, Sweep Shape: 0,9ms, Finalize End Callback: 0,8ms, Deallocate: 1,2ms
 ----------
CC(T+143.7) duration: 0ms, suspected: 296, visited: 433 RCed and 137 GCed, collected: 24 RCed and 18 GCed (42|90 waiting for GC)
ForgetSkippable 8 times before CC, min: 0 ms, max: 0 ms, avg: 0 ms, total: 0 ms, sync: 0 ms, removed: 6278

Comment 6

[Maha]

Thanks a lot for checking this. Let me know if there's anything we can do at our end to make things easier for the GC. Else, will wait for your resolution. :)

Comment 7

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I'm pretty sure that GC is not the issue here. The max pause for the GCs above is 50.5ms, which isn't too bad. Also, I ran a GC-heavy workload while playing audio and I didn't get any stutter (or at least nothing too noticeable--it was hard to tell). However, browsing around did cause stutter.

I think the most likely problem is that your site needs to use a larger audio buffer. We strive to ensure that Firefox won't introduce long pauses in JS execution, but there's only so much we can do. Using a larger buffer would defend against occasional interruptions.

However, I don't know how the Mozilla audio APIs work. I'm going to transfer this bug to that component just in case there's something we could improve here.

Comment 8

[Matthew Gregan [:kinetik]]

In a nightly build, I don't get audio at all.  The site is detecting support for Web Audio (which was enabled in bug 851603), but then throws the following script error:

  JavaScript error: http://radioflote.com/player/player.min.js, line 9: this.context.createJavaScriptNode is not a function

createJavaScriptNode has been renamed to createScriptProcessor in the Web Audio spec.  It's also not implemented in Gecko yet, that will happen in bug 834513.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

I had to set media.webaudio.enabled to false.

Also, it doesn't work in Linux (on Chrome or Firefox). Mac seems to work.

Comment 10

[Matthew Gregan [:kinetik]]

(Yeah, sorry, I thought it'd be clearer to start a new comment for the other playback path.)

As Bill says, using a larger buffer would help.  For streaming audio, the preferred solution is to write as much as possible via mozWriteAudio.  When the backend buffers are full, mozWriteAudio will return a short write.  It should be possible to buffer ~1s of audio this way.

The script appears to be using a 250ms buffer target (sampleRate / 2, but treated as samples rather than frames, so effectively sampleRate / 2 / 2 for stereo) currently, but as it's using mozCurrentSampleOffset (which is unreliable for buffer size calculations due to bugs).  My recommendation is to change the write logic to use short writes from mozWriteAudio to detect full backend buffers.  This will have higher latency, but for streaming audio that shouldn't be a problem.

Comment 11

[Maha]

Ok, let me hack away at the scripts and see what I can do. 

I checked the streaming logic, everything is perfect, and the streaming player once fully buffered has approcimately one minute of audio data.

So as I understand, the decoder(which is aac.js, a library that I use) is using mozCurrentSampleOffset, instead I should be sending writes via mozWriteAudio, checking for short writes and handling them appropriately.

Correct?

Comment 12

[Matthew Gregan [:kinetik]]

That's right, that'll ensure the backend audio buffers are as full as possible and there's no risk of buffer size misestimation via mozCurrentSampleOffset.

Comment 13

[Maha]

Thanks for the great help Matthew, and everyone else. I followed your advice and have smooth playback now.

Would have been impossible to figure out what was wrong on my own.

Love you all,

Regards,
Maha

Comment 14

[(mostly gone) XtC4UaLL [:xtc4uall]]

So can this be resolved WFM?