Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Help finding device...



On Thu, Feb 05, 2004 at 05:25:11AM -0500, Scott Ehrlich wrote:
> On Thu, 5 Feb 2004, Derek Martin wrote:
> > The trick is, you need to make all your sound applications go through
> > artsd...  XMMS, for example, comes with an artsd plugin to enable that
> > kind of behavior.  But you need to configure it in the options menu.
> 
> Remember - the error was occuring during the init phase of the window
> manager startup screen, long before it would allow me access to my
> desktop.

Yes, I realize that, but I'm not quite sure what your point is.
Again, artsd is a sound daemon which is started at the beginning of
your KDE session, so that all access to the sound card can go through
it.  It grabs /dev/dsp, preventing other applications from doing so,
but the point is that they SHOULDN'T try to access /dev/dsp -- they
should play sounds through artsd instead.

Many applications (mostly ones that are KDE-aware) have configuration
options to make this possible.  Some don't, I'm sure.  But the artsd
package probably has some program associated with it which will allow
you to run non-artsd-aware programs through it.

I'm not specifically familiar with artsd, but this is basically also
true of Gnome's version of artsd, which is called esd.  To again use
xmms as an example, in the preferences dialog you can tell xmms to
send its output to esd (or artsd) instead of trying to grab /dev/dsp.
For applications that don't know how to use esd, a utility called
something like esddsp, or maybe esdplay, is provided.  Running that
utility with the name of the program you want to run as its argument
will cause the program to use esd instead of grabbing the sound
hardware directly.  I believe artsd has a similar facility.

In case this was not clear from my previous post, the point of this is
to allow multiple applications to access the sound hardware at the
same time, which is normally not possible on Linux.  This is why we
have esd and artsd.

You never said much about what you were doing that wasn't working, but
there's almost certainly a way to configure it to make it work
properly through artsd instead of trying to grab the sound hardware
directly.

There are, however, cases where you may not want to do that.  Some
applications perform poorly when they use a sound daemon, but work
fine when they access /dev/dsp directly.  But rather than making artsd
unusable, you can simply disable it.  That's probably the better way
to handle it.

OTOH, if you're happy with your current solution, then by all means
keep using it...  But you should at least be aware that it's not very
portable, and you'll have to re-"fix" it on each newly installed
system you create.  If you disable it in your session instead, you can
probably just copy all the KDE-related dot files in your home
directory from machine to machine (you probably already do this
anyway if you've been using some flavor of Unix for any length of
time) and never worry about it again.  

I don't use KDE, so I can't be sure, but I must imagine that you can
disable artsd from the sound preferences applet in KDE's control
center, or whatever it's called.  Or if KDE provides a session
management applet, you can probably do it there too.  

Hope you find this useful...

-- 
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.
Replying to it will result in undeliverable mail.
Sorry for the inconvenience.  Thank the spammers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040205/87dd5442/attachment.sig>



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org