Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |