Default mixer settings for EMU20K2 enable PCM Input on boot while showing it as disabled

[DiegoRivera]

Upon boot, the EMU20K2's PCM input channel is enabled (unmuted), but it shows as disabled (muted) in alsamixer. One has to enable it and disable it in alsamixer in order to ensure sound does not "leak" out.

This is unaffected by alsactl store/restore - even if the asound.state file includes information explicitly turning the PCM input off, alsactl restore fails to automatically fix the issue. One must manually go in and turn PCM input on, then off, to ensure it's really off.

This has been the case for a few Ubuntu releases now. I'm reporting it precisely because it seems it's not been reported (or at least, not getting attention).

[DiegoRivera (diego-rivera)]

There would be a simple workaround if any of the command-line utilities for alsa would allow me to change specific mixer settings. A script could easily be devised to simply turn PCM Input on, then off, and that would be that. Sadly, to my knowledge no such utility exists.

[Raymond (superquad-vortex2)]

do you mean pcm capture switch is off ?

 control.16 {
  iface MIXER
  name 'PCM Capture Switch'
  value false
  comment {
   access 'read write'
   type BOOLEAN
   count 1
  }
 }

[DiegoRivera (diego-rivera)]

Yes, precisely.

Take this sequence:

    Start up the machine
    Boot to Ubuntu
    Log in
    Open sound input settings (gnome-control-center sound, input tab)
    Play some music

The input indicator moves with the music clearly denoting that the PCM capture is enabled. However, alsactl store produces an asound.state file in which the PCM switch is turned off. Opening up alsamixer also shows the item as off. Same with amixer cget. Using alsactl to restore a "correct" asound.state does NOT fix the problem, but if I turn the switch on, then off again (via alsamixer, or amixer, regardless), correct functioning is restored - PCM capture is disabled.

However, if I reboot, the problem shows up again. I haven't tested logout-login after fixing the problem (i.e. if it causes the issue or not), but I don't think it does (will test that shortly).

The workaround is now to have a script that runs at login, turning the switch on, then off, using amixer (new discovery on my part).

However this is only applicable to my case in which I want PCM input to be turned off at the beginning. Other users might want it turned on and/or other input means (microphone, line-in) turned off instead. The issue here is that state isn't being properly restored to where it should - either "something" is altering the card's state post-alsa initialization and state restore, without alsa's knowledge, or alsa isn't restoring the state properly.

Hope this info helps. I'll run the logout-login test shortly and relay the results.

Cheers! Thanks for the quick reply!

[DiegoRivera (diego-rivera)]

As expected, login-logout had no effect. Therefore, it's safe to assume the bug only manifests on a fresh boot. This reinforces the idea that it's either "something" changing the card's state behind ALSA'S back, or ALSA not properly restoring state to the card. The fact that alsactl restore fails to fix the problem but amixer cset works, seems to suggest that alsactl restore may be where the problem lies.

Cheers.

[Raymond (superquad-vortex2)]

http://git.alsa-project.org/?p=alsa-utils.git;a=blob_plain;f=alsactl/init/default;hb=HEAD

if alsactl restore is not executed, try adding o'clock capture switch in alsactl/init/default

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths

how about adding element o'clock in analog-input.common similar to analog.output.common

[DiegoRivera (diego-rivera)]

You lost me - what's the o'clock capture switch? How do I set it? What are the permissible values? It's not documented in the alsactl man page either.

If you give me an example I'll be more than happy to test and relay the results.

[Raymond (superquad-vortex2)]

CTL{name}="PCM Capture Switch",CTL{index}="1",CTL{do_search}=="1", \
  CTL{values}="on"

[DiegoRivera (diego-rivera)]

No effect for the default volume levels setting, the same behavior continues (tested repeatedly).

No idea how to test the other thing you mention, since there's no mention of "PCM Capture" anywhere in those pulseaudio files. Can you offer up a concrete example of what you'd like me to add, and to which file?

[Raymond (superquad-vortex2)]

do you mean "alsactl init" does not turn pcm capture switch on

or "pcm capture volume" need to be unit too ?

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths/analog-output.conf.common

[Element PCM]
switch = mute
volume = merge
override-map.1 = all
override-map.2 = all-left,all-right

http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/mixer/paths/analog-input.conf.common

+[Element PCM]
+switch = on
+volume = merge
+override-map.1 = all
+override-map.2 = all-left,all-right

[DiegoRivera (diego-rivera)]

The simplest definition of the bug is that after bootup, the actual state of the emu20k2 hardware is not accurately reflected in the software (alsamixer, alsactl store). The easiest observable effect (in my case) is the PCM Capture switch - it shows off even though it's functioning as if it were on. Other differences between hardware and software may be exist, but I've not detected them (nor have I searched).

Toggling the switch on, then off, fixes the issue and syncs between hardware and software. However, using alsactl restore has no effect even if the configuration being restored contains the instructions to set the switch to off, and even if the "force" parameter is used (which is the default anyway). I wonder if alsactl compares the hardware state to the new state intended and avoids setting the switch value as an "optimization"...

I'm testing your latest now, will report its effects.

[DiegoRivera (diego-rivera)]

Ok...your latest suggestion (pulseaudio analog-input.conf.common modifications) had no effect. The defect is still present.

Let me know if you'd like me to test something else.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for alsa-driver (Ubuntu) because there has been no activity for 60 days.]

[DiegoRivera (diego-rivera)]

This is still happening in Ubuntu 19.10, and I'm all but certain it will continue to happen with 20.04 when I upgrade to it. I'll verify next weekend when I finally have time for the upgrade.