Each time I booted in openSUSE, the digital optical line was activated (output of red light from the mini jack port), so after some google searchs, I’ve found how to disable this with the help of ALSA:
Fire up a root shell and launch alsamixer(1)
Use the arrow keys to move around and when over S/PDIF press M to mute (if there’s more than one S/PDIF lines cycle mute through each of those until this turns off the light)
Hit the Escape key - DO NOT CLOSE TERMINAL
Type sudo alsactl store -f /var/lib/alsa/asound.state
This will make it persist across reboots 1. Close the shell
Unfortunately, calling alsamixer(1) from a root shell or with sudo(8) doesn’t work anymore on openSUSE Tumbleweed (20201119 snapshot here) so as a workaround I’ve created the following .desktop file to autostart from your DE a call to alsactl(1):
alsactl --file ~/.config/asound.state store
Create with your favorite editor the alsarestore.desktop file:
Another cleaner way of disabling at boot the S/PDIF on MacBook Pros running Tumbleweed and globally is making systemd(1) handles this with a help of a new service and timer as by default alsa tries to restore /var/lib/alsa/asound.state before the sound card driver is entirely loaded by the kernel.
On a root shell:1. Create a new systemd service “/etc/systemd/system/alsa-restore-delayed.service” with the following content after disabling the S/PDIF output (see my first message of this tread):
Thanks for your inputs. However none of the default timer and systemd services bundled with Tumbleweed works with these laptops.
The S/PDIF is always active despite custom settings set with alsamixer(1) and saved on /var/lib/alsa/asound.state.
At first view, with none of the workarounds I’ve made, leaving Tumbleweed doing its stuff, /var/lib/alsa/asound.state is reseted at each boot no matter what custom settings are saved with alsactl store on /var/lib/alsa/asound.state.
From logs, this shows alsa is trying to apply settings before the sound card driver is fully loaded, thus overwriting custom /var/lib/alsa/asound.state with a new one.
With Leap 15.2, it just works whereas it’s not with Tumbleweed snapshots I’ve tested and actually use, so the last workaround I’ve posted actually works on all of the MacBook Pros I resurrected thanks to openSUSE
**erlangen:~ #** journalctl -b -1 -u alsa-restore.service
-- Logs begin at Sat 2020-11-14 06:05:06 CET, end at Thu 2020-11-26 18:44:19 CET. --
Nov 25 21:05:16 erlangen systemd[1]: Starting Save/Restore Sound Card State...
Nov 25 21:05:17 erlangen systemd[1]: Finished Save/Restore Sound Card State.
Nov 26 18:42:00 erlangen systemd[1]: Stopping Save/Restore Sound Card State...
Nov 26 18:42:00 erlangen systemd[1]: alsa-restore.service: Succeeded.
Nov 26 18:42:00 erlangen systemd[1]: Stopped Save/Restore Sound Card State.
**erlangen:~ #** systemctl status alsa-restore.service
**●** alsa-restore.service - Save/Restore Sound Card State
Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
Active: **active (exited)** since Thu 2020-11-26 18:42:37 CET; 5min ago
Process: 763 ExecStart=/usr/sbin/alsactl restore (code=exited, status=0/SUCCESS)
Main PID: 763 (code=exited, status=0/SUCCESS)
Nov 26 18:42:37 erlangen systemd[1]: Starting Save/Restore Sound Card State...
Nov 26 18:42:37 erlangen systemd[1]: Finished Save/Restore Sound Card State.
**erlangen:~ #**
Did you check conditions?
**erlangen:~ #** systemctl cat alsa-restore.service
**# /usr/lib/systemd/system/alsa-restore.service**
#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#
[Unit]
Description=Save/Restore Sound Card State
**ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
ConditionPathExists=/var/lib/alsa/asound.state
**
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/usr/sbin/alsactl restore
ExecStop=-/usr/sbin/alsactl store
**erlangen:~ #**
You’re welcome
Yes (do note on the following output I have disabled alsa-restore.service but still having the same output if /etc/alsa/state-daemon.conf is there and this service is enabled):
**root@raiatea:/home/matt #** journalctl -b -1 -u alsa-restore.service
-- Logs begin at Sun 2020-11-22 13:30:29 CET, end at Fri 2020-11-27 02:48:05 CET. --
nov. 26 15:46:14 raiatea systemd[1]: Starting Save/Restore Sound Card State...
nov. 26 15:46:14 raiatea systemd[1]: Finished Save/Restore Sound Card State.
nov. 27 02:10:49 raiatea.local systemd[1]: Stopping Save/Restore Sound Card State...
nov. 27 02:10:49 raiatea.local systemd[1]: alsa-restore.service: Succeeded.
nov. 27 02:10:49 raiatea.local systemd[1]: Stopped Save/Restore Sound Card State.
root@raiatea:/home/matt # systemctl status alsa-restore.service
● alsa-restore.service - Save/Restore Sound Card State
Loaded: loaded (/usr/lib/systemd/system/alsa-restore.service; static)
Active: **inactive (dead)**
Condition: start condition failed at Fri 2020-11-27 02:11:07 CET; 38min ago
└─ **ConditionPathExistsGlob=/dev/snd/control* was not met**
nov. 27 02:11:07 raiatea systemd[1]: Condition check resulted in Save/Restore Sound Card State being skipped.
**root@raiatea:/home/matt # **
Also yes:
**root@raiatea:/home/matt #** systemctl cat alsa-restore.service
# /usr/lib/systemd/system/alsa-restore.service
#
# Note that two different ALSA card state management schemes exist and they
# can be switched using a file exist check - /etc/alsa/state-daemon.conf .
#
[Unit]
Description=Save/Restore Sound Card State
ConditionPathExists=!/etc/alsa/state-daemon.conf
ConditionPathExistsGlob=/dev/snd/control*
ConditionPathExists=/var/lib/alsa/asound.state
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=-/usr/sbin/alsactl restore
ExecStop=-/usr/sbin/alsactl store
**root@raiatea:/home/matt # **
Why one of alsa-restore.service’s condition is not met puzzle me and lead me to think that the sound card driver isn’t fully loaded before the service is run. On Leap 15.2 no such problem after muting the S/PDIF in alsamixer(1).
It fixes under Leap 15.2 but not on Tumbleweed (at least on MacBookPro9,2), hence my searches of finding how to apply custom settings to alsa when booting up.
As stated previously, alsa creates a /var/lib/alsa/asound.state with default settings as its trying to restore before the sound card driver is fully loaded.
Anyway, things are fixed now but making this consistent is better (other distributions also are affected; found forum’s threads where Debian, Arch, Manjaro, etc. users does have the same problem), be it a rolling release or not.
One last word about that thread, Macs by default outputs a sound when it boots (called “startup chime” in Apple’s world). If that sound is muted, then the workarounds we have found have to be applied; otherwise no tweaks are needed (be it the sound card is marked as configured or not in YaST’s sound panel)!
Testing was done on two MacBook Pro (a Mid-2012 with an i5 which hasn’t its startup chime muted and a Mid-2012 with an i7 which has its startup chime muted).
To summarize it appears muting the startup chime disable the sound card on Macs’s UEFI, thus default settings on Tumbleweed aren’t good and tweaks have to be done. Dumping efivars on both laptops was of no help, those are equals.
I don’t have a bugzilla’s account (yet!), would you mind please update your PR by adding this note?
There is much interesting detail. I think it’s good practice to wait for sound.target being reached. It ensures required units are loaded and active before further action is taken:
**erlangen:~ #** systemctl list-units '*sound*'
UNIT LOAD ACTIVE SUB DESCRIPTION
sys-devices-pci0000:00-0000:00:01.0-0000:01:00.1-sound-card1.device loaded active plugged Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X]
sys-devices-pci0000:00-0000:00:1f.3-sound-card0.device loaded active plugged 100 Series/C230 Series Chipset Family HD Audio Controller
sound.target loaded active active Sound Card
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
**3 loaded units listed.** Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
**erlangen:~ #**
I don’t have a bugzilla’s account (yet!), would you mind please update your PR by adding this note?
Login to bugzilla with forum credentials should work.
