507919 - <audio> stream regularly gets interrupted.

Status: VERIFIED WORKSFORME

(Core :: Audio/Video, defect)

Description

[John-Paul Harold]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090801 Shiretoko/3.5.3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090801 Shiretoko/3.5.3pre

this seemed to happen to me late last week, 2009-07-30 or thereabouts. The <audio> element will, regularly (although I can't quite reproduce it on demand yet) play the stream but cut out throughout, until it either stops the pauses, or some other reason that causes it to resume usual uninterrupted playback. I haven't managed to figure out a reliable way to reproduce this, but it seems to happens more often than not.

The fault can best be imagined as someone cutting the volume out at regular intervals.

Reproducible: Sometimes




I haven't quite worked out if this is: my code, firefox, linux, or something else. I'm raising a bug here, as I can only reproduce this on Firefox as yet, Midori and Epiphany Webkit are both playing things fine. I've tried using builds of Firefox from around, or just before 2009-07-30 but the issue still remains. This could indicate a linux audio issue, which is only affecting Firefox, and leaving Midori alone.

Comment 1

[cajbir (:cajbir)]

Possibly the same issue as bug 506061? Audio under runs?

Comment 2

[John-Paul Harold]

I've had a look at that bug you mention, it doesn't sound entirely like mine, as I get these issues from a fresh invocation of play(), no need to wait for 26 mins. But, there's a comment about moving the scrubber to fix the problem, which is one reliable way I've found to sort my issue, so I've decided to follow that bug and see if the cure helps this. Hopefully my ticket is a poorly phrased version of bug 506061.

Kind of unrelated, Chrome Browser has a similar issue to 506061 in that the <audio> just stops at around the 15 min mark. But, that's for Chrome developers to worry about.

Comment 3

[John-Paul Harold]

after an update to libpulseaudio in Ubuntu Karmic today, this issue appears to have gone away. Well, I assume libpulseaudio did the trick, it might have been something else. However, this issue I raised a ticket about appears to have gone for now.

I don't know if I can mark bugs resolved or not, but are you happy for this be closed for now?

Comment 4

[Matthew Gregan [:kinetik]]

Thanks for the update.  I see the current version of pulseaudio in karmic is 1:0.9.16~test4-0ubuntu1.  Do you know what version of the library was installed when you were seeing this bug?

Comment 5

[John-Paul Harold]

Like any bad software tester, I didn't make a note of this. However, I've been updating Ubuntu fairly regularly, so I suppose when the issue was raised, I'd have been using the previous version pushed to Karmic. If you know of a way to find this out, a log or some such, I'll have a look.

Comment 6

[Matthew Gregan [:kinetik]]

There are logs in /var/log/dpkg.log (and .1, .2.gz, etc.) which will tell you when a particular version of a package was installed, but you'd need to go back through them looking for a previous version of the same package to work out what you upgraded from.

The link to the package changelog on Ubuntu's package repository website is giving me a 404, but I dug a little deeper and found the older changelog files at http://changelogs.ubuntu.com/changelogs/pool/main/p/pulseaudio/

Probably the interesting change is going from pulseaudio 0.9.15 -> 0.9.16 on August 4.

It's possible that the bug was in pulseaudio and has been fixed in that upgrade.  It's also possible that some unrelated changes in pulseaudio have caused the bug to no longer manifest in the same way, as it seems to be somewhat dependent on timing and buffer sizes.

I'll try installing 0.9.16 locally and see what happens.

Comment 7

[Matthew Gregan [:kinetik]]

It looks like alsa-plugins has been updated recently too.  That package contains a pulseaudio backend plugin that we're using indirectly via the ALSA API, so I'll check that as well.

Comment 8

[John-Paul Harold]

there's been another Ubuntu Karmic update to pulseaudio. Now the issue has returned, but it's limited to the first five seconds or so of audio.

Comment 9

[John-Paul Harold]

again, this issue is still happening. it's gone back to the original scenario where the whole stream jerks along until I drag the scrubber along some, effectively stopping and restarting the audio object.

Am I an isolated case with this bug? Could I offer more in the way of an example? I could give a developer a link to my app which is using <audio>, but it's not something I can make public.

Comment 10

[Matthew Gregan [:kinetik]]

I think this problem is related to what's being worked on in bug 506061, specifically the ALSA/PulseAudio issues.  Once the issues discussed in that bug have been resolved, please retest and let me know if this bug is also fixed.

Comment 11

[Matthew Gregan [:kinetik]]

The patches for bug 506061 have landed, so please retest with today's trunk and let me know if you're still seeing this problem.  Thanks!

Comment 12

[Kent James (:rkent)]

I have a similar experience in a different context.

My ToneQuilla extension for Thunderbird 3.0 and SeaMonkey 2.0 allows the playing of short sound files, typically 4 seconds, as a response to particular emails as determined by a filter action. The current version of ToneQuilla only supports .wav files. In my development version, I added support for .ogg files, and tried to use it as the default. The code to do this is very simple, in a js module I have:

      case "audio/ogg":
        that._audioElement = new that.window.Audio(aSpec);
        that._audioElement.autoplay = true;
        that._audioElement.load();

But when this plays, I get the choppy behaviour of this bug more often than not on portions of the audio. The sound is like the audio is being interrupted 10 or so times per second.

Typically in Thunderbird, when this plays I am in the middle of downloading emails, so there is significant additional activity on the system. The test computer is a relatively slow Pentium M tablet running Windows XP. The ogg files play fine when there is no activity on the system.

Comment 13

[Matthew Gregan [:kinetik]]

That's probably bug 484814.  I think this bug is Linux specific.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

Does this problem still exist? We've fixed a bunch of Linux audio bugs recently, can someone who experienced this problem retest on an up to date nightly?

Comment 15

[Matthew Gregan [:kinetik]]

Nobody reported further problems after I asked in comment 10, no point keeping this open any longer.  Please file new bugs if you're having problems with audio playback.