This section answers some frequently asked questions about aRts.
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.
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.
Check that artsd is linked to libaudiofile (ldd artsd). If it isn't, download kdesupport, recompile everything, and it will work.
The permissions of the file /dev/dsp affect which users will have sound. To allow everyone to use it, do this:
log in as root
open a konqueror window
go into the /dev directory
click on the file dsp with the right mouse button, and choose properties
click on the permissions tab
check the read and write check boxes in all sections
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.
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
Since the aRts sound server used by KDE is running, it is using the sound device. If the server is idle for 60 seconds, it will auto-suspend and release it automatically.
Currently it doesn't suspend when using full duplex. Turn full duplex off from the KDE Control Center and it will suspend. Disabling full duplex is generally a good idea anyway if you only use aRts for playing audio and not recording.
Run them using the artsdsp. For instance, if you normally would run:
mpg123 foo.mp3
instead use:
artsdsp mpg123 foo.mp3
This will redirect the sound output to aRts. This method doesn't require changes to the applications. It is something of an ugly hack however, and does not yet fully support all features of the sound card device, so some applications may not work.
You need a recent version of the glibc library; artsdsp will not work reliably on some older Linux distributions. For instance, on Debian 2.1 (which is glibc 2.0 based) it doesn't work, while on Debian 2.2 (which is glibc 2.1.3 based), it does.
15.1.2.5. Are there theoretical limitations with some applications that will prevent them from ever working with artsdsp ?
No. Using artsdsp can result in slightly more latency and CPU usage that using the aRts APIs directly. Other than that, any application that doesn't work should be considered a bug in artsdsp. The technique used by artsdsp should, if implemented properly, allow every application to work with it (including large applications like Quake 3).
You can wait for artsd to suspend or use the command artsshell suspend to ask the server to suspend itself. You will only be able to suspend the server if no aRts applications are currently using it, and no aRts applications will be able to run when the server is suspended.
If the server is busy, a crude but effective way to get rid of it is:
killall artsd ; killall artswrapper start application... kcminit arts |
Any currently running aRts applications may crash, however, once you kill the server.
This is most likely not a bug, but caused by the fact that the Linux kernel is not very good at real-time scheduling. There are situations where aRts will not be able to keep up with playback. You can, however, enable real-time rights (via KControl), and use a large latency setting (like 250ms or don't care), which should improve the situation.
The help text for this setting in the KDE Control Center can be misleading. A lower value means that aRts will take less time to respond to external events (i.e. the time that it takes between closing a window and hearing a sound played by artsd). It will also use more CPU resources, and be more likely to cause dropouts.
For users of IDE drives, you can use the hdparm command to put your IDE drive in DMA mode. A word of warning: this does not work on all hardware, and can result in having to do a hard reset or in rare cases, data loss. Read the documentation for the hdparm command for more details. I have successfully used the following command:
hdparm -c1 -d1 -k1 -K1 /dev/hda
You need to run this after every boot, so you might want to place it in a system startup script (how to do this distribution specific, on Debian Linux it is usually put in /etc/rc.boot).
Enable it in the KDE Control Center Sound / Sound Server settings (enable X11 server for security information and network transparency). Then copy your .mcoprc to all machines you plan to use network transparency from. Log in again. Make sure that the hosts that interact know each other by name (i.e. they have resolvable names or are in /etc/hosts).
This should be all you need to do. However, if it still doesn't work here are some additional details. The aRts sound server process, artsd, should only run on one host, the one with the sound card where the sound should be played. It can be started automatically on login by KDE (if you configure that in kcontrol), or manually using something like:
artsd -n -F 5 -S 8192
The -n parameter is for network transparency, while the others configure latency.
Your .mcoprc file should have this entry:
GlobalComm=Arts::X11GlobalComm
on all machines involved, in order for network transparency to work, This is what is enabled by the "X11 server for security information" control panel setting.
Finally, in any KDE version in the 2.0.x series, there is a bug which applies if you don't have a domain name set. Clients of artsd try to find where to connect to via the hostname.domainname combination. If your domain name is empty, it will try to connect to hostname. (note the extra dot). Adding an entry like this to /etc/hosts1 (i.e. orion. if your hostname is orion) works around the problem.
Assuming you have the KDE source code, go to kdelibs/arts/examples, and run make check to compile some programs, including referenceinfo. Then run
./referenceinfo global:Arts_SimpleSoundServer
The output will indicate the host name and port being used by aRts. For example, tcp:orion:1698 would mean that any client trying to use network transparency should know how to reach host orion.
The most likely cause is that you are using old structures or modules which aren't supported with the KDE 2 version. Unfortunately the documentation which is on the web refers to aRts-0.3.4.1 which is quite outdated. The most often reported crash is: that performing an execute structure in artsbuilder results in the error message
[artsd] Synth_PLAY: audio subsystem is already used.
You should use a Synth_AMAN_PLAY instead of a Synth_PLAY module and the problem will go away. Also see the artsbuilder help file (hit F1 in artsbuilder).
Recent versions of artsbuilder (KDE2.1 beta 1 and later) come with a set of examples which you can use.