I've had to watch the past several weeks' air.mozilla.org events on chrome, due to hiccups in the playback on firefox nightly channel. This is on OSX, in the vancouver office. Happy to provide further details or assist in diagnostics.
Is it still choppy? Can you provide build specifics?
So, just now Nightly 9.0a1 from 2011-08-23 on MacOS 10.7.1 was choppy watching the default airmozilla stream (intern presentations currently going on). I added the nightly tester tools to get the build id, restarted to Nightly 9.0a1 2010-08-24 and now it's fine.
Yes. Not right off the bat but after a few minutes of watching it changes to a mode where it has a clump of 4 or 5 half-second audio dropouts then 1-2s of audio then another clump of 4-5 more half-second dropouts. Not usable. This is nightly; about:buildconfig says Built from http://hg.mozilla.org/mozilla-central/rev/1881f9b5f8b5 i386-apple-darwin10.2.0 x86_64-apple-darwin10.2.0 What else can I provide?
Graydon, the build config is dated August 19. Can you please try today's nightly (2011-08-24)?
Not perfectly consistent -- sometimes I get period of respite -- so it may well have to do with low bandwidth to the office. On the other hand, same machine and same network it is not an issue on chrome, I can get through full meetings w/o dropouts.
Ah. I'll blame the updater for thinking that was "most recent" (I had just updated before checking). Re-checking the about dialogue is moving me to another one. Tell you in a minute!
Ok. Just applied update to: http://hg.mozilla.org/mozilla-central/rev/198c7de0699d (according to about:buildconfig) and am still getting same dropouts. Something else I should paste in from about:support?
Does this happen on a new profile?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #8) > Does this happen on a new profile? Just checked, yes.
Can you attach a plain-text file containing a paste of your about:support page?
(In reply to Graydon Hoare :graydon from comment #3) > Yes. Not right off the bat but after a few minutes of watching it changes to > a mode where it has a clump of 4 or 5 half-second audio dropouts then 1-2s > of audio then another clump of 4-5 more half-second dropouts. Not usable. This sounds like bug 641273, which I have seen once locally, but have been unable to reproduce in a debug environment.
Has been fine for quite a while now, thanks.