2

I got audio working in Arch Linux without problems yesterday, but at some point it stopped working again:

$ alsamixer 
cannot open mixer: No such file or directory
$ vlc foo.mp4
...
[0x7f1388006be8] alsa audio output error: cannot open ALSA device "default": No such file or directory

alsamixer runs fine as root, so it seems to be a permission problem. All the audio devices are owned by root:audio:

$ ls -l /dev/snd
total 0
drwxr-xr-x 2 root root       80 Aug  6 22:54 by-path
crw-rw---- 1 root audio 116,  7 Aug  6 22:54 controlC0
crw-rw---- 1 root audio 116, 10 Aug  6 22:54 controlC1
crw-rw---- 1 root audio 116,  6 Aug  6 22:54 hwC0D0
crw-rw---- 1 root audio 116,  9 Aug  6 22:54 hwC1D0
crw-rw---- 1 root audio 116,  5 Aug  6 22:54 pcmC0D0c
crw-rw---- 1 root audio 116,  4 Aug  6 22:54 pcmC0D0p
crw-rw---- 1 root audio 116,  3 Aug  6 22:54 pcmC0D1p
crw-rw---- 1 root audio 116,  2 Aug  6 22:54 pcmC0D2c
crw-rw---- 1 root audio 116,  8 Aug  6 22:54 pcmC1D3p
crw-rw---- 1 root audio 116,  1 Aug  6 22:54 seq
crw-rw---- 1 root audio 116, 33 Aug  6 22:54 timer
$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/by-path
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/hwC0D0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/hwC1D0
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D1p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D2c
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC1D3p
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
group::rw-
other::---

I'm not in the audio group, as recommended by the ALSA instructions:

$ groups
wheel users

A discussion pointed me to an explanation of why adding the group is unnecessary and sometimes harmful. From there the user groups info said

None of these groups is needed for standard desktop permissions like sound, 3D, printing, mounting, etc. as long as the logind session isn't broken.

Following directions to session permission troubleshooting, I finally found a discrepancy - it says the output of loginctl show-session $XDG_SESSION_ID should contain Remote=no and Active=yes, but I get the following:

$ loginctl show-session $XDG_SESSION_ID
ControlGroupHierarchy=/user
ResetControllers=cpu
NAutoVTs=6
KillExcludeUsers=root
KillUserProcesses=no
IdleHint=yes
IdleSinceHint=0
IdleSinceHintMonotonic=0
InhibitDelayMaxUSec=5s
HandlePowerKey=poweroff
HandleSuspendKey=suspend
HandleHibernateKey=hibernate
HandleLidSwitch=suspend
IdleAction=ignore
IdleActionUSec=30min
PreparingForShutdown=no
PreparingForSleep=no

From there I found info on preserving the session, which doesn't seem to be applicable - my /etc/X11/xinit/xserverrc is unmodified since the installation:

$ ls -l /etc/X11/xinit/xserverrc
-rw-r--r-- 1 root root 132 Oct 31  2012 /etc/X11/xinit/xserverrc

SLiM seems to be running fine:

$ systemctl status slim.service
slim.service - SLiM Simple Login Manager
   Loaded: loaded (/usr/lib/systemd/system/slim.service; enabled)
   Active: active (running) since Sat 2013-08-10 00:00:39 CEST
 Main PID: 258 (slim)
   CGroup: name=systemd:/system/slim.service
           ├─ 258 /usr/bin/slim -nodaemon
           ├─ 292 /usr/bin/X -nolisten tcp vt07 -auth /var/run/slim.auth
           ├─ 416 /usr/bin/gnome-keyring-daemon --daemonize --login
           ├─ 418 awesome
           ├─ 423 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
           ├─ 472 xscreensaver -no-splash
           ├─ 479 firefox
           ├─ 481 java -Xmx192M -jar /usr/share/java/jedit/jedit.jar -reuseview
           ├─ 483 pidgin
           ├─ 485 xterm
           ├─ 500 bash
           ├─ 581 /usr/lib/at-spi2-core/at-spi-bus-launcher
           ├─ 641 xterm
           ├─ 643 bash
           ├─1006 git gui
           ├─1007 wish /usr/lib/git-core/git-gui --
           ├─1367 dbus-launch --autolaunch e943bbb765d74fceb0393a55ceebfd1d --binary-syntax --close-stderr
           ├─1368 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
           ├─1403 ekiga
           ├─1405 /usr/lib/GConf/gconfd-2
           ├─1476 thunar
           ├─1478 /usr/lib/xfce4/xfconf/xfconfd
           └─1589 systemctl status slim.service

What do I need to do to fix the logind session, and thus (presumably) the audio permissions?

  • TheAudioGroup says: "The ConsoleKit daemon automatically switches access to the audio device according to the currently logged in user. It does so by setting access rights to the sound device nodes (i e everything under /dev/snd/* ). You can verify that by downloading the acl package, then running the "getfacl /dev/snd/*" terminal command, it should list the current logged in user as having read and write access." – CL. Aug 7 '13 at 10:51
  • @CL. Nope, see updated answer. – l0b0 Aug 7 '13 at 15:10
  • That loginctl ouptut looks wrong in more ways than just a non-active session. How are you logging in and starting X? – jasonwryan Aug 7 '13 at 18:14
  • @jasonwryan Could you be a bit more specific? I followed the Arch wiki to set up X, SLiM and awesome. Some configuration is linked from there. – l0b0 Aug 8 '13 at 8:25
  • 1
    Your output should look like this; I'd say slim is b0rking your session... – jasonwryan Aug 8 '13 at 8:49
1

The problem was the login_cmd as @jasonwryan hinted; I should have kept the original value rather than following the [SLiM + GNOME keyring][7] on GNOME > 2.30 configuration recommendation:

$ grep login_cmd /etc/slim.conf
# login_cmd           exec /bin/sh - ~/.xinitrc %session
# login_cmd           exec /bin/bash -login ~/.xinitrc %session
login_cmd           exec dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1

After reverting to login_cmd exec /bin/bash -login ~/.xinitrc %session, I now get more sensible session info:

$ loginctl show-session $XDG_SESSION_ID
Id=c1
Timestamp=Fri 2013-08-09 22:30:28 CEST
TimestampMonotonic=11871667
DefaultControlGroup=systemd:/user/1000.user/c1.session
VTNr=7
Display=:0.0
Remote=no
RemoteUser=root
Service=slim
Leader=260
Audit=0
Type=x11
Class=user
Active=yes
State=active
KillProcesses=no
IdleHint=no
IdleSinceHint=0
IdleSinceHintMonotonic=0
Name=username

This actually fixed the primary problem - vlc is able to play videos if I manually set it to use the first HDA Intel audio device.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.