[arch-general] [Bad fix?] was Re: No user sound - only root has access alsamixer on virtualbox?

[Armin K.]

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_permissions