[arch-general] No user sound - only root has access alsamixer on virtualbox?
Guys, I've run into a problem with sound on a new archlinux guest install on virtualbox (v4.36). Only root can see/access the sound system. From the asla page, I've tried 'alsactl init' and I've also tried adding user to the audio group as mentioned in old forum pages, but still only root sees sound. The guest is a fully updated Arch install (with updates through today) Here are the details: As user: 19:46 valhalla:~> alsamixer cannot open mixer: No such file or directory 19:51 valhalla:~> cat /proc/asound/cards 0 [I82801AAICH ]: ICH - Intel 82801AA-ICH Intel 82801AA-ICH with STAC9700,83,84 at irq 11 19:53 valhalla:~> lsmod | grep snd snd_intel8x0 23757 0 snd_ac97_codec 89404 1 snd_intel8x0 ac97_bus 878 1 snd_ac97_codec snd_pcm 63880 2 snd_ac97_codec,snd_intel8x0 snd_page_alloc 5978 2 snd_intel8x0,snd_pcm snd_timer 14946 1 snd_pcm snd 44598 4 snd_ac97_codec,snd_intel8x0,snd_timer,snd_pcm soundcore 4386 1 snd 20:00 valhalla:~> aplay -l aplay: device_list:268: no soundcards found... 20:00 valhalla:~> aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default Default ALSA Output (currently PulseAudio Sound Server) As root: [20:01 valhalla:/home/david] # alsamixer (works fine) No protocol specified xcb_connection_has_error() returned true [20:02 valhalla:/home/david] # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I82801AAICH [Intel 82801AA-ICH], device 0: Intel ICH [Intel 82801AA-ICH] Subdevices: 1/1 Subdevice #0: subdevice #0 [20:02 valhalla:/home/david] # aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default Default ALSA Output (currently PulseAudio Sound Server) sysdefault:CARD=I82801AAICH Intel 82801AA-ICH, Intel 82801AA-ICH Default Audio Device front:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH Front speakers surround40:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 4.0 Surround output to Front and Rear speakers surround41:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 5.1 Surround output to Front, Center, Rear and Subwoofer speakers iec958:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH IEC958 (S/PDIF) Digital Audio Output I have since removed the user from audio group since it didn't help. I cannot find a solution. Any thoughts? -- David C. Rankin, J.D.,P.E.
On 02/02/2014 03:14 AM, David C. Rankin wrote:
Guys,
I've run into a problem with sound on a new archlinux guest install on virtualbox (v4.36). Only root can see/access the sound system. From the asla page, I've tried 'alsactl init' and I've also tried adding user to the audio group as mentioned in old forum pages, but still only root sees sound. The guest is a fully updated Arch install (with updates through today) Here are the details:
As user:
19:46 valhalla:~> alsamixer cannot open mixer: No such file or directory
19:51 valhalla:~> cat /proc/asound/cards 0 [I82801AAICH ]: ICH - Intel 82801AA-ICH Intel 82801AA-ICH with STAC9700,83,84 at irq 11
19:53 valhalla:~> lsmod | grep snd snd_intel8x0 23757 0 snd_ac97_codec 89404 1 snd_intel8x0 ac97_bus 878 1 snd_ac97_codec snd_pcm 63880 2 snd_ac97_codec,snd_intel8x0 snd_page_alloc 5978 2 snd_intel8x0,snd_pcm snd_timer 14946 1 snd_pcm snd 44598 4 snd_ac97_codec,snd_intel8x0,snd_timer,snd_pcm soundcore 4386 1 snd
20:00 valhalla:~> aplay -l aplay: device_list:268: no soundcards found...
20:00 valhalla:~> aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default Default ALSA Output (currently PulseAudio Sound Server)
As root:
[20:01 valhalla:/home/david] # alsamixer (works fine) No protocol specified xcb_connection_has_error() returned true
[20:02 valhalla:/home/david] # aplay -l **** List of PLAYBACK Hardware Devices **** card 0: I82801AAICH [Intel 82801AA-ICH], device 0: Intel ICH [Intel 82801AA-ICH] Subdevices: 1/1 Subdevice #0: subdevice #0
[20:02 valhalla:/home/david] # aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default Default ALSA Output (currently PulseAudio Sound Server) sysdefault:CARD=I82801AAICH Intel 82801AA-ICH, Intel 82801AA-ICH Default Audio Device front:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH Front speakers surround40:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 4.0 Surround output to Front and Rear speakers surround41:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 4.1 Surround output to Front, Rear and Subwoofer speakers surround50:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 5.0 Surround output to Front, Center and Rear speakers surround51:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH 5.1 Surround output to Front, Center, Rear and Subwoofer speakers iec958:CARD=I82801AAICH,DEV=0 Intel 82801AA-ICH, Intel 82801AA-ICH IEC958 (S/PDIF) Digital Audio Output
I have since removed the user from audio group since it didn't help. I cannot find a solution. Any thoughts?
Seems like you installed pulseaudio but you aren't running it. pulseaudio usually runs as normal user and not as root user - that's why root uses "raw alsa", and normal user uses "alsa through pulseaudio". -- Note: My last name is not Krejzi.
On 02/01/2014 08:54 PM, Armin K. wrote:
Seems like you installed pulseaudio but you aren't running it. pulseaudio usually runs as normal user and not as root user - that's why root uses "raw alsa", and normal user uses "alsa through pulseaudio".
Hmm.. You are correct. But installing pulseaudio-alsa which provides /etc/asound.conf: # Use PulseAudio by default pcm.!default { type pulse fallback "sysdefault" hint { show on description "Default ALSA Output (currently PulseAudio Sound Server)" } } ctl.!default { type pulse fallback "sysdefault" } Has always taken care of this automatically before. However, this is the first build of Trinity on Arch that does not rely on hal, so there may be more required to get sound going for normal users. I have started pulseaudio, but as of yet, I cannot get sound configured and working. Sound has always been tricky when it is not working. Here, apparently root works just fine using "raw alsa", but then what to do for the users. I'll keep picking around, if you have any other suggestions, please let me know. Thanks. -- David C. Rankin, J.D.,P.E.
On 02/02/2014 05:23 AM, David C. Rankin wrote:
On 02/01/2014 08:54 PM, Armin K. wrote:
Seems like you installed pulseaudio but you aren't running it. pulseaudio usually runs as normal user and not as root user - that's why root uses "raw alsa", and normal user uses "alsa through pulseaudio".
Hmm.. You are correct. But installing pulseaudio-alsa which provides /etc/asound.conf:
# Use PulseAudio by default pcm.!default { type pulse fallback "sysdefault" hint { show on description "Default ALSA Output (currently PulseAudio Sound Server)" } }
ctl.!default { type pulse fallback "sysdefault" }
Has always taken care of this automatically before. However, this is the first build of Trinity on Arch that does not rely on hal, so there may be more required to get sound going for normal users. I have started pulseaudio, but as of yet, I cannot get sound configured and working. Sound has always been tricky when it is not working. Here, apparently root works just fine using "raw alsa", but then what to do for the users. I'll keep picking around, if you have any other suggestions, please let me know. Thanks.
Well, pulseaudio-alsa is installed by default with pulseaudio iirc, so you'll always get that. pulseaudio daemon is started by a startup file in /etc/xdg/autostart, but I believe it can be dbus activated when something requests it - yet you still need to have a valid dbus session in either cases - be it dbus-launch-ed one or (not really sure 'bout this one) the one started with systemd user session. -- Note: My last name is not Krejzi.
On 02/01/2014 10:43 PM, Armin K. wrote:
On 02/02/2014 05:23 AM, David C. Rankin wrote:
On 02/01/2014 08:54 PM, Armin K. wrote:
Seems like you installed pulseaudio but you aren't running it. pulseaudio usually runs as normal user and not as root user - that's why root uses "raw alsa", and normal user uses "alsa through pulseaudio".
Hmm.. You are correct. But installing pulseaudio-alsa which provides /etc/asound.conf:
# Use PulseAudio by default pcm.!default { type pulse fallback "sysdefault" hint { show on description "Default ALSA Output (currently PulseAudio Sound Server)" } }
ctl.!default { type pulse fallback "sysdefault" }
Has always taken care of this automatically before. However, this is the first build of Trinity on Arch that does not rely on hal, so there may be more required to get sound going for normal users. I have started pulseaudio, but as of yet, I cannot get sound configured and working. Sound has always been tricky when it is not working. Here, apparently root works just fine using "raw alsa", but then what to do for the users. I'll keep picking around, if you have any other suggestions, please let me know. Thanks.
Well, pulseaudio-alsa is installed by default with pulseaudio iirc, so you'll always get that. pulseaudio daemon is started by a startup file in /etc/xdg/autostart, but I believe it can be dbus activated when something requests it - yet you still need to have a valid dbus session in either cases - be it dbus-launch-ed one or (not really sure 'bout this one) the one started with systemd user session.
Following your suggestions, I examined the files in /etc/xdg/autostart and I tried about ever combination of inits to get sound going, but failed each time to get any sound as user. However, this was one of those frustrating situations where I decided to try adding the user to the audio group and tested everything without success, but I left the user as a member of the group when the system was shut down. Apparently, that is all that it took, because when I started the system this morning - sound began automatically playing beautifully. All the settings in TDE are the default 'Autodetect' sound system settings and I made no config file changes. After reading the forum posts that recommended adding the user to the audio group, then reading the wiki pages Warning: don't do it, I'm left curious what I should do in this situation. For whatever reason, sound would not play in TDE until the user was added to the audio group and the system restarted. So what does this tell me isn't working correctly such that non-root users don't have sound access unless in the audio group? Obviously, for Arch, the standard is to not have users in the audio group to prevent breaking fast-user-switching, etc. What process then must be incorporated and relied upon to make this work correctly? According to https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote [1] under Installation) sound access was provided to users via Consolekit in the past. Consolekit is no longer part of Arch. I have kept basic build of TDE for Arch totally reliant on Arch packages, so I would like to solve the sound problem in the proper way so that this desktop is a seamless addition to Arch. What is the best approach to finding a solution to this sound issue? -- David C. Rankin, J.D.,P.E.
On 2.2.2014 22:01, David C. Rankin wrote:
On 02/01/2014 10:43 PM, Armin K. wrote:
On 02/02/2014 05:23 AM, David C. Rankin wrote:
On 02/01/2014 08:54 PM, Armin K. wrote:
Seems like you installed pulseaudio but you aren't running it. pulseaudio usually runs as normal user and not as root user - that's why root uses "raw alsa", and normal user uses "alsa through pulseaudio".
Hmm.. You are correct. But installing pulseaudio-alsa which provides /etc/asound.conf:
# Use PulseAudio by default pcm.!default { type pulse fallback "sysdefault" hint { show on description "Default ALSA Output (currently PulseAudio Sound Server)" } }
ctl.!default { type pulse fallback "sysdefault" }
Has always taken care of this automatically before. However, this is the first build of Trinity on Arch that does not rely on hal, so there may be more required to get sound going for normal users. I have started pulseaudio, but as of yet, I cannot get sound configured and working. Sound has always been tricky when it is not working. Here, apparently root works just fine using "raw alsa", but then what to do for the users. I'll keep picking around, if you have any other suggestions, please let me know. Thanks.
Well, pulseaudio-alsa is installed by default with pulseaudio iirc, so you'll always get that. pulseaudio daemon is started by a startup file in /etc/xdg/autostart, but I believe it can be dbus activated when something requests it - yet you still need to have a valid dbus session in either cases - be it dbus-launch-ed one or (not really sure 'bout this one) the one started with systemd user session.
Following your suggestions, I examined the files in /etc/xdg/autostart and I tried about ever combination of inits to get sound going, but failed each time to get any sound as user. However, this was one of those frustrating situations where I decided to try adding the user to the audio group and tested everything without success, but I left the user as a member of the group when the system was shut down. Apparently, that is all that it took, because when I started the system this morning - sound began automatically playing beautifully. All the settings in TDE are the default 'Autodetect' sound system settings and I made no config file changes.
After reading the forum posts that recommended adding the user to the audio group, then reading the wiki pages Warning: don't do it, I'm left curious what I should do in this situation. For whatever reason, sound would not play in TDE until the user was added to the audio group and the system restarted. So what does this tell me isn't working correctly such that non-root users don't have sound access unless in the audio group? Obviously, for Arch, the standard is to not have users in the audio group to prevent breaking fast-user-switching, etc. What process then must be incorporated and relied upon to make this work correctly?
According to https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote [1] under Installation) sound access was provided to users via Consolekit in the past. Consolekit is no longer part of Arch. I have kept basic build of TDE for Arch totally reliant on Arch packages, so I would like to solve the sound problem in the proper way so that this desktop is a seamless addition to Arch. What is the best approach to finding a solution to this sound issue?
You shouldn't need to have user member of any group that granted access to the any kind of hardware nowadays. That's handled by logind, which is a replacement for ConsoleKit. But, if you start your DE via .xinitrc, you need to make xserver start on the same VT in order to preserve valid systemd session. Also, you should have a user dbus daemon started, as I already pointed out. If you are starting your DE via some kind of Display Manager, and given that it uses PAM, its PAM file need to contain systemd pam file in session section, unless you include system files. https://wiki.archlinux.org/index.php/Xinitrc#Getting_started - Scroll down to the note right before "Configuration" https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss...
On 02/02/2014 04:22 PM, Armin K. wrote:
According to https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote [1] under Installation) sound access was provided to users via Consolekit in the past. Consolekit is no longer part of Arch. I have kept basic build of TDE for Arch totally reliant on Arch packages, so I would like to solve the sound problem in the proper way so that this desktop is a seamless addition to Arch. What is the best approach to finding a solution to this sound issue?
You shouldn't need to have user member of any group that granted access to the any kind of hardware nowadays. That's handled by logind, which is a replacement for ConsoleKit.
But, if you start your DE via .xinitrc, you need to make xserver start on the same VT in order to preserve valid systemd session. Also, you should have a user dbus daemon started, as I already pointed out.
If you are starting your DE via some kind of Display Manager, and given that it uses PAM, its PAM file need to contain systemd pam file in session section, unless you include system files.
https://wiki.archlinux.org/index.php/Xinitrc#Getting_started - Scroll down to the note right before "Configuration"
https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss...
OK, Now we are getting somewhere. Trinity desktop tdm.service is started by systemd on boot. tdm is an updated kde3/kdm desktop manager. tdm.service contains: [Unit] Description=TDE Display Manager After=systemd-user-sessions.service [Service] ExecStart=/opt/trinity/bin/tdm [Install] Alias=display-manager.service On installation trinity also creates and installs a pam file in pam.d containing the following: /etc/pam.d/trinity #%PAM-1.0 #auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login account include system-local-login session include system-local-login On login, dbus and pulseaudio are started from /etc/X11/xinit/xinitrc.d. The two files started are: 30-dbus pulseaudio All of this looks exactly correct for what is described in https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss.... Except for the response from loginctl. Checking loginctl I do not get Remote=no and Active=yes as suggested on the page, instead I get: 08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID 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 So, according to the Troubleshooting section -- If it does not [contain Remote=no and Active=yes], make sure that X runs on the same tty where the login occurred. Here is where I need help. Systemd is doing the starting, so how can I make sure that X runs on the same tty where the login occurred? Where/how do I specify what vt X is running on? -- David C. Rankin, J.D.,P.E.
On 02/03/2014 09:05 AM, David C. Rankin wrote:
On 02/02/2014 04:22 PM, Armin K. wrote:
According to https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture (footnote [1] under Installation) sound access was provided to users via Consolekit in the past. Consolekit is no longer part of Arch. I have kept basic build of TDE for Arch totally reliant on Arch packages, so I would like to solve the sound problem in the proper way so that this desktop is a seamless addition to Arch. What is the best approach to finding a solution to this sound issue?
You shouldn't need to have user member of any group that granted access to the any kind of hardware nowadays. That's handled by logind, which is a replacement for ConsoleKit.
But, if you start your DE via .xinitrc, you need to make xserver start on the same VT in order to preserve valid systemd session. Also, you should have a user dbus daemon started, as I already pointed out.
If you are starting your DE via some kind of Display Manager, and given that it uses PAM, its PAM file need to contain systemd pam file in session section, unless you include system files.
https://wiki.archlinux.org/index.php/Xinitrc#Getting_started - Scroll down to the note right before "Configuration"
https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss...
OK,
Now we are getting somewhere. Trinity desktop tdm.service is started by systemd on boot. tdm is an updated kde3/kdm desktop manager. tdm.service contains:
[Unit] Description=TDE Display Manager After=systemd-user-sessions.service
[Service] ExecStart=/opt/trinity/bin/tdm
[Install] Alias=display-manager.service
On installation trinity also creates and installs a pam file in pam.d containing the following:
/etc/pam.d/trinity #%PAM-1.0
#auth required pam_securetty.so auth requisite pam_nologin.so auth include system-local-login account include system-local-login session include system-local-login
On login, dbus and pulseaudio are started from /etc/X11/xinit/xinitrc.d. The two files started are:
30-dbus pulseaudio
All of this looks exactly correct for what is described in https://wiki.archlinux.org/index.php/General_Troubleshooting#Session_permiss.... Except for the response from loginctl. Checking loginctl I do not get Remote=no and Active=yes as suggested on the page, instead I get:
08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID 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
So, according to the Troubleshooting section -- If it does not [contain Remote=no and Active=yes], make sure that X runs on the same tty where the login occurred.
Here is where I need help. Systemd is doing the starting, so how can I make sure that X runs on the same tty where the login occurred? Where/how do I specify what vt X is running on?
Bad to reply-to-self, but I thought the following information would be helpful. Here are the process started and running including dbus: /sbin/init /usr/lib/systemd/systemd-journald /usr/lib/systemd/systemd-udevd /usr/bin/VBoxService -f /usr/lib/systemd/systemd-logind /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation /sbin/agetty --noclear tty1 /opt/trinity/bin/tdm \_ /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-LI4Qla \_ -:0 \_ /bin/sh /opt/trinity/bin/starttde \_ /opt/trinity/bin/tdeinit_phase1 \_ kwrapper ksmserver --windowmanager twin /opt/trinity/bin/tdekbdledsync /usr/bin/gpg-agent --daemon /usr/bin/ssh-agent -s dcopserver [tdeinit] --nosid --suicide kded [tdeinit] --new-startup start_tdeinit --new-startup +kcminit_startup ksmserver [tdeinit] --windowmanager twin -- David C. Rankin, J.D.,P.E.
On 02/03/2014 02:50 PM, David C. Rankin wrote:
08:29 valhalla:~> loginctl show-session $XDG_SESSION_ID
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
This issue has been traced to Trinity/twin requiring code changes to work in a pure systemd environment. The fix required will be similar to kde4/kwin: kde-workspace-4.11.1-kdm-logind-multiseat.patch This is in work. Until then, TDE works fine, the only areas impacted are closing tdeio_sftp connections (kio_sftp) and those permission issues dealing with user sound. Feel free to install TDE and test. Thank you for all the help with this issue. -- David C. Rankin, J.D.,P.E.
participants (2)
-
Armin K.
-
David C. Rankin