[gentoo-amd64] arts

[gentoo-amd64] arts

[Benny Pedersen]

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

if more info is needed say so
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] arts

[Zac Medico]

Benny Pedersen wrote:
> 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
> 
> if more info is needed say so

I use the audio group to grant permission to /dev/dsp.

$ ls -lL /dev/dsp
crw-rw----  1 root audio 14, 3 Jul  7 14:46 /dev/dsp

Zac
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: arts

[Duncan]

Benny Pedersen posted
<36728.80.166.75.19.1120793029.squirrel@mail.junc.org>, 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@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Peter Humphrey]

Duncan wrote:

>Benny Pedersen posted
><36728.80.166.75.19.1120793029.squirrel@mail.junc.org>, 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.
>>    
>>
>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.
>  
>

I hope I'm not hijacking this thread   ;-)    but can anyone tell me
what creates /dev/dsp in the first place? On this newly reinstalled
Xfce4 system it doesn't exist, even though the kernel sound modules do
and have been loaded.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Tres Melton]

On Fri, 2005-07-08 at 11:57 +0100, Peter Humphrey wrote:

> I hope I'm not hijacking this thread   ;-)    but can anyone tell me
> what creates /dev/dsp in the first place? On this newly reinstalled
> Xfce4 system it doesn't exist, even though the kernel sound modules do
> and have been loaded.

I think that it is created by the deprecated devfs package.  The newer
udev package uses /dev/sound/dsp and make /dev/dsp a link to the newer
one for compatibility but since you don't have one it may only create
the link if the old device was there.

-- 
Tres

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Peter Humphrey]

Tres Melton wrote:

>On Fri, 2005-07-08 at 11:57 +0100, Peter Humphrey wrote:
>
>  
>
>>I hope I'm not hijacking this thread   ;-)    but can anyone tell me
>>what creates /dev/dsp in the first place? On this newly reinstalled
>>Xfce4 system it doesn't exist, even though the kernel sound modules do
>>and have been loaded.
>>    
>>
>
>I think that it is created by the deprecated devfs package.  The newer
>udev package uses /dev/sound/dsp and make /dev/dsp a link to the newer
>one for compatibility but since you don't have one it may only create
>the link if the old device was there.
>  
>

Hmm. /dev/sound/dsp doesn't exist either, but I find:

prh@wstn ~ $ ls -lL /dev/dsp?
crw-rw----  1 root audio 14, 19 Mar  4 13:40 /dev/dsp1
crw-rw----  1 root audio 14, 35 Mar  4 13:40 /dev/dsp2
crw-rw----  1 root audio 14, 51 Mar  4 13:40 /dev/dsp3

Now I find I've somehow omitted alsasound from the default runlevel;
putting it in there and /etc/init.d/alsasound start gives /dev/dsp as a
link to /dev/sound/dsp. So I've answered my own question, but I hope
I've also exposed another little fact.

-- 
Rgds
Peter Humphrey
Linux Counter 5290, Aug 93.

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Alexey Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

As far as I remember, /dev/dsp is only used with OSS.
In case you use ALSA, it is created by OSS emulation. Possibly OSS emulation 
modules are not loaded. Module names are something like snd_*_oss.

P.S. I can be very wrong about it.


On Friday 08 July 2005 14:46, Peter Humphrey wrote:
> Tres Melton wrote:
> >On Fri, 2005-07-08 at 11:57 +0100, Peter Humphrey wrote:
> >>I hope I'm not hijacking this thread   ;-)    but can anyone tell me
> >>what creates /dev/dsp in the first place? On this newly reinstalled
> >>Xfce4 system it doesn't exist, even though the kernel sound modules do
> >>and have been loaded.
> >
> >I think that it is created by the deprecated devfs package.  The newer
> >udev package uses /dev/sound/dsp and make /dev/dsp a link to the newer
> >one for compatibility but since you don't have one it may only create
> >the link if the old device was there.
>
> Hmm. /dev/sound/dsp doesn't exist either, but I find:
>
> prh@wstn ~ $ ls -lL /dev/dsp?
> crw-rw----  1 root audio 14, 19 Mar  4 13:40 /dev/dsp1
> crw-rw----  1 root audio 14, 35 Mar  4 13:40 /dev/dsp2
> crw-rw----  1 root audio 14, 51 Mar  4 13:40 /dev/dsp3
>
> Now I find I've somehow omitted alsasound from the default runlevel;
> putting it in there and /etc/init.d/alsasound start gives /dev/dsp as a
> link to /dev/sound/dsp. So I've answered my own question, but I hope
> I've also exposed another little fact.
>
> --
> Rgds
> Peter Humphrey
> Linux Counter 5290, Aug 93.

-- 
Alexey Maslennikov
Oracle DBA and developer
*NIX system administrator

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-amd64] Re: Re: arts

[Duncan]

Alexey Maslennikov posted
<200507090210.07611.alexey.maslennikov@gmail.com>, excerpted below,  on
Sat, 09 Jul 2005 02:10:02 +0300:

> As far as I remember, /dev/dsp is only used with OSS. In case you use
> ALSA, it is created by OSS emulation. Possibly OSS emulation modules are
> not loaded. Module names are something like snd_*_oss.
> 
> P.S. I can be very wrong about it.

(Without looking,) I believe you're quite right, actually, tho I never
track exactly which devices are ALSA and which are OSS, so you /might/
have that reversed.

I always run ALSA with OSS emulation in the kernel, so get both.  With
Gentoo's default udev configuration, based on devfs, one set is created in
/dev/snd/, the other in /dev/sound/, with symlinks from /dev/ to the
devices in both subdirs as necessary, I just never remember which is OSS
and which is ALSA.  If I had to, I'd look it up.  The quickest way would
be to check the (commented) /etc/udev/rules.d/* file(s).  The ALSA section
there is presented separately from the OSS section, so looking at that,
it's easy to figure out which is which.

As to whether they exist or not at any particular moment, that will depend
on several possible configuration details, such as whether you've compiled
the drivers as modules or built-in, and whether you have the alsa or
coldplug (or oss, for those not running alsa) initscripts set to run in
your current runlevel (also on whether you have the init set to use the
tarball or not, I have that turned off and the only devices in my static
/dev are /dev/null and /dev/console, if udev fails, so I'd know it
pretty fast!). Here, I don't run alsa at bootup, but I do run coldplug as
part of initlevel 2 (nonet, my default) and 3 (normal default).  I have
the drivers compiled in, so coldplug triggers udev to load the device
nodes.  I never /do/ run the alsa script, as what coldplug does is enough
to have sound in KDE/X, and I don't use it at the console if KDE/X isn't
running.

-- 
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@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Luigi Pinna]

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Alle 01:10, sabato 09 luglio 2005, Alexey Maslennikov ha scritto:
> As far as I remember, /dev/dsp is only used with OSS.
> In case you use ALSA, it is created by OSS emulation. Possibly OSS
> emulation modules are not loaded. Module names are something like
> snd_*_oss.
>
> P.S. I can be very wrong about it.

Sorry, I have a question:
can you use arts without problems? If I use arts, it crashs often and 
freeze the computer...
Usually I can't login in a session where one or two programs, that they 
use arts, must be open (a restored session).
If I do that, the computer freeze immediately.
Am I alone?
I recompiled KDE without arts support now, but I have no system sound 
and kopete sound...
Luigi

-- 
Public key GPG(0x073A0960) on http://keyserver.linux.it/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: arts

[Alexey Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

I do not use arts, but have configured KDE notifications to use external 
player: in my case alsaplayer.

I don't use native kde music players, so this is sufficient.

On Saturday 09 July 2005 05:37, Luigi Pinna wrote:
> Alle 01:10, sabato 09 luglio 2005, Alexey Maslennikov ha scritto:
> > As far as I remember, /dev/dsp is only used with OSS.
> > In case you use ALSA, it is created by OSS emulation. Possibly OSS
> > emulation modules are not loaded. Module names are something like
> > snd_*_oss.
> >
> > P.S. I can be very wrong about it.
>
> Sorry, I have a question:
> can you use arts without problems? If I use arts, it crashs often and
> freeze the computer...
> Usually I can't login in a session where one or two programs, that they
> use arts, must be open (a restored session).
> If I do that, the computer freeze immediately.
> Am I alone?
> I recompiled KDE without arts support now, but I have no system sound
> and kopete sound...
> Luigi

-- 
Alexey Maslennikov
Oracle DBA and developer
*NIX system administrator

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-amd64] Re: Re: arts

[Duncan]

Luigi Pinna posted <200507090437.21664.mailing-gentoo@sailorferris.com>,
excerpted below,  on Sat, 09 Jul 2005 04:37:17 +0200:

> Sorry, I have a question:
> can you use arts without problems? If I use arts, it crashs often and
> freeze the computer...
> Usually I can't login in a session where one or two programs, that they
> use arts, must be open (a restored session). If I do that, the computer
> freeze immediately. Am I alone?
> I recompiled KDE without arts support now, but I have no system sound and
> kopete sound...

ARTS is working just fine, here, arts-3.4.1-r2 compiled with
gcc-4.0.1-pre20050607 I think it was.  The hardware is the onboard sound
on a Tyan s2885 dual Opteron board, AMD-8xxx chipset, meaning the intel8x0
ALSA driver.

Every once in awhile I have issues with it, and have to play with the
settings, switching artsd between the ALSA, OSS, and OSS-threaded driver
modules.  Very occasionally, something in the ARTS config will get
corrupted as well, and I'll end up having to delete all the arts temp
files (and the dcop temp files) and the like.  However, I eventually get
it all working again.

Note that everybody, including all the KDE devs that know anything about
it, considers ARTS a huge mess.  It has been barely maintained for some
time, the code is spaghetti code and difficult for anyone to do anything
with, there are quite a few untouched open bugs on it at KDE bugzilla, and
the original ARTS authors are no longer with KDE, and nobody else wants to
/touch/ it, let alone claim maintainership.  Yes, the code /is/ that bad. 
As well, the entire arts project suffered from overreach from the
beginning.  They tried to do to much in one thing, instead of taking the
traditional Unix approach of a bunch of small apps or modules, each doing
only one thing, but doing it WELL, so arts does quite a bit but none of it
WELL, and as mentioned, the code base is spaghetti to a point beyond
recovery.

It's really a wonder they got it working on amd64 at all.

For all these reasons and more, KDE is moving off of arts.  However, for
compatibility reasons, it will remain with us thru the KDE 3.x series,
thus, will be around for the next minor release, KDE 3.5, which will
likely be out either late this year or next spring (a specific schedule
hasn't been set, yet).

3.5 is, however, supposed to be the last "tide-over" minor version of KDE
before KDE 4.0, which will be released a year to a year and a half from
now, so 2H2006.  KDE 4.0 will *NOT* have ARTS as a major component any
longer.  As a partial replacement for the KDE audio framework
functionality of ARTS, kdemm will appear.  The idea is a common API
framework that all KDE (and others, if they wish)  programs can call,
replacing that functionality within ARTS.  On the other end, the
driver/device end, it will have a plugin architecture, with "bridge"
plugins available to interface between the native platform sound drivers
and kdemm.  Thus, there'll be an ALSA plugin for modern Linux, an OSS
plugin for older Linux kernels and the BSDs, as well as the proprietary
OSS drivers, likely an esd plugin to interface with other desktop
environments, likely another plugin to interface with the just now
formulating freedesktop.org sound project, etc.  The sound daemon software
audio stream merging aspect of arts, however, will NOT be directly
replaced, since many sound hardware devices and their drivers (alsa and
others) manage that in hardware.  For those without hardware stream
merging available, ALSA (and presumably OSS and others as well) provides
its own solution, so kdemm doesn't need to do so.

What's /really/ interesting about the kdemm infrastructure, however, is
just what it implies about adaptability to other platforms.  Keep in mind
that Trolltech has made a GPLed Qt4 library available for MSWormOS for the
first time, and aspects of the KDE community are targeting an MSWormOS
port of KDE-4 as well.  Because of the plugin architecture, kdemm will be
compilable with few if any changes for MSWormOS, only needing a driver
plugin very parallel to the one it uses for ALSA, to interface directly
with the MSWormOS native sound system as well!  Imagine, just as one can
run OOo or Firefox on MSWormOS or Linux or OSX or whatever, so KDE, with
version 4, is intended to be cross-platform.  Get folks used to the KDE
environment on MSWormOS, and a year or two later, it'll be much easier to
switch out the implementing platform from underneath it, and have them
running freedomware Linux, rather than proprietaryware, the opposite of
freedomware, MSWormOS!

Anyway, the bad news is that issues with ARTS aren't uncommon, and they'll
continue if not get worse for another year or so, as ARTS continues to get
the bare minimum of maintenance.  The good news is, with the release of
KDE4, anticipated sometime in the latter half of 2006, so a year to a year
and a half out, we won't have to worry about ARTS headaches any longer!

-- 
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@gentoo.org mailing list

Re: [gentoo-amd64] arts

[Luigi Pinna]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

Alle 11:40, sabato 09 luglio 2005, Alexey Maslennikov ha scritto:
> I do not use arts, but have configured KDE notifications to use
> external player: in my case alsaplayer.
>
> I don't use native kde music players, so this is sufficient.

Can you explain me how I can do it? I tried but I have no idea...
Thanks,
Luigi

-- 
Public key GPG(0x073A0960) on http://keyserver.linux.it/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: arts

[Duncan]

Luigi Pinna posted <200507091322.55385.mailing-gentoo@sailorferris.com>,
excerpted below,  on Sat, 09 Jul 2005 13:22:51 +0200:

> Alle 11:40, sabato 09 luglio 2005, Alexey Maslennikov ha scritto:
>> I do not use arts, but have configured KDE notifications to use external
>> player: in my case alsaplayer.
>>
>> I don't use native kde music players, so this is sufficient.
> 
> Can you explain me how I can do it? I tried but I have no idea... Thanks,

Run kcontrol and switch to Sound and Multimedia, System Notifications (or
run kcmshell kcmnotify, to get the specific applet directly), click the
Player Settings button, then the Use an external player radiobutton in
the resulting dialog. Enter or browse to the player you want to use, hit
apply, and test the results.  Note that you may have to play around with
command line options such as volume and the like, for your selected
player.  

Note that some applications open the sound devices in exclusive access
(unshared) mode.  Arts itself is a good example.  If this happens, your
sounds won't be able to play unless/until the device is free.  Thus, it's
possible you'll get only one sound stream at a time, unless you arrange
for separate multiplexing.  That can be done, but I'm not going to attempt
an explanation in this message.  In any case, having one thing play at a
time is better than no sound at all!

-- 
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@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Benny Pedersen]

On Fri, July 8, 2005 11:21, Duncan wrote:

> 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.

that was the pointer for me[3], i have disabled arts and enabled alsa olso
in the kernel after that rebuild all that hasuse arts[1] in use settings,
and last emerged all alså supporting tools[2], wonderfull it sound is
again working on my asus sk8n

> Also, check your PAM settings, console.perms IIRC.  Gentoo is moving away
> from using the PAM console-perms module by default, because it causes

will pam still be an problem for me now when the silence is dead here ?

using kernel 2.6.12 r4 now

[1] equery hasuse arts
[2] equery hasuse alsa
    emerge from the listning above
[3] usermod -G audio myuser
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Re: arts

[Duncan]

Benny Pedersen posted
<48612.80.166.75.19.1120990641.squirrel@mail.junc.org>, excerpted below, 
on Sun, 10 Jul 2005 12:17:21 +0200:

> On Fri, July 8, 2005 11:21, Duncan wrote:
> 
>> 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.
> 
> that was the pointer for me[3], i have disabled arts and enabled alsa olso
> in the kernel after that rebuild all that hasuse arts[1] in use settings,
> and last emerged all alså supporting tools[2], wonderfull it sound is
> again working on my asus sk8n

LOL!  I've never used the usermod tool.  I always simply edit the
/etc/group or /etc/passwd files directly (yes, I know about the possible
race conditions, but if I'm the only human user and I'm not in the middle
of an emerge or something else that might try to edit the files...).  I'm
used to loading them to grab a quick look at what users are on what
groups, as well.

BTW, all you would have needed to do (and you still might want to, to
catch any other changes you may have missed) is run emerge --ask --newuse
--verbose (-aNv), and portage would have figured out what packages were
emerged with outdated flags and asked you if you wanted to remerge them.

The --newuse (-N) flag is one of the quite useful newer features in the
portage 2.0.51 series, so if you didn't know about it, take a look at the
emerge man page and note that flag for further reference.

>> Also, check your PAM settings, console.perms IIRC.  Gentoo is moving away
>> from using the PAM console-perms module by default, because it causes
> 
> will pam still be an problem for me now when the silence is dead here ?

It may not be, but it'a /always/ a useful thing to keep in the back of
your mind to check, if for some reason you appear to be having permission
problems, particularly if it seems to work sometimes and not others (altho
it's entirely possible you only see the "fail" condition, if you never
satisfy the conditions that would trigger "success" in your normal
routine), because PAM has a number of features that can be used to
dynamically control permissions.  It's also useful to keep PAM in mind for
that dynamic permission control feature, just in case you sometime need to
control access to something by time of day, or some other such strange
thing. 

(A caveat with the time of day thing -- there's a sort of bypass ability
if you don't set it up right, for those smart enough to figure it out, so
don't count on something like that to be 100% foolproof, at least not
without reading the PAM documentation, which explains the issue quite
well.  It works well in the same fashion a padlock does, however.  Most
padlocks are easily snipped in seconds with a bolt cutter, many easily
knocked open with just the right tap from a hammer, but they serve as an
indicator of intended lack of permission, and as they say, to "keep the
honest people honest", even if everyone knows they aren't really all that
secure if one's intent is to get at what they are "protecting".)

> using kernel 2.6.12 r4 now

Hmm...  I haven't the foggiest what Gentoo's kernel ebuilds are like, as I
learned how to download and build my own kernel relatively quickly after
switching from MSWormOS (within 90 days), and had been doing it on
Mandrake for some time before switching to Gentoo, so saw no reason at all
to change that, so didn't.

> [1] equery hasuse arts
> [2] equery hasuse alsa
>     emerge from the listning above
> [3] usermod -G audio myuser

-- 
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@gentoo.org mailing list

Re: [gentoo-amd64] Re: arts

[Luigi Pinna]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Alle 14:01, sabato 09 luglio 2005, Duncan ha scritto:

> Run kcontrol and switch to Sound and Multimedia, System Notifications
> (or run kcmshell kcmnotify, to get the specific applet directly),
> click the Player Settings button, then the Use an external player
> radiobutton in the resulting dialog. Enter or browse to the player
> you want to use, hit apply, and test the results.  Note that you may
> have to play around with command line options such as volume and the
> like, for your selected player.

I tried it but it doesn't work.
I selected alsaplayer (like you) and I tested alsaplayer alone, but with 
KDE no chance...
What did you do? Only selected the player? Can you help me?
Thanks,
Luigi

-- 
Public key GPG(0x073A0960) on http://keyserver.linux.it/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] Re: arts

[Alexey Maslennikov]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Make sure you have specified the full path of the player.
Make sure you have disabled arts.

And again, it works for notifications only.

On Monday 11 July 2005 19:04, Luigi Pinna wrote:
> Alle 14:01, sabato 09 luglio 2005, Duncan ha scritto:
> > Run kcontrol and switch to Sound and Multimedia, System Notifications
> > (or run kcmshell kcmnotify, to get the specific applet directly),
> > click the Player Settings button, then the Use an external player
> > radiobutton in the resulting dialog. Enter or browse to the player
> > you want to use, hit apply, and test the results.  Note that you may
> > have to play around with command line options such as volume and the
> > like, for your selected player.
>
> I tried it but it doesn't work.
> I selected alsaplayer (like you) and I tested alsaplayer alone, but with
> KDE no chance...
> What did you do? Only selected the player? Can you help me?
> Thanks,
> Luigi

-- 
Alexey Maslennikov
Oracle DBA and developer
*NIX system administrator

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-amd64] Re: Re: arts

[Duncan]

Luigi Pinna posted <200507111804.06064.mailing-gentoo@sailorferris.com>,
excerpted below,  on Mon, 11 Jul 2005 18:04:01 +0200:

> Alle 14:01, sabato 09 luglio 2005, Duncan ha scritto:
> 
>> Run kcontrol and switch to Sound and Multimedia, System Notifications
>> (or run kcmshell kcmnotify, to get the specific applet directly), click
>> the Player Settings button, then the Use an external player radiobutton
>> in the resulting dialog. Enter or browse to the player you want to use,
>> hit apply, and test the results.  Note that you may have to play around
>> with command line options such as volume and the like, for your selected
>> player.
> 
> I tried it but it doesn't work.
> I selected alsaplayer (like you) and I tested alsaplayer alone, but with
> KDE no chance...
> What did you do? Only selected the player? Can you help me? Thanks,

I expect something else has claimed exclusive use of the sound system at
the same time.  That could be ARTS itself if you haven't entirely disabled
it (try "ps aux|grep artsd" at the konsole to see), since arts is KNOWN to
hog exclusive control of the sound system.

If it's not arts, and you have the sys-process/psmisc package merged, try
using the "fuser /dev/dsp" command to see what if anything has the file
open. If a process is using it, it will return the PID. You can then use
ps aux and grep again, to find the commandline of the process belonging to
that PID.

BTW, with both ps/grep commands above, note that the grep command is also
returned -- no surprise that a grep of a ps listing returns the grep
command in that ps listing. <g>

...

It's also possible that it's not all that, but a different config option
in KDE that has it silent.  In the same kcmshell kcmnotify module I
mentioned earlier, check that you don't have all sound turned off.  Also
check in kcmshell bell that you don't have "use system bell instead of
system notification" turned on.

Finally, I've never tried merging kde with USE=-arts, so I don't know
exactly what that removes.  Possibly, that turns off the entire notify
framework, in which case you'll have to compile with arts enabled, and
just tell KDE not to run it (using kcmshell arts), before setting up an
external player for KDE system notification events.

-- 
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@gentoo.org mailing list