delayed volume changes

[majuscule]

Subject of the issue

I have a very strange issue where volume changes are extremely delayed (5-10 seconds to take effect).

Your environment

• 2019.02.14
• 5.0.0-arch1-1-ARCH x86_64
• config file is user/pass/event_command (catching only songstart)
• alsa-lib 1.1.8-1

Steps to reproduce

Start pianobar, adjust sound with ( or ).

Expected behaviour

Volume should change immediately.

Actual behaviour

Volume takes several seconds to begin adjusting, and then slowly fades to the correct volume.

Additional notes

Adjusting volume with alsamixer is instantaneous.

[PromyLOPh]

This is caused by audio buffering inside pianobar. There’s one thread decoding audio and applying filters (like volume adjustment) and another one playing these frames. The default buffer size between them is five seconds, but you reduce the latency by lowering the setting buffer_seconds, if you have a fast computer.

[majuscule]

That makes sense but I am confused as to why this is the first time I am seeing this behavior. I have used pianobar on several machines, and this happens to be the "fastest" I've ever tried it on (intel i7-8700k, 12 cores (hyperthreaded) @ 3.7ghz). Does lowering buffer_seconds have any other side effects such as worse performance during brief internet disconnections?

[majuscule]

For that matter, I'm fairly certain that this was not always the case. I remember using pianobar on this box without this issue some time ago.

[PromyLOPh]

Does lowering buffer_seconds have any other side effects such as worse performance during brief internet disconnections?

It mostly affects low-end machines that can’t keep up with decoding when other processes consume a lot of CPU time. In the past this caused stuttering and weird audio artifacts on these machines.

For that matter, I'm fairly certain that this was not always the case. I remember using pianobar on this box without this issue some time ago.

Buffering was introduced by commit bbbdd99, so you’re right, this behavior is new.

[majuscule]

Been a while; setting buffer_seconds = 0 did resolve the issue for me. I'd argue it's still a bug that the default configuration gives this issue for machines capable of quick decoding, but if you'd like to close this issue it's fine by me. Thank you for pianobar & your help!

[PromyLOPh]

No, it is a bug, so I’ll leave it open. I just don’t know how to solve this right now.