Debdiff for questing attached. ** Description changed:
- Ubuntu versions - Plucky, Noble, Oracular - pipewire versions - 1.0.5 (noble), 1.3.81(plucky) + [IMPACT] - Upstream link to pipewire bug - https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4464 - https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4114 + Playing audio from on an Ubuntu instance Noble and later, results in duplicated audio samples + after a silence interval (no audio buffer pushed in the pipeline for some time). - The set of patches needs to be identified and back-ported to each series. - This was very difficult to test in a local KVM VM, so a VM from AWS was used to verify fix. + It affects Noble, Oracular, Plucky and Questing. - The problem started because in Noble we've switched from pulseaudio to - pipewire. This issue is not reproducible on pulseaudio. + The problem started because in Noble we've switched from pulseaudio to pipewire. + This issue is not reproducible on pulseaudio. - Experimental pipewire package - https://packages.debian.org/source/experimental/pipewire + Upstream commit (1) is required as a depedency: + https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/cf7e91702417276cbb062ed23fa424ced3864121 - To see the problem happening, you need to install audacity and then - launch 1 terminal + 1 pavucontrol + 1 audacity window and then: + The issue is fixed by upstream commit (2): + https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/c62905d911485369556b68e074b1ec73162ef545 + + + [TEST CASE] + + The issue is not always reproducible. + + Install audacity and then launch 1 terminal + 1 pavucontrol + 1 audacity + window and then: - Start recording on audacity (even without playing anything) - Execute the sample app with "./audio_test test_audio.wav" - Go to pavucontrol and set: --- In the playback tab, pick your audio output for 'audio_test' app --- In the recording tab, pick the "Monitor of" the same audio output device for the audacity app - Stop the recording in audacity and open a new clean audacity window (ctrl+n) - Start recording and immediately jump to the terminal and execute the sample app (./audio_test test_audio.wav) - You will be able to see similar behavior in the audio spectrogram - generated by audacity, when comparing it with the one from the upstream - bug (with the incorrect audio being played from the buffer after the - silence). To make it more visible, you can import the audio file - (test_audio.wav) using File>Import, align and compare them. - - Then, switch from pipewire to pulseaudio and repeat those same steps and - you will see that we can't reproduce the problem anymore. + You will be able to see similar behavior in the audio spectrogram generated by audacity, + when comparing it with the one from the upstream bug (with the incorrect audio being played from the buffer after the silence). To make it more visible, you can import the audio file (test_audio.wav) using File>Import, align and compare them. - ``` - ubuntu@vm:~$ ./audio_test2 test_audio.wav - 2025-01-08 20:09:35.610465 INFO (null) - Init - 2025-01-08 20:09:35.627511 INFO (null) - Setup player - 2025-01-08 20:09:35.627557 DEBUG (null) - Launching pipeline: appsrc is-live=1 do-timestamp=true format=time caps="audio/x-raw,format=S16LE,layout=interleaved,rate=48000,channels=2" name="player_src" ! audioconvert ! audioresample ! queue max-size-buffers=1 silent=true ! pulsesink buffer-time=10000 latency-time=5000 sync=true name="player_sink" - 2025-01-08 20:09:35.632150 INFO (null) - Setup capture: filesrc location=test_audio.wav ! decodebin ! queue !audioconvert name=grabber_convert ! audioresample name=grabber_resample ! audio/x-raw,format=S16LE,layout=interleaved,rate=48000,channels=2 !appsink caps="audio/x-raw" sync=true name=appsink - 2025-01-08 20:09:35.633253 DEBUG (null) - Set capture callback - 2025-01-08 20:09:35.633292 INFO (null) - Start player - 2025-01-08 20:09:35.636397 INFO (null) - Start capture - 2025-01-08 20:09:35.636651 DEBUG (null) - Playback pipeline state changed from NULL to READY - 2025-01-08 20:09:35.636676 DEBUG (null) - Capture pipeline state changed from NULL to READY - 2025-01-08 20:09:35.636714 DEBUG (null) - Playback pipeline state changed from READY to PAUSED - 2025-01-08 20:09:35.643645 DEBUG (null) - Capture pipeline state changed from READY to PAUSED - 2025-01-08 20:09:35.644073 DEBUG (null) - Received buffer after silence (capture pts=0 msec) - 2025-01-08 20:09:35.644111 INFO (null) - Simulate silence - 2025-01-08 20:09:35.644131 DEBUG (null) - Capture pipeline state changed from PAUSED to PLAYING - 2025-01-08 20:09:35.687073 INFO (null) - Simulate silence end - 2025-01-08 20:09:35.687535 DEBUG (null) - Playback pipeline state changed from PAUSED to PLAYING - 2025-01-08 20:09:40.721732 INFO (null) - Simulate silence - ``` + [WHERE PROBLEMS COULD OCUUR] + + This SRU introduces 2 commits. + + (1) https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/cf7e91702417276cbb062ed23fa424ced3864121 + pulse-server: make a function to silence a buffer + + This commit changes the stream_process() function of pulse-server and cuts out some code to turn it into + a function without modifying it. The regression potential here is minimal (no any functional change), however + any potential problem would regard pulse server. + + (2) https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/c62905d911485369556b68e074b1ec73162ef545 + pulse-server: clear old data when jumping forwards + + This commit addresses the issue by checking if a forward jump has happened in the ringbuffer, if so + the samples jumped over are cleared. The change is happens in modules/module-protocol-pulse/server.c. + Any potential regression would affect audio playback. + + + [OTHER] + + Upstream bugs: + https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4464 + https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4114 ** Also affects: pipewire (Ubuntu Questing) Importance: Undecided Status: New ** Changed in: pipewire (Ubuntu Questing) Status: New => Confirmed ** Changed in: pipewire (Ubuntu Plucky) Status: New => Confirmed ** Changed in: pipewire (Ubuntu Oracular) Status: New => Confirmed ** Changed in: pipewire (Ubuntu Noble) Status: New => Confirmed ** Changed in: pipewire (Ubuntu Noble) Importance: Undecided => Medium ** Changed in: pipewire (Ubuntu Oracular) Importance: Undecided => Medium ** Changed in: pipewire (Ubuntu Plucky) Importance: Undecided => Medium ** Changed in: pipewire (Ubuntu Questing) Importance: Undecided => Medium ** Changed in: pipewire (Ubuntu Noble) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: pipewire (Ubuntu Oracular) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: pipewire (Ubuntu Questing) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: pipewire (Ubuntu Plucky) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Patch added: "lp2100497_questing.debdiff" https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2100497/+attachment/5874879/+files/lp2100497_questing.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pipewire in Ubuntu. https://bugs.launchpad.net/bugs/2100497 Title: Duplicated audio sample played after silence Status in pipewire package in Ubuntu: Confirmed Status in pipewire source package in Noble: Confirmed Status in pipewire source package in Oracular: Confirmed Status in pipewire source package in Plucky: Confirmed Status in pipewire source package in Questing: Confirmed Bug description: [IMPACT] Playing audio from on an Ubuntu instance Noble and later, results in duplicated audio samples after a silence interval (no audio buffer pushed in the pipeline for some time). It affects Noble, Oracular, Plucky and Questing. The problem started because in Noble we've switched from pulseaudio to pipewire. This issue is not reproducible on pulseaudio. Upstream commit (1) is required as a depedency: https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/cf7e91702417276cbb062ed23fa424ced3864121 The issue is fixed by upstream commit (2): https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/c62905d911485369556b68e074b1ec73162ef545 [TEST CASE] The issue is not always reproducible. Install audacity and then launch 1 terminal + 1 pavucontrol + 1 audacity window and then: - Start recording on audacity (even without playing anything) - Execute the sample app with "./audio_test test_audio.wav" - Go to pavucontrol and set: --- In the playback tab, pick your audio output for 'audio_test' app --- In the recording tab, pick the "Monitor of" the same audio output device for the audacity app - Stop the recording in audacity and open a new clean audacity window (ctrl+n) - Start recording and immediately jump to the terminal and execute the sample app (./audio_test test_audio.wav) You will be able to see similar behavior in the audio spectrogram generated by audacity, when comparing it with the one from the upstream bug (with the incorrect audio being played from the buffer after the silence). To make it more visible, you can import the audio file (test_audio.wav) using File>Import, align and compare them. [WHERE PROBLEMS COULD OCUUR] This SRU introduces 2 commits. (1) https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/cf7e91702417276cbb062ed23fa424ced3864121 pulse-server: make a function to silence a buffer This commit changes the stream_process() function of pulse-server and cuts out some code to turn it into a function without modifying it. The regression potential here is minimal (no any functional change), however any potential problem would regard pulse server. (2) https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/c62905d911485369556b68e074b1ec73162ef545 pulse-server: clear old data when jumping forwards This commit addresses the issue by checking if a forward jump has happened in the ringbuffer, if so the samples jumped over are cleared. The change is happens in modules/module-protocol-pulse/server.c. Any potential regression would affect audio playback. [OTHER] Upstream bugs: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4464 https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/4114 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/2100497/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
