[PATCH] cmd_vol: Read back volume from mixer after changing it

Discussion:

Thomas Karpiniec

2010-03-14 14:21:27 UTC

Hi all,

A very simple change here which stops the volume percentage in my status
line from lagging the actual setting by one adjustment when I press "="
and "-".

Standard disclaimer: I'm new, so I'm not certain that it's the best fix.
If anyone has any better ways to investigate please let me know. :)

Cheers,

Tom

Gregory Petrosyan

2010-03-14 19:14:40 UTC

Permalink

Post by Thomas Karpiniec
A very simple change here which stops the volume percentage in my status
line from lagging the actual setting by one adjustment when I press "="
and "-".

Good catch! I wonder why it was unnoticed for so long. Nobody on cmus-devel
uses alsa mixer?

Hm, or is this a pulseaudio-alsa-emulation error?

Post by Thomas Karpiniec
Subject: [PATCH] cmd_vol: Read back volume from mixer after changing it
volume_l and volume_r are only updated by the the mixer's get_volume
function. When a new volume is set these values must be read back so
that the status displays back the current volume instead of the
previous volume.
---
command_mode.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/command_mode.c b/command_mode.c
index 7232ac4..0fb145e 100644
--- a/command_mode.c
+++ b/command_mode.c
@@ -1207,6 +1207,7 @@ static void cmd_vol(char *arg)
l = calc_vol(l, volume_l, volume_max, lf);
r = calc_vol(r, volume_r, volume_max, rf);
mixer_set_volume(l, r);
+ mixer_read_volume();
}
update_statusline();
return;

This does not look like *the* fix — ui_curses.c contains code that updates the
volume after waiting on mixer fds or after a timeout, if no fds exist.

My "ALSA on top of PA" setup shows, that mixer_get_fds() in ui_curses.c
returns 1, but select() does not trigger after "-" or "=". Is it the same for
you? If yes, looks like yet another PA bug.

P.S. Am I right that fd_high thing in ui_curses.c is insane and totally wrong?

Gregory

Thomas Karpiniec

2010-03-23 01:07:49 UTC

Permalink

Hi everyone,

I've been doing some experiments on my Debian desktop and Ubuntu netbook
and I'm seeing an astonishing range of behaviour. I'm interested to know
what's supposed to be happening.

This does not look like *the* fix â ui_curses.c contains code that updates the
volume after waiting on mixer fds or after a timeout, if no fds exist.
My "ALSA on top of PA" setup shows, that mixer_get_fds() in ui_curses.c
returns 1, but select() does not trigger after "-" or "=". Is it the same for
you? If yes, looks like yet another PA bug.

Yes, this is the case. There is more sinister stuff going on too though.

The general behaviour I'm seeing is that cmus' volume is directly
changing ALSA's mixer settings. This seems a little odd to me compared
with other applications which have a per-application volume.

I have some fairly sensible results on Debian and some absolutely insane
stuff on Ubuntu:

allanon - Debian Sid w/ ALSA
----------------------------

soft_vol = 0

Mixer has 1 fd and it is activated both when cmus volume is changed with
-/= and when external mixer volume is changed. External mixer has
channels "Master" and "PCM".

cmus volume corresponds directly to the PCM channel 0-100 and this is
reflected in the status line

athabasca - Ubuntu Netbook Remix w/ ALSA (+ PA?)
------------------------------------------------

soft_vol = 0

Mixer has 1 fd and it is activated only when mixer volume is changed
externally, not with -/=.

Changing cmus volume changes external mixer volume (Master, PCM, Front
channels) but this does not activate the fd, causing the lag-by-one bug.

Starting at cmus volume = 100, having accounted for the lag-by-one bug
the following results occur when stepping down:
(L/R) channels where applicable:

CMUS Master PCM Front
100 100 100/100 100/100
90 98 99/99 98/98
80 94 98/98 98/98
70 80 100/100 98/98
60 81 100/100 98/98
50 73 100/100 98/98
40 66 98/98 98/98
30 53 100/100 98/98
20 38 98/98 98/98
10 8 100/100 98/98
0 0 0/0 0/98

If, having gone down, you push up Front, PCM and Master in that order
cmus volume only reaches 9
If, having gone down, you push up Master, PCM and Front in that order,
it gets to about 9, and as soon as you start increasing Front the right
channel stays at 98 and the left channel rises in cmus up towards 100
but on a different linear scale from the mixer.

------------------------------------------------

From this I can conclude:

- Yes there is a bug in the Ubuntu setup such that the fd is not hit
when cmus itself updates the mixer
- cmus does not interact well in Ubuntu if somebody (or something)
starts playing with the ALSA mixer settings directly

Is any of this our fault? I'd like to know if the Debian behaviour is
right, and whether or not the three-channel mess on Ubuntu is actually sane.

Cheers,

Tom

dead_orc

2010-03-23 01:20:38 UTC

Permalink

This post might be inappropriate. Click to display it.

Thomas Karpiniec

2010-03-23 01:44:04 UTC

Permalink

Post by dead_orc
Please, please check if you're running PA (which I strongly assume). PA
started at some point to control not only Master and PCM but any channel
it thinks is worth controlling, and messing with them manually isn't
what it expects I suppose. If you're using PA, the only thing that's
strange is that the system volume is changed and not cmus' own
application volume, but if it's PA, we have the PA OP and do not need to
care about the fucked up ALSA emulation of PA.
There is absolutely no reason for the ALSA mixer to behave that way
without PA, as cmus has it's own setting for which mixer channel to
control (and AFAIK, it doesn't change all the others).

Oh wow, that little bit of understanding has helped so very much. I
didn't even realise there was a pulse OP. Thanks.

That system _is_ running pulseaudio and the pulse OP works great. The
volume in the status line updates like it should (albeit through the
polling method) and system mixer is left entirely alone as far as I can
tell. Therefore the Ubuntu setup is perfect provided you use the right
driver.

The Debian system is using ALSA directly as far as I can tell. Should I
consider it a bug that it's affecting the system PCM level instead of
just its own?

Cheers,

Tom

a.l.e

2010-03-23 07:28:36 UTC

Permalink

Post by Thomas Karpiniec
The Debian system is using ALSA directly as far as I can tell. Should I
consider it a bug that it's affecting the system PCM level instead of
just its own?

personally, i like the way it currently works with alsa and it is what i
would expect from a sane application (flash on youtube not being a sane
application, i don't expect its volume to affect the system's volume).

ciao
a.l.e

Gregory Petrosyan

2010-03-23 09:04:50 UTC

Permalink

Post by Thomas Karpiniec

Oh wow, that little bit of understanding has helped so very much. I
didn't even realise there was a pulse OP. Thanks.
That system _is_ running pulseaudio and the pulse OP works great. The
volume in the status line updates like it should (albeit through the
polling method) and system mixer is left entirely alone as far as I can
tell. Therefore the Ubuntu setup is perfect provided you use the right
driver.

Can you file a bug agains Ubuntu's cmus package, so that they update it to
2.3.1 and make pulse OP default? Without this, cmus package is barely usable
on Ubuntu :-(

Gregory

Thomas Karpiniec

2010-03-23 09:24:28 UTC

Permalink

Post by Gregory Petrosyan
Can you file a bug agains Ubuntu's cmus package, so that they update it to
2.3.1 and make pulse OP default? Without this, cmus package is barely usable
on Ubuntu :-(

Done here: https://bugs.launchpad.net/ubuntu/+source/cmus/+bug/544886

Tom

Thomas Karpiniec

2010-03-23 09:28:30 UTC

Permalink

I should also mention that the "playback problems" I noticed were
unpredictable freezes and delays when resuming from pause, particularly
if I paused for longer periods of time.

Naturally, using the most suitable output plugin has made all of that
perfectly reliable.

Tom

Gregory Petrosyan

2010-03-23 09:45:58 UTC

Permalink

On Tue, Mar 23, 2010 at 12:24 PM, Thomas Karpiniec

Post by Thomas Karpiniec

Post by Gregory Petrosyan
Can you file a bug agains Ubuntu's cmus package, so that they update it to
2.3.1 and make pulse OP default? Without this, cmus package is barely usable
on Ubuntu :-(

Done here: https://bugs.launchpad.net/ubuntu/+source/cmus/+bug/544886

Thanks!

Gregory

dead_orc

2010-03-23 09:41:36 UTC

Permalink

Post by Thomas Karpiniec
Oh wow, that little bit of understanding has helped so very much. I
didn't even realise there was a pulse OP. Thanks.

Oh, okay, in that case: No problem. :)

Post by Thomas Karpiniec
(albeit through the polling method)

That bugged me when I cleaned up the wakeups in player.c, that it still
polled the mixer with pulse OP, but as it seems, the fd that PA provides
via the ALSA emulation doesn't work well, so we have to do with polling...

Post by Thomas Karpiniec
The Debian system is using ALSA directly as far as I can tell. Should I
consider it a bug that it's affecting the system PCM level instead of
just its own?

No, that's not a bug.
ALSA does not have per-application-volume, so cmus' only chance is to
manipulate system volume. If you want a separate volume meter for cmus,
use softvol=1 (BTW, can we disable that for pulse OP or something? PA
provides that already anyway).

Greetings,
dead_orc

Gregory Petrosyan

2010-03-14 19:21:54 UTC

Permalink

While at it, here's a small fix that causes cmus to poll mixer if
mixer_get_fds() returns <= 0.

Gregory

Gregory Petrosyan

2010-03-16 09:39:13 UTC

Permalink

Post by Thomas Karpiniec
A very simple change here which stops the volume percentage in my status
line from lagging the actual setting by one adjustment when I press "="
and "-".

Pushed it to maint.

Gregory