The aRts Handbook
Prev |  | Next

# Chapter 13. Questions and answers

This section answers some frequently asked questions about aRts.

# 13.1. General Questions

13.1.1. Does KDE support my sound card for audio output?
13.1.2. Is there sound support on platforms other than Linux®?
13.1.3. I can't play `wav` files with artsd!
13.1.4. I hear sound when logged in as >root but no other users have sound!
13.1.5. This helps for artsd, but what about KMix, kmid, KSCD,etc.?
13.1.6. What can I do if artsd doesn't start or crashes while running?

13.1.1. Does KDE support my sound card for audio output?

KDE uses aRts to play sound, and aRts uses the Linux® kernel sound drivers, either OSS or ALSA (using OSS emulation). If your sound card is supported by either ALSA or OSS and properly configured (i.e. any other Linux® application can output sound), it will work.

13.1.2. Is there sound support on platforms other than Linux®?

There is currently only support for OSS (or compatible) drivers on other platforms (e.g. FreeBSD). You are welcome to contribute by adding support for other platforms. The relevant source code is `kdelibs/arts/flow/audiosubsys.cc`.

13.1.3. I can't play `wav` files with artsd!

Check that artsd is linked to `libaudiofile` (`ldd `artsd``). If it isn't, download kdesupport, recompile everything, and it will work.

13.1.4. I hear sound when logged in as >root but no other users have sound!

The permissions of the file `>/dev/dsp` affect which users will have sound. To allow everyone to use it, do this:

1. log in as >root

2. open a Konqueror window

3. go into the `/dev` directory

4. click on the file `dsp` with the right mouse button, and choose properties.

5. click on the Permissions tab

6. check the Read and Write check boxes in all sections

7. click on ok

You can achieve the same effect in a terminal window using the command `chmod `666 `/dev/dsp```.

For restricting access to sound to specific users, you can use group permissions. On some Linux® distributions, for instance Debian/Potato, `/dev/dsp` is already owned by a group called >audio, so all you need to do is add the users to this group.

13.1.5. This helps for artsd, but what about KMix, kmid, KSCD,etc.?

There are various other devices which provide functionality accessed by multimedia applications. You can treat them in the same way, either by making them accessible for everyone, or using groups to control access. Here is a list, which may still be incomplete (also if there are various devices in a form like midi0, midi1, ..., then only the 0-version is listed here):

`>/dev/admmidi0` `>/dev/adsp0` `>/dev/amidi0` `>/dev/amixer0` `>/dev/audio` `>/dev/audio0` `>/dev/cdrom` `>/dev/dmfm0` `>/dev/dmmidi0` `>/dev/dsp` `>/dev/dsp0` `>/dev/midi0` `>/dev/midi0` `>/dev/midi00` `>/dev/midi00` `>/dev/mixer` `>/dev/mixer0` `>/dev/mpu401data` `>/dev/mpu401stat` `>/dev/music` `>/dev/rmidi0` `>/dev/rtc` `>/dev/sequencer` `>/dev/smpte0` `>/dev/sndstat`

13.1.6. What can I do if artsd doesn't start or crashes while running?

First of all: try using the default settings in KControl (of if you are starting manually, don't give additional options besides maybe -F10 -S4096 for latency). Especially full duplex is likely to break with various drivers, so try disabling it.

A good way to figure out why artsd doesn't start (or crashes while running) is to start it manually. Open a konsole window, and do:

     % artsd -F10 -S4096

You can also add the -l0 option, which will print more information about what is happening, like this:

     % artsd -l0 -F10 -S4096

Doing so, you will probably get some useful information why it didn't start. Or, if it crashes when doing this-and-that, you can do this-and-that, and see "how" it crashes. If you want to report a bug, producing a backtrace with gdb and/or an strace may help finding the problem.

Prev | Home | Next
References |  | Non-Arts Applications