debcrafters-packages team mailing list archive

[Sebastien Bacher <2100497@xxxxxxxxxxxxxxxxxx>]

The fix for questing will be part of the Debian merge on
https://code.launchpad.net/~seb128/ubuntu/+source/pipewire/+git/pipewire/+merge/486193
which is being reviewed

** Changed in: pipewire (Ubuntu Questing)
     Assignee: Ioanna Alifieraki (joalif) => Sebastien Bacher (seb128)

** Changed in: pipewire (Ubuntu Questing)
       Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of
Debcrafters 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:
  Fix Committed
Status in pipewire source package in Noble:
  Fix Committed
Status in pipewire source package in Oracular:
  Won't Fix
Status in pipewire source package in Plucky:
  Fix Committed
Status in pipewire source package in Questing:
  Fix Committed

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]

  autopkgtest for N, O, P passing.

  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