The aRts Handbook
Prev | Chapter 13. Questions and answers | Next

# 13.2. Non-Arts Applications

13.2.1. As soon as KDE is running, no other application can access my sound device!
13.2.2. You said it suspends after 60 seconds, it doesn't for me!
13.2.3. How can I run old, non-aRts applications?
13.2.4. I can't run artsdsp with any application, it always crashes!
13.2.5. Are there theoretical limitations with some applications that will prevent them from ever working with artsdsp ?
13.2.6. What can I do if an application doesn't work with artsdsp?
13.2.7. What about applications written for KDE1?
13.2.8. What about applications using the enlightened sound daemon, ESD?

13.2.1. As soon as KDE is running, no other application can access my sound device!

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.

13.2.2. You said it suspends after 60 seconds, it doesn't for me!

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.

13.2.3. How can I run old, non-aRts applications?

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.

13.2.4. I can't run artsdsp with any application, it always crashes!

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.

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

13.2.6. What can I do if an application doesn't work with artsdsp?

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
     Now start your own application.
     % kcminit arts

Any currently running aRts applications may crash, however, once you kill the server.

13.2.7. What about applications written for KDE1?

If you are running KDE1 applications, which output sound via the KDE1 audio server, you will need to run kaudioserver to make it work. You can start kaudioserver in the same way than other non-aRts-applications:

     % artsdsp kaudioserver

You will need to have installed kaudioserver (from the same source where you got your KDE1 applications from) - it belongs to KDE1, not KDE2.

13.2.8. What about applications using the enlightened sound daemon, ESD?

The issue is similar than with kaudioserver. Such applications will need a running esd server. You can start esd via artsdsp, and every ESD aware application should work fine, like this:

     % artsdsp esd

Prev | Home | Next
Questions and answers | Up | Latency