Bug 162860 – [GStreamer] Audio glitches

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Media

Hello,

I just tried Epiphany and I noticed audio glitches when I played radio paradise (webradio - https://www.radioparadise.com). The stream work well in Firefox. I'm on Fedora 24, WebKitGTK 2.12.5. 
I already reported the bug against Epiphany but they asked me to report here (https://bugzilla.gnome.org/show_bug.cgi?id=772294)

If you need some particular infos to fix this, I will be pleased to provide them :)

Thanks !

[Philippe Normand]

Seems like this website uses Flash?

No it don't. I don't have flash installed.

[Michael Catanzaro]

I see JavaScript errors:

[Error] TypeError: undefined is not an object (evaluating 'soundManager.getSoundById('rp').readyState')
	reStart (rp2_player_1.php:100)
	Global Code (Script Element 1:1)

Generally, I would say the presence of JS errors indicates the website is broken unless the website developers tell us they think otherwise.

[Michael Catanzaro]

(In reply to comment #1)
> Seems like this website uses Flash?

Why do you say that?

[Michael Catanzaro]

Wait, you say "audio glitches." Were you able to get sound at all? I hear nothing. Maybe they're using an encumbered codec like MP3?

(In reply to comment #5)
> Wait, you say "audio glitches." Were you able to get sound at all? I hear
> nothing. Maybe they're using an encumbered codec like MP3?

I think they use MP3. I tried some other stream in MP3 and the glitches are here too. I tried some Ogg vorbis stream and there was no glitch !

I use RPMfusion repo for MP3 support. Can this be a problem with the repo ?

[Philippe Normand]

This plays without glitches here on Debian Testing (after having removed the Flash plugin, which is used by this website if installed).

Do you also hear glitches with this command?

gst-play-1.0 http://stream-uk1.radioparadise.com/mp3-192?1475769631


In this case WebKit doesn't do anything fancy with the audio rendering, so if the gst-play-1.0 command above also shows glitches, you should report the bug in GNOME's Bugzilla against the GStreamer product. Sorry for the various bugzilla redirections :)

No glitch with gst-play-1.0. On the other hand there is glitches even with the stream URL in Epiphany.

[Philippe Normand]

(In reply to comment #8)
> No glitch with gst-play-1.0. On the other hand there is glitches even with
> the stream URL in Epiphany.

This doesn't make much sense.
Can you add this option to gst-play-1.0 ? --audiosink="scaletempo ! audioconvert ! audioresample ! autoaudiosink"

This should replicate the same audio rendering chain as used in WebKit.

The "?" seem to pose problem 

Lecture en cours de /home/jeremy/?
ERROR Ressource introuvable. for file:///home/jeremy/%3F
ERROR debug information: gstfilesrc.c(530): gst_file_src_start (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstFileSrc:source:
No such file "/home/jeremy/?"

So I used this command

gst-play-1.0 --audiosink="scaletempo ! audioconvert ! audioresample ! autoaudiosink" http://stream-uk1.radioparadise.com/mp3-192?1475769631

No glitch too

Oh I re-read your comment and that was a question :D

The problem is still here :(

Same problem on Fedora 25

[Charlie Turner]

This played fine using MiniBrowser from a nightly build.

I had the same issue as Michael using Epiphany from f25 linked again 2.16.3.

[Charlie Turner]

I don't hear glitches, and I suspect the issue heard was fixed by r218703, which could non-deterministically cause horrible audio glitches in Icecast streams.

Thanks. In which webkitgtk version I will be able to test that ?

[Charlie Turner]

Jeremy, 2.16.6

Fedora 25 just had the 2.16.6 version and the problem is still here :(

[Charlie Turner]

Sorry Jeremy, it looks like r218703 wasn't merged into the 2.16.6 branch. I'm going to propose it for merging and I'll update you again.

[Charlie Turner]

This is now proposed for merging into 2.16.7: https://trac.webkit.org/wiki/WebKitGTK/2.16.x

I can confirm it's fixed !
Thanks !

[Radar WebKit Bug Importer]

<rdar://problem/34736614>

With webkitgtk4-2.18.2 (and epiphany-3.26.1), this seems to be mostly fixed, but not entirely.

With WebKit 2.16.x, I experienced regular glitches (slight audio discontinuity every half-second or so, which continued the entire time the stream played.

With 2.18.2, audio streams start with the same half-second glitches, but they reliably go away after 4-5 seconds of playback.

On e.g. Firefox or various stream-capable media players, there are no glitches at any point.

[Michael Catanzaro]

Is there a specific website you can reproduce this problem on?

Several radio streams at least.

E.g.:

http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio1_mf_p
http://media-ice.musicradio.com/ChillMP3
http://icy-e-ba-07-boh.sharp-stream.com:8000/kissnational.mp3
https://ais.absoluteradio.co.uk/absoluteradiomed.aac (needs to be contained in an <audio> element to be played instead of downloaded, at least in Epiphany/Web)
http://radio.virginradio.co.uk/stream

[Michael Catanzaro]

OK, I can hear it sometimes, but not always. It seems to happen more often on the first stream, at least for me.

Interesting, happens every time on each one for me, though it's difficult to hear if it's spoken word (e.g. advertising, which seems to be sometimes pre-rolled on some of those streams).

The Absolute Radio AAC stream (https://ais.absoluteradio.co.uk/absoluteradiomed.aac) is especially obvious - plays back with errors at 150-200% speed for the first 4 or so seconds.

The Chill stream should also be useful to reproduce since it uses an identical pre-roll at each stream start.

[Philippe Normand]

(In reply to webkit from comment #27)
> Interesting, happens every time on each one for me, though it's difficult to
> hear if it's spoken word (e.g. advertising, which seems to be sometimes
> pre-rolled on some of those streams).
> 
> The Absolute Radio AAC stream
> (https://ais.absoluteradio.co.uk/absoluteradiomed.aac) is especially obvious
> - plays back with errors at 150-200% speed for the first 4 or so seconds.
> 
> The Chill stream should also be useful to reproduce since it uses an
> identical pre-roll at each stream start.

I can reproduce the issue on Absolute Radio AAC but it's not a playback speed issue. Seems more like the initial ICY metadata isn't correctly parsed.

I don't think it's a playback speed issue with the Absolute stream it sounds like it's just not successfully getting ~ every second packet for the first few seconds, and then playing the remaining (buffered) ones without any gaps for the missing packets. So it's normal pitch, but sounds "double-speed" (i.e. like a "time stretch" high-speed playback, rather than a "chipmunk" high speed playback).

Are you hearing something different from that? I just re-tested and it's still doing the same thing on that stream.

I suspect that the behaviour (no silence inserted for missing packets) is the same on the other streams, and it' just there is a lower ratio of missing packets for the glitchy few seconds on the other streams. So something like:

Absolute: 13579 etc. (10-packet section played back in 5-packet time)
Others: 12456790 etc. (10-packet section played back in 8-packet time)

Instead of:

Absolute: 1.3.5.7.9. etc.
Others: 12.4567.90 etc.

Where "." represents a one packet-duration silence.

[Philippe Normand]

Created attachment 330461 [details]
patch

Can you test this patch please?

I tried to build from the latest Fedora 27 SRPM for webkitgtk4 (2.18.4-1), and though the patch applies fine, there's an eventual build error unfortunately. I haven't tried building without the patch to see if it still fails.

[Philippe Normand]

(In reply to webkit from comment #31)
> I tried to build from the latest Fedora 27 SRPM for webkitgtk4 (2.18.4-1),
> and though the patch applies fine, there's an eventual build error
> unfortunately. I haven't tried building without the patch to see if it still
> fails.

Ah well, don't bother. It seems to be yet another bug in our httpsrc element because if I disable it, there is no glitch.

[Charlie Turner]

Bug 182829 contains a patch that helps this issue quite a bit. Instead of ~4s of bad audio, it's about 1/2 s. That's still not good enough though.

I'm testing the absolute radio stream.

[Xabier Rodríguez Calvar]

Comment on attachment 330461 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=330461&action=review

It would be awesome if you could explain why this improves the situation as I see several things but I fail to understand why they work together.

> Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:873
> -    // Emit a GST_EVENT_CUSTOM_DOWNSTREAM_STICKY event to let GStreamer know about the HTTP headers sent and received.
> +    // Emit a GST_EVENT_CUSTOM_DOWNSTREAM_STICKY event and message to let
> +    // GStreamer know about the HTTP headers sent and received.
>      GstStructure* httpHeaders = gst_structure_new_empty("http-headers");
> -    gst_structure_set(httpHeaders, "uri", G_TYPE_STRING, priv->originalURI.data(), nullptr);
> +    gst_structure_set(httpHeaders, "uri", G_TYPE_STRING, priv->originalURI.data(),
> +                      "http-status-code", G_TYPE_UINT, response.httpStatusCode(), nullptr);

You can keep this in a single line.

> Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:888
> +    gst_element_post_message(GST_ELEMENT_CAST(src), gst_message_new_element(GST_OBJECT_CAST(src),
> +        gst_structure_copy(httpHeaders)));

ditto

[Philippe Normand]

(In reply to Xabier Rodríguez Calvar from comment #34)
> Comment on attachment 330461 [details]
> patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=330461&action=review
> 
> It would be awesome if you could explain why this improves the situation as
> I see several things but I fail to understand why they work together.
> 
> > Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:873
> > -    // Emit a GST_EVENT_CUSTOM_DOWNSTREAM_STICKY event to let GStreamer know about the HTTP headers sent and received.
> > +    // Emit a GST_EVENT_CUSTOM_DOWNSTREAM_STICKY event and message to let
> > +    // GStreamer know about the HTTP headers sent and received.
> >      GstStructure* httpHeaders = gst_structure_new_empty("http-headers");
> > -    gst_structure_set(httpHeaders, "uri", G_TYPE_STRING, priv->originalURI.data(), nullptr);
> > +    gst_structure_set(httpHeaders, "uri", G_TYPE_STRING, priv->originalURI.data(),
> > +                      "http-status-code", G_TYPE_UINT, response.httpStatusCode(), nullptr);
> 
> You can keep this in a single line.
> 
> > Source/WebCore/platform/graphics/gstreamer/WebKitWebSourceGStreamer.cpp:888
> > +    gst_element_post_message(GST_ELEMENT_CAST(src), gst_message_new_element(GST_OBJECT_CAST(src),
> > +        gst_structure_copy(httpHeaders)));
> 
> ditto

I wasn't expecting a review of this patch. Some of its changes were merged some weeks ago though, as part of other bugs.

[Xabier Rodríguez Calvar]

(In reply to Philippe Normand from comment #35)
> I wasn't expecting a review of this patch. Some of its changes were merged
> some weeks ago though, as part of other bugs.

I assumed it was WIP and you probably wanted feedback.

[Philippe Normand]

I think this can be closed, the behavior in gst-play and webkit are now the same, at least for the absolute AAC stream which had glitches in the past for us.

Please re-open again otherwise :)