Bug 48307 - Volume changes can be delayed a lot
Summary: Volume changes can be delayed a lot
Status: RESOLVED MOVED
Alias: None
Product: PulseAudio
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: pulseaudio-bugs
QA Contact: pulseaudio-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-04 11:58 UTC by Tanu Kaskinen
Modified: 2018-07-30 10:19 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Log of delayed rewind (6.98 KB, text/plain)
2012-04-04 11:58 UTC, Tanu Kaskinen
Details

Description Tanu Kaskinen 2012-04-04 11:58:24 UTC
Created attachment 59487 [details]
Log of delayed rewind

This was reported in IRC by "uau". For him, sink volume changes happen with a large delay (like after a second). I have spotted one obvious bug in the source code: when the sink volume is changed, but the software volume doesn't need adjustment, the hardware volume is changed after whatever latency there happens to be at the moment of the volume change request, which tends to be large. If the software volume needs to be changed also, the sink is rewound, which will make the hw volume change happen earlier. So, the missing rewind is messing things up.

That is not the only problem, however. uau is having delays also when the rewind is happening. When I try changing the sink volume on my machine (with the current git master), the rewind happens before the volume change is applied, as expected. But for uau, the rewind appears to happen after the hw volume has been changed, i.e. about a second late. I haven't really investigated yet how that could be possible. uau is using Pulseaudio 1.1, the "current debian unstable version". Here's a log sample: http://fpaste.org/DVTW/

I'll also attach that log, in case the pastebin url becomes stale.
Comment 1 Tanu Kaskinen 2012-04-04 12:28:53 UTC
Actually, the rewind in the log could, and probably is, caused by the event sound stopping, and not because of the volume change.
Comment 2 main.haarp 2014-05-12 01:26:40 UTC
Not sure if this is relevant here, but I'm encountering exactly these 1 to 2-second delays when changing the volume level.

I am doing these changes with amixer and pnmixer, which use the PA alsa-pseudo-device for their mixing. I'll wager that this delay affects all apps using that.

Interestingly, the delay disappears complete when pavucontrol is running (just running, nothing more) while I make thse changes.
Comment 3 Tanu Kaskinen 2014-05-23 13:27:46 UTC
Having pavucontrol running causes pulseaudio to reduce the latency, so that pavucontrol's volume meters don't have too much delay.
Comment 4 trondsg+bugzilla+freedesktop 2014-06-04 12:09:10 UTC
I just had this issue, then it went away. Linux mint 14.04.
Comment 5 GitLab Migration User 2018-07-30 10:19:50 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/348.


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.