I can reproduce this very easily joining a flowdock channel, even when I have all sound notifications disabled, it seems we are playing silence all the time. I don't know if this is expected or not, because I don't know anything about web audio. The thing is that the memory of the web process keeps growing all the time while the chat room is open, and never ends growing. Valgrind shows we are leaking the memory of the GstBuffers, see: ==17405== 2,348,346 bytes in 3,542 blocks are definitely lost in loss record 15,722 of 15,730 ==17405== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299) ==17405== by 0x1105D678: g_malloc (gmem.c:94) ==17405== by 0x11075302: g_slice_alloc (gslice.c:1025) ==17405== by 0xE1766E9: _sysmem_new_block (gstallocator.c:416) ==17405== by 0xE181B81: gst_buffer_new_allocate (gstbuffer.c:838) ==17405== by 0xE184EF7: default_alloc_buffer (gstbufferpool.c:234) ==17405== by 0xE184FA5: do_alloc_buffer (gstbufferpool.c:274) ==17405== by 0xE1852EC: default_acquire_buffer (gstbufferpool.c:1130) ==17405== by 0xE18697F: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1261) ==17405== by 0x7182FF4: webKitWebAudioSrcLoop(_WebKitWebAudioSrc*) (in WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37.16.0) ==17405== by 0xE1EBC70: gst_task_func (gsttask.c:334) ==17405== by 0x1107F8DD: g_thread_pool_thread_proxy (gthreadpool.c:307) ==17405== ==17405== 2,349,009 bytes in 3,543 blocks are definitely lost in loss record 15,723 of 15,730 ==17405== at 0x4C2ABAF: malloc (vg_replace_malloc.c:299) ==17405== by 0x1105D678: g_malloc (gmem.c:94) ==17405== by 0x11075302: g_slice_alloc (gslice.c:1025) ==17405== by 0xE1766E9: _sysmem_new_block (gstallocator.c:416) ==17405== by 0xE176820: _sysmem_copy (gstallocator.c:462) ==17405== by 0xE1B3020: gst_memory_make_mapped (gstmemory.c:241) ==17405== by 0xE182C45: gst_buffer_map_range (gstbuffer.c:1737) ==17405== by 0x7153404: WebCore::mapGstBuffer(_GstBuffer*, unsigned int) (in WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37.16.0) ==17405== by 0x7182F8B: webKitWebAudioSrcLoop(_WebKitWebAudioSrc*) (in WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37.16.0) ==17405== by 0xE1EBC70: gst_task_func (gsttask.c:334) ==17405== by 0x1107F8DD: g_thread_pool_thread_proxy (gthreadpool.c:307) ==17405== by 0x1107EF04: g_thread_proxy (gthread.c:784) And this is happening a lot of times per second. I cleaned up the code and added some smart pointers (will submit a patch) to make the code easier to follow and ensure we are not leaking any ref, and indeed we aren't. After a lot of debugging I've realized that GST_BUFFER_FLAG_GAP is the problem. I don't know why or whether it's a GStreamer bug or something we do wrong in WebKit, that's why I opened the bug here first. If I understood the flag correctly, it's actually an optimization, but it's not a problem to remove it because when the channel is silent the memory is filled with 0, so we will not play anything anyway. If that is the case and the bug is actually in GST, I would suggest to remove that until there's a new GST release with the bug fixed.
This is a serious issue and nobody said anything, so I've rolled out r182947. Feel free to close this if someone confirms this is a GST issue.
(In reply to comment #1) > This is a serious issue and nobody said anything, so I've rolled out > r182947. Feel free to close this if someone confirms this is a GST issue. Sounds good to me as a short term solution.
Offending patch rolled out in bug #166922. Patch introducing regression, bug #143869, was subsequently reopened.
Closing.
Turns out this is a bug in GStreamer: https://bugzilla.gnome.org/show_bug.cgi?id=793067