Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-amd64
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-amd64@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: arts
Date: Fri, 08 Jul 2005 02:21:07 -0700
Benny Pedersen posted
<36728.80.166.75.19.1120793029.squirrel@...>, excerpted below, 
on Fri, 08 Jul 2005 05:23:49 +0200:

> Sound server informational message:
> Error while initializing the sound driver: device /dev/dsp can't be opened
> (Permission denied) The sound server will continue, using the null output
> device.
> 
> i get a requester when starting x11 now and i don't know how to solve this
> one :(
> 
> using udev 0.58

There was just a problem with that, with the new udev-061, now masked
pending a fix.  However, if you're running 058, that shouldn't be the one
you are having.

Expanding on what Zac said, ensure your user is in the audio group, and
that udev is set up to use that group for audio devices and that the mode
is 660. 

Also, check your PAM settings, console.perms IIRC.  Gentoo is moving away
from using the PAM console-perms module by default, because it causes
issues, but I've no idea if that's now on stable or if stable is still
running console-perms by default.  Basically, the idea of console-perms is
to have the sound hardware and certain other devices belong to the first
logged in console user.  After they log off, perms switch to the second,
etc.  If nobody is logged in at the console, perms would switch to root
only.  Note that it is *NOT* necessary to be logged in at the console
while you have an X session running, and this is in fact one of the big
problems with pam-console-perms, and the reason Gentoo has decided to
switch off of it.  For those who don't understand how it works, it ends up
looking like sometimes the perms work as expected, sometimes they don't,
randomly, which of course causes serious support headaches.

Anyway, if you aren't on a network and it's basically a single user at a
time machine, you could probably get away with setting both PAM (if
necessary) and UDEV permissions to 666, allowing all users to read/write
the audio hardware, regardless of whether they are in the audio group. 
That's not necessarily a good thing on a decent sized office network, of
course, because it's all too easy for someone else to login remotely, and
set it playing embarrassing noises at the wrong time <g>, not to mention
potential buffer overflows and the like, but for a single computer or
home/SOHO network where all users are trusted and behind a suitable
firewall, that'd generally be the least complicated thing to do.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list


Replies:
Re: Re: arts
-- Benny Pedersen
Re: Re: arts
-- Peter Humphrey
References:
arts
-- Benny Pedersen
Navigation:
Lists: gentoo-amd64: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: arts
Next by thread:
Re: Re: arts
Previous by date:
RE: ATI drivers and 32 bits games
Next by date:
Re: Re: arts


Updated Jun 28, 2012

Summary: Archive of the gentoo-amd64 mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.