Bug 94466 - Transients with A2DP audio streams
Summary: Transients with A2DP audio streams
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-09 19:00 UTC by Andreas Kloeckner
Modified: 2018-07-30 09:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Debian package info (57.48 KB, text/plain)
2016-03-09 19:00 UTC, Andreas Kloeckner
Details

Description Andreas Kloeckner 2016-03-09 19:00:07 UTC
Created attachment 122181 [details]
Debian package info

I often play audio from my phone through Bluetooth on my computer's
speakers--and that works fantastically. There's only one wrinkle: When a system
notification sound is played, there is a hard-to-describe transient after
playback of the notification sound finishes. At best, there's a noticeable
click. At worst, the A2DP stream plays at the wrong (and often very loud)
volume for a fraction of a second. This happens also for the "plop" feedback
sounds played by the Gnome 3 volume adjustment helper.
Comment 1 Tanu Kaskinen 2016-03-10 10:19:43 UTC
It sounds like an issue with the "deferred volume" feature. The term refers to the need to delay hardware volume changes when synchronizing with software volume changes. It's impossible to reliably make hardware and software volume changes simultaneously, and on your hardware the default parameters don't seem to work that well. The parameters can be tuned in /etc/pulse/daemon.conf, see "man pulse-daemon.conf" for more details.

A simpler workaround is to disable the "flat volumes" feature (many distributions disable it by default). You can do that by putting "flat-volumes = no" to /etc/pulse/daemon.conf.
Comment 2 Andreas Kloeckner 2016-03-10 22:31:04 UTC
Thanks for the pointer. I can confirm that switching to flat volumes actually does successfully work around the issue for me. Nonetheless, I would like to suggest one of the following as a more permanent remedy:

first, rather than trying to exactly time to instantaneous volume adjustments, it might just be easier to try and do a linear blend on both the sink and the stream volumes to get them to their desired states. I am aware that that will result in a bunch of more software complexity, but I do feel that the experience of loud volume transients is sufficiently janky that this may be merited.

On the other hand, if that is not feasible, at least in the short term, it might be worthwhile to disable flat volumes by default. I know I will certainly lobby Debian to disable them.
Comment 3 Andreas Kloeckner 2016-03-10 22:36:07 UTC
Never mind: Plenty of people seem to hate flat volumes already.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674935
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697119
(and further bugs merged into that)
Comment 4 GitLab Migration User 2018-07-30 09:38:33 UTC
-- 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/pulseaudio/pulseaudio/issues/69.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.