[alsa-devel] [RFC, alsa-utils] RFC: alsamixer: Improve description of playback switches
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
* clock source validity (read only switch) * processing features on/off (rw switch) * potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
In this RFC, I suggest to show switches more generic:
[yy] == sound on / clock source is valid / processing feature is on [nn] == sound muted / clock source is invalid / processing feature is off
And give a more generic description in the help.
Signed-off-by: Kirill Marinushkin k.marinushkin@gmail.com Cc: Jaroslav Kysela perex@perex.cz Cc: Takashi Iwai tiwai@suse.de Cc: alsa-devel@alsa-project.org --- alsamixer/mixer_display.c | 8 ++++---- alsamixer/mixer_widget.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/alsamixer/mixer_display.c b/alsamixer/mixer_display.c index b1f79d0..f73b11a 100644 --- a/alsamixer/mixer_display.c +++ b/alsamixer/mixer_display.c @@ -513,13 +513,13 @@ static void display_control(unsigned int control_index) mvwaddch(mixer_widget.window, base_y + 1, frame_left + 1, switches[0] /* TRANSLATORS: playback on; one character */ - ? _("O")[0] | (control->flags & IS_ACTIVE ? attr_ctl_nomute : 0) + ? _("y")[0] | (control->flags & IS_ACTIVE ? attr_ctl_nomute : 0) /* TRANSLATORS: playback muted; one character */ - : _("M")[0] | (control->flags & IS_ACTIVE ? attr_ctl_mute : 0)); + : _("n")[0] | (control->flags & IS_ACTIVE ? attr_ctl_mute : 0)); waddch(mixer_widget.window, switches[1] - ? _("O")[0] | (control->flags & IS_ACTIVE ? attr_ctl_nomute : 0) - : _("M")[0] | (control->flags & IS_ACTIVE ? attr_ctl_mute : 0)); + ? _("y")[0] | (control->flags & IS_ACTIVE ? attr_ctl_nomute : 0) + : _("n")[0] | (control->flags & IS_ACTIVE ? attr_ctl_mute : 0)); }
if (control->flags & TYPE_CSWITCH) { diff --git a/alsamixer/mixer_widget.c b/alsamixer/mixer_widget.c index 0c2b9e0..93d1923 100644 --- a/alsamixer/mixer_widget.c +++ b/alsamixer/mixer_widget.c @@ -210,9 +210,9 @@ static void show_help(void) _("Z X C Decrease left/both/right volumes"), _("B Balance left and right volumes"), "", - _("M Toggle mute"), + _("M Toggle mute / playback switch"), /* TRANSLATORS: or , . */ - _("< > Toggle left/right mute"), + _("< > Toggle left/right mute / playback switch"), "", _("Space Toggle capture"), /* TRANSLATORS: or Insert Delete */
On Mon, 26 Mar 2018 07:11:44 +0200, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
In this RFC, I suggest to show switches more generic:
[yy] == sound on / clock source is valid / processing feature is on [nn] == sound muted / clock source is invalid / processing feature is off
I don't think it's better solution, sorry. The current symbol isn't the best of the best, I admit. But yy/nn isn't better from the visibility POV, and what's worse is the sudden change of user experience on such a long-living application. Also, you can't expect every user understanding English.
If the problem is about the mismatch of mute/non-mute symbol against the switch state, we may blacklist / whitelist the element names. At easiest, we can keep using mute symbol for "xxx Playback Switch". This is very likely a mute control. The rest is neutral, so something more generic symbol can be used for on/off instead of 'M'.
thanks,
Takashi
On 03/26/18 09:38, Takashi Iwai wrote:
On Mon, 26 Mar 2018 07:11:44 +0200, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
In this RFC, I suggest to show switches more generic:
[yy] == sound on / clock source is valid / processing feature is on [nn] == sound muted / clock source is invalid / processing feature is off
I don't think it's better solution, sorry. The current symbol isn't the best of the best, I admit. But yy/nn isn't better from the visibility POV, and what's worse is the sudden change of user experience on such a long-living application. Also, you can't expect every user understanding English.
You are right. Change of symbols will complicate the experience. I agree that we better keep the current ones.
If the problem is about the mismatch of mute/non-mute symbol against the switch state, we may blacklist / whitelist the element names. At easiest, we can keep using mute symbol for "xxx Playback Switch". This is very likely a mute control. The rest is neutral, so something more generic symbol can be used for on/off instead of 'M'.
I faced 2 problems:
* the clock source validity was displayed as [O]. I thought it is a zero, which is the opposite from the real state * I couldn't find how to turn the processing feature on. The help doesn't say anything about it
I agree that we better keep the symbol unchanged. But in the help we need to clarify the use-case. Below is an alternative way to make it clear. What do you think about this?
--- a/alsamixer/mixer_widget.c +++ b/alsamixer/mixer_widget.c @@ -210,9 +210,11 @@ static void show_help(void) _("Z X C Decrease left/both/right volumes"), _("B Balance left and right volumes"), "", - _("M Toggle mute"), + _("M Toggle mute/switch"), /* TRANSLATORS: or , . */ - _("< > Toggle left/right mute"), + _("< > Toggle left/right mute/switch"), + _(" [O] == playback on / switch on"), + _(" [M] == playback muted / switch off"), "", _("Space Toggle capture"), /* TRANSLATORS: or Insert Delete */
thanks,
Takashi
On Mon, Mar 26, 2018 at 11:32 AM, Kirill Marinushkin k.marinushkin@gmail.com wrote:
I faced 2 problems:
- the clock source validity was displayed as [O]. I thought it is a zero, which is the opposite from the real state
- I couldn't find how to turn the processing feature on. The help doesn't say anything about it
A recent patch of mine changed clock source validity from a mixer to a global control, so it should no longer show up in alsamixer.
On 03/26/18 22:41, Andrew Chant wrote:
On Mon, Mar 26, 2018 at 11:32 AM, Kirill Marinushkin k.marinushkin@gmail.com wrote:
I faced 2 problems:
- the clock source validity was displayed as [O]. I thought it is a zero, which is the opposite from the real state
- I couldn't find how to turn the processing feature on. The help doesn't say anything about it
A recent patch of mine changed clock source validity from a mixer to a global control, so it should no longer show up in alsamixer.
Hello Andrew,
Nice! One of the problems is solved. However, the second problem is still actual. As you had a recent experience with alsamixer, what is your opinion?
Best Regards, Kirill
Hi,
On Mar 27 2018 06:13, Kirill Marinushkin wrote:
On 03/26/18 22:41, Andrew Chant wrote:
On Mon, Mar 26, 2018 at 11:32 AM, Kirill Marinushkin k.marinushkin@gmail.com wrote:
I faced 2 problems:
- the clock source validity was displayed as [O]. I thought it is a zero, which is the opposite from the real state
- I couldn't find how to turn the processing feature on. The help doesn't say anything about it
A recent patch of mine changed clock source validity from a mixer to a global control, so it should no longer show up in alsamixer.
Hello Andrew,
Nice! One of the problems is solved. However, the second problem is still actual. As you had a recent experience with alsamixer, what is your opinion?
I think Kirill mentions a patch to change the type of 'iface' for such control elements to 'SNDRV_CTL_ELEM_IFACE_CARD' or 'SNDRV_CTL_ELEM_IFACE_PCM', but I cannot find such patches in Iwai-san's tree[1]. I guess they're not merged yet.
In my humble opinion, if so, Kirill's patch is not better in a view of compatibility, because such smixer controls suddenly disappear via alsa-lib's mixer APIs when the patched kernel is released. In a point of backward compatibility, this kind of change should be avoided, as possible (of cource, depending on the cases).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-n...
Regards
Takashi Sakamoto
On 03/26/18 23:44, Takashi Sakamoto wrote:
Hi,
On Mar 27 2018 06:13, Kirill Marinushkin wrote:
On 03/26/18 22:41, Andrew Chant wrote:
On Mon, Mar 26, 2018 at 11:32 AM, Kirill Marinushkin k.marinushkin@gmail.com wrote:
I faced 2 problems:
- the clock source validity was displayed as [O]. I thought it is a zero, which is the opposite from the real state
- I couldn't find how to turn the processing feature on. The help doesn't say anything about it
A recent patch of mine changed clock source validity from a mixer to a global control, so it should no longer show up in alsamixer.
Hello Andrew,
Nice! One of the problems is solved. However, the second problem is still actual. As you had a recent experience with alsamixer, what is your opinion?
I think Kirill mentions a patch to change the type of 'iface' for such control elements to 'SNDRV_CTL_ELEM_IFACE_CARD' or 'SNDRV_CTL_ELEM_IFACE_PCM', but I cannot find such patches in Iwai-san's tree[1]. I guess they're not merged yet.
Andrew mentioned the patch [2]
In my humble opinion, if so, Kirill's patch is not better in a view of compatibility, because such smixer controls suddenly disappear via alsa-lib's mixer APIs when the patched kernel is released. In a point of backward compatibility, this kind of change should be avoided, as possible (of cource, depending on the cases).
The patch of Andrew and my RFC serve different purposes. They do not replace each other. Patch of Andrew made the "clock valid" global. My RFC is to add the string in the help, to clarify how to toggle the switches in alsamixer.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-n...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=fo...
Regards
Takashi Sakamoto
Hello Takashi Sakamoto, Takashi Iwai, Andrew Chant,
Thank you for the discussion. I saw the drawbacks of my proposal, and it was nice to clarify them with you.
Also, during our discussion I found, that the "description of playback switches" has a different solution. I will check my new idea. If it will work good enough, I will send a patch later.
From my perspective, we can consider this RFC to be closed.
Thanks for your attention.
Best Regards, Kirill
On 03/26/18 23:53, Kirill Marinushkin wrote:
On 03/26/18 23:44, Takashi Sakamoto wrote:
Hi,
On Mar 27 2018 06:13, Kirill Marinushkin wrote:
On 03/26/18 22:41, Andrew Chant wrote:
On Mon, Mar 26, 2018 at 11:32 AM, Kirill Marinushkin k.marinushkin@gmail.com wrote:
I faced 2 problems:
- the clock source validity was displayed as [O]. I thought it is a zero, which is the opposite from the real state
- I couldn't find how to turn the processing feature on. The help doesn't say anything about it
A recent patch of mine changed clock source validity from a mixer to a global control, so it should no longer show up in alsamixer.
Hello Andrew,
Nice! One of the problems is solved. However, the second problem is still actual. As you had a recent experience with alsamixer, what is your opinion?
I think Kirill mentions a patch to change the type of 'iface' for such control elements to 'SNDRV_CTL_ELEM_IFACE_CARD' or 'SNDRV_CTL_ELEM_IFACE_PCM', but I cannot find such patches in Iwai-san's tree[1]. I guess they're not merged yet.
Andrew mentioned the patch [2]
In my humble opinion, if so, Kirill's patch is not better in a view of compatibility, because such smixer controls suddenly disappear via alsa-lib's mixer APIs when the patched kernel is released. In a point of backward compatibility, this kind of change should be avoided, as possible (of cource, depending on the cases).
The patch of Andrew and my RFC serve different purposes. They do not replace each other. Patch of Andrew made the "clock valid" global. My RFC is to add the string in the help, to clarify how to toggle the switches in alsamixer.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/log/?h=for-n...
[2] https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=fo...
Regards
Takashi Sakamoto
Hi,
On Mar 26 2018 14:11, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
Could you show such control elements to help reviewers? For example, output from 'amixer' might be enough.
Regards
Takashi Sakamoto
On 03/26/18 10:19, Takashi Sakamoto wrote:
Hi,
On Mar 26 2018 14:11, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
Could you show such control elements to help reviewers? For example, output from 'amixer' might be enough.
I tried to avoid it, because most probably it will be displayed incorrectly inside the email. I attach it now, but keep in mind that in alsamixer it will look more accurate.
For the new proposal, where we modify only the help, the output will look like this:
│ │ # │ │ │M Toggle mute/switch # │ │ │< > Toggle left/right mute/switch # │ │ │ [O] == playback on / switch on # │ │ │ [M] == playback muted / switch off# │ │ │ │ │
Regards
Takashi Sakamoto
On 03/26/18 10:19, Takashi Sakamoto wrote:
Hi,
On Mar 26 2018 14:11, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
Could you show such control elements to help reviewers? For example, output from 'amixer' might be enough.
Hello Takashi Sakamoto,
I misread your message. You mean the amixer output, not the alsamixer. Below I attach the output from amixer.
$ amixer -c2 Simple mixer control 'Clock Source 15 Validity',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Up Down',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Up Down Mode Select',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 1 Mono: 1 [100%]
Regards
Takashi Sakamoto
Hi,
On Mar 27 2018 03:42, Kirill Marinushkin wrote:
On 03/26/18 10:19, Takashi Sakamoto wrote:
Hi,
On Mar 26 2018 14:11, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
Could you show such control elements to help reviewers? For example, output from 'amixer' might be enough.
Hello Takashi Sakamoto,
I misread your message. You mean the amixer output, not the alsamixer. Below I attach the output from amixer.
$ amixer -c2 Simple mixer control 'Clock Source 15 Validity',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Up Down',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Up Down Mode Select',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 1 Mono: 1 [100%]
Thanks. Then you can see corresponding control elements with the same name in output of 'amixer -c2 contents'. I guess:
$ amixer -c 2 contents | grep -B1 -A1 BOOLEAN ... numid=?,iface=MIXER,name='Clock Source 15 Validity' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=?,iface=MIXER,name='Up Down' ; type=BOOLEAN,access=rw------,values=1 : values=on ...
A control element of 'Up Down Mode Select' is not the one of BOOLEAN type so it's not issued one in your patch.
For example, in my case (E-MU 0404 USB, kernel v4.13):
$ amixer -c 1 ... Simple mixer control 'AnalogueIn Soft Limit ',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Clock rate Selector',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 5 Mono: 0 [0%] Simple mixer control 'DigitalIn CLK source External',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'DigitalOut format: SPDIF/AC3',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off]
These mixer elements are translated by alsa-lib's mixer API implementation from control elements maintained by ALSA control core. In my case:
$ amixer -c 1 contents | grep -B1 -A1 BOOLEAN numid=4,iface=MIXER,name='PCM Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on -- numid=9,iface=MIXER,name='AnalogueIn Soft Limit ' ; type=BOOLEAN,access=rw------,values=1 : values=on -- numid=8,iface=MIXER,name='DigitalIn CLK source External' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=6,iface=MIXER,name='DigitalOut format: SPDIF/AC3' ; type=BOOLEAN,access=rw------,values=1 : values=off
Well, if your aim is just to focus on UI issue, it's enough to change alsamixer. On the other hand, developers tend to add any control element categorized to 'mixer' iface without enough care of its meaning. What you see is this kind of control elements, I guess. If you wish to suppress alsamixer to handle such non-traditional mixer controls (I mean they're not for gain/level/pan/mute etc), it's better to have extra care; e.g. backward compatibility.
Regards
Takashi Sakamoto
On 03/27/18 00:03, Takashi Sakamoto wrote:
Hi,
On Mar 27 2018 03:42, Kirill Marinushkin wrote:
On 03/26/18 10:19, Takashi Sakamoto wrote:
Hi,
On Mar 26 2018 14:11, Kirill Marinushkin wrote:
Currently, all playback switches are described as mute. It is shown as:
[OO] == sound is on (left and right channels) [MM] == sound is muted (left and right channels)
But cards can have different kinds of switch controls, not only mute. At least usb-audio provides boolean controls as playback switches for:
- clock source validity (read only switch)
- processing features on/off (rw switch)
- potentially other similar use-cases
It becames confusing, because it is shown as:
[OO] == clock source is valid [MM] == clock source is invalid
[OO] == processing feature is on [MM] == processing feature is off
And from the help, it is not clear how to toggle such switches.
Could you show such control elements to help reviewers? For example, output from 'amixer' might be enough.
Hello Takashi Sakamoto,
I misread your message. You mean the amixer output, not the alsamixer. Below I attach the output from amixer.
$ amixer -c2 Simple mixer control 'Clock Source 15 Validity',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Up Down',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Up Down Mode Select',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 1 Mono: 1 [100%]
Thanks. Then you can see corresponding control elements with the same name in output of 'amixer -c2 contents'. I guess:
$ amixer -c 2 contents | grep -B1 -A1 BOOLEAN ... numid=?,iface=MIXER,name='Clock Source 15 Validity' ; type=BOOLEAN,access=rw------,values=1 : values=on numid=?,iface=MIXER,name='Up Down' ; type=BOOLEAN,access=rw------,values=1 : values=on ...
A control element of 'Up Down Mode Select' is not the one of BOOLEAN type so it's not issued one in your patch.
For example, in my case (E-MU 0404 USB, kernel v4.13):
$ amixer -c 1 ... Simple mixer control 'AnalogueIn Soft Limit ',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [on] Simple mixer control 'Clock rate Selector',0 Capabilities: volume volume-joined Playback channels: Mono Capture channels: Mono Limits: 0 - 5 Mono: 0 [0%] Simple mixer control 'DigitalIn CLK source External',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off] Simple mixer control 'DigitalOut format: SPDIF/AC3',0 Capabilities: pswitch pswitch-joined Playback channels: Mono Mono: Playback [off]
These mixer elements are translated by alsa-lib's mixer API implementation from control elements maintained by ALSA control core. In my case:
$ amixer -c 1 contents | grep -B1 -A1 BOOLEAN numid=4,iface=MIXER,name='PCM Playback Switch' ; type=BOOLEAN,access=rw------,values=1 : values=on -- numid=9,iface=MIXER,name='AnalogueIn Soft Limit ' ; type=BOOLEAN,access=rw------,values=1 : values=on -- numid=8,iface=MIXER,name='DigitalIn CLK source External' ; type=BOOLEAN,access=rw------,values=1 : values=off numid=6,iface=MIXER,name='DigitalOut format: SPDIF/AC3' ; type=BOOLEAN,access=rw------,values=1 : values=off
Well, if your aim is just to focus on UI issue, it's enough to change alsamixer. On the other hand, developers tend to add any control element categorized to 'mixer' iface without enough care of its meaning. What you see is this kind of control elements, I guess. If you wish to suppress alsamixer to handle such non-traditional mixer controls (I mean they're not for gain/level/pan/mute etc), it's better to have extra care; e.g. backward compatibility.
Hello Takashi Sakamoto,
Maybe there is a misunderstanding. I don't want to suppress non-traditional mixer controls. As I mentioned in the subject, I want to Improve their description. I don't want to change the existing behavior.
I think I will just create an patch, and it will make things clear.
Best Regards, Kirill
Regards
Takashi Sakamoto
participants (4)
-
Andrew Chant -
Kirill Marinushkin -
Takashi Iwai -
Takashi Sakamoto