GNOME Bugzilla – Bug 742271
REGRESSION: Severely distorted sound on changing volume of stream in pulseaudio
Last modified: 2018-11-03 10:47:18 UTC
Created attachment 293666 [details] Arch linux build script for building orc from git Using Arch Linux x86_64 with pulseaudio 5.0-1, orc 0.4.23-1, I'm getting severely distorted audio after I change the volume of a stream, even by just a little. Steps to reproduce $ pulseaudio -k $ # restart pulseaudio if it doesn't start automatically on first use $ man man | espeak # Generate some audio, varying dynamics. In pavucontrol, move the volume slider for the espeak application stream just a little. Actual result: severely distorted audio (almost like white noise, barely discernible speech from espeak). Expected result: clear audio for reasonable volume settings. The problem does not occur for orc 0.4.22 . Building an Arch linux package of orc from git[1], I was able to bisect the problem to this first bad commit: http://cgit.freedesktop.org/gstreamer/orc/commit/?id=a62eefc1dc716046d99aacec208cfdfe42dadb34 Suspecting a breaking ABI change (because of the added struct members), I rebuilt and reinstalled pulseaudio[2], but to no avail, sound remains distorted. [1]: See attached PKGBUILD.orc-git [2]: See attached PKGBUILD.pulseaudio
Created attachment 293667 [details] Arch linux build script for building pulseaudio
Bug report on Arch Linux bug tracker, related issue: https://bugs.archlinux.org/task/43298?project=1&cat%5B0%5D=2&string=orc
I have this problem as well. I played around a bit with the commit Alain mentioned. Here is what I find. The offending lines are 602--606 (in the current version of orc/orccompiler.c): if (loaded != -1) { insn.src_args[i] = loaded; continue; } This is the only place where that commit will affect the rest of the code. I have 2 differrent sound cards, one build-in on the motherborad for output and one inside a usb mic for input. The above code is only called when the usb mic is plugged in and it only affects the sound for the usb one (combined with Alain's test case, it seems both input/output are affected). The "if" part succeeds twice, for different j (seems to be an index for programs) and i (seems to be an index for variables in that program). In both cases, the variable compiler->vars[insn.src_args[i]].name = "p" is referred to the variable compiler->vars[loaded].name = "tmp39" I am happy to help in fixing this if more tests are needed.
Created attachment 293670 [details] Files generated from svolume.orc during the build of pulseaudio
Here are the files generated from svolume.orc during the build of pulseaudio, using orc@c368c33 as latest 'good' commit and orc@a62eefc as first 'bad' commit. There appear to be some interesting differences, hopefully these can be of help in some way.
Sorry, previous upload may be wrong version, I'm superceeding svolume-orc-gen.tar.gz with new version.
Created attachment 293673 [details] Files generated from svolume.orc during the build of pulseaudio
I tried a bit more but was not able to find another way to trigger the said code. It would be nice if orc is known to be used in some other context so it can be checked if that piece of code always fails or the sound system used orc in some unintended way.
*** Bug 742303 has been marked as a duplicate of this bug. ***
It's because the orc code triggers a bug in the parameter loading. Fix is coming.
patch to pulseaudio is here: http://lists.freedesktop.org/archives/pulseaudio-discuss/2015-January/022905.html I also want to fix this in orc.
Thanks. I tested your patch with both pulse-5.0 Arch currently uses and pulse-5.99.2 for the next Arch. It solved the problem for me in both cases.
*** Bug 742710 has been marked as a duplicate of this bug. ***
The PulseAudio patch has been landed now, and will be part of the next release (6.0).
Thanks to all for helping to fix this issue.
Why is this bug still open ? Isn't everything fixed ?
> Why is this bug still open ? Isn't everything fixed ? Comment #11: "I also want to fix this in orc."
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/orc/issues/4.