| Summary: | [GStreamer] Sound loop with Google Hangouts and WhatsApp notifications | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alberto Garcia <berto> | ||||||||||||||||
| Component: | WebKitGTK | Assignee: | Philippe Normand <pnormand> | ||||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||||
| Severity: | Normal | CC: | aakash.kapoor, bugs-noreply, calvaris, ews-watchlist, jdiggs, koalay, mcatanzaro, philn, pnormand, ppaalanen, softrobot | ||||||||||||||||
| Priority: | P2 | ||||||||||||||||||
| Version: | Other | ||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=267809 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Alberto Garcia
2018-09-10 01:23:31 PDT
Reportedly also happens with WhatsApp FWIW I keep getting more reports about this. Is WebAudio broken? This happens for me in Epiphany browser application mode running Mattermost chat app. Every time I get a highlight and it plays a "ding", that "ding" is left on endless loop. Every new highlight opens a new Pulseaudio stream (as seen in pavucontrol) from Epiphany playing "ding" in loop. I'm on Debian with: - libwebkit2gtk-4.0-37:amd64 2.22.5-1 - epiphany-browser 3.30.2-2 I don't know when it started, because this is a fresh install. Can you please get debug logs? GST_DEBUG_NO_COLOR=1 GST_DEBUG=3,webkit*:6 epiphany ... 2> gst.log Created attachment 359144 [details]
Gst debug log from epiphany
This is the log from:
GST_DEBUG_NO_COLOR=1 GST_DEBUG="3,webkit*:6" epiphany --application-mode --profile=...
Someone pings me once in Mattermost, which plays one "ding", which remains looping until I close epiphany.
The uncompressed log is 4 MB.
(In reply to Michael Catanzaro from comment #2) > FWIW I keep getting more reports about this. Is WebAudio broken? This is not related with WebAudio. (In reply to Pekka Paalanen from comment #5) > Created attachment 359144 [details] > Gst debug log from epiphany > Thanks Pekka! So hum it looks like MediaPlayerPrivateGStreamer::play() is called again after EOS. I don't know why yet unfortunately :( It would be great if we could have a standalone test for this, I don't use Hangouts, Mattermost or WhatsApp (in browser). Pekka, can download the Mattermost notification mp3 file and check if the issue happens also when playing the file through a basic <audio> tag? (In reply to Philippe Normand from comment #6) > Pekka, can download the Mattermost notification mp3 file and check if the > issue happens also when playing the file through a basic <audio> tag? If you give me a full example of such HTML file, sure. I wouldn't know how to use an <audio> tag. Do you want it with the same logging as before? A file containing this: <audio autoplay src="uri-goes-here"/> With same logging level yes please :) Created attachment 359153 [details]
Gst debug log from epiphany with simple audio tag
I made a file ding.html with:
<html>
<body>
<audio autoplay src="file:///home/pq/tmp/ding.mp3"/>
</body>
</html>
and ran it with:
GST_DEBUG_NO_COLOR=1 GST_DEBUG="3,webkit*:6" epiphany ./ding.html 2> epiphany-audio-tag.log
Indeed, the ding plays in endless loop, just like in Mattermost in app mode. The Gst log is attached, 2 MB uncompressed.
Can you attach the mp3 file here too? Created attachment 359154 [details]
The notification sound in Mattermost
Here with Ephy 3.30.2 and WebKitGTK 2.22.5 the ding plays one time only. I can also hear it only once (Ephy 3.22.7 and WebKitGTK+ 2.22.5), which is interesting because I do get an infinite sound loop in this same system with the sound notifications from Google Hangouts. *** Bug 196000 has been marked as a duplicate of this bug. *** There's at least 2 issues 1) if the media is remote and the duration query fails, MediaTime::positiveInfiniteTime() is returned from MediaPlayerPrivateGStreamer::durationMediaTime() and that's what triggers the loop With current trunk this no longer happens, at least for the test case reported by Avner. With 2.24 it still happens, most likely because that branch doesn't have the rewritten webkitwebsrc element 2) if the media is local, well Pekka reported a loop issue as well but I can't reproduce that one here, so it will require more investigation. For 1) I plan to clean-up our duration query handling, we used to cache it, we don't anymore but now I think we should :) And not returning positiveInfinite() either, that's not done in the AVF player either, I don't know why we do that... I just tried Google Hangouts with the most recent trunk (r243327) and unfortunately the problem still happens. Created attachment 365713 [details]
Patch
Avner, Berto, anyone, can you please test this patch? Is there a version of WPE I can try this patch on? (In reply to softrobot from comment #19) > Is there a version of WPE I can try this patch on? No, if you want to test this patch, download it and apply it with `patch`. Yes I have added the patch to buildroot to apply on 2.23.91, but the compilation failed. I think there was some error applying the patch, I will get back to it later tonight. For the stable 2.24 branch this might not apply cleanly indeed. Sorry ;) (In reply to Philippe Normand from comment #18) > Avner, Berto, anyone, can you please test this patch? Tested on top of r243420, I confirm that Google Hangouts works fine now, thanks! Created attachment 365858 [details]
Patch
Sorry it took me a while, but I can confirm this patch also works on WPE 2.23.91! Thanks Comment on attachment 365858 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=365858&action=review > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:511 > + MediaTime duration = platformDuration(); > + if (!duration || duration.isInvalid()) > + return MediaTime::zeroTime(); Why zero and not invalid? How is this working with live sources? > Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.h:195 > + mutable MediaTime m_cachedDuration; > + mutable MediaTime m_reportedDuration; I wonder why we have this duality. Can you please explain? That's code copied from the AVF player actually... I should add a comment about it. Comment on attachment 365858 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=365858&action=review >> Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:511 >> + return MediaTime::zeroTime(); > > Why zero and not invalid? > > How is this working with live sources? Live sources use positiveInfinite(), which is valid, I think. Created attachment 365863 [details]
Patch
Comment on attachment 365863 [details] Patch Attachment 365863 [details] did not pass win-ews (win): Output: https://webkit-queues.webkit.org/results/11660814 New failing tests: js/error-should-not-strong-reference-global-object.html Created attachment 365870 [details]
Archive of layout-test-results from ews202 for win-future
The attached test failures were seen while running run-webkit-tests on the win-ews.
Bot: ews202 Port: win-future Platform: CYGWIN_NT-6.1-2.10.0-0.325-5-3-x86_64-64bit
Committed r243489: <https://trac.webkit.org/changeset/243489> (In reply to Philippe Normand from comment #32) > Committed r243489: <https://trac.webkit.org/changeset/243489> \o/ The exact same issue is occurring for me on GNOME Web version 44. Would you consider re-opening the bug? (In reply to aakash.kapoor from comment #34) > The exact same issue is occurring for me on GNOME Web version 44. Would you > consider re-opening the bug? A new bug please |