Does KDE support my soundcard for audio output?
KDE uses aRts to play sounds. aRts bases on your normal Linux sound drivers, either OSS or ALSA (using the OSS emulation). So if your soundcard is supported by either ALSA or OSS (i.e. any other Linux app can output sound), it will work.
Is there sound support if I am not using Linux?
Only if there are OSS (compatible) drivers for your platform (i.e. FreeBSD). Feel free to contribute. Simply rewrite audiosubsys.cc in kdelibs/arts/flow.
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.
I have sound as root but no users have sound?
The permissions of the file /dev/dsp affect which users will have sound. To allow everybody to use it, do this:
You can achieve the same effect in a terminal window using the command
chmod 666 /dev/dsp
For exactly limiting which users may access sound, you can use a group. On some linux distributions, for instance debian/potatoe, /dev/dsp is already owned by a group called audio, so the only thing you need to do is adding users to the group.
This does help for artsd, but what about kmix, kmid, kscd?
There are various other devices which provide functionality accessed by multimedia apps. You can treat them in the same way, either by making them accessible for everybody, or using groups to control access. Here is a list, which may still be incomplete (also if there are various devices of a kind like midi0, midi1, ..., then only the 0-version is listed here):
/dev/audio, /dev/dsp, /dev/midi0, /dev/midi00, /dev/mixer, /dev/mpu401data, /dev/mpu401stat, /dev/rmidi0, /dev/sequencer, /dev/smpte0, /dev/sndstat, /dev/cdrom, /dev/rtc
As soon as KDE is running, no other application can access my sound device?
Yes, since the aRts sound server KDE uses is running, it is using the sound device. If it is idle for 60 seconds, it will release it automatically (auto-suspend).
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 and it will suspend. Turning it off is a good idea anyway if you only use aRts for playing things.
What should I do to run old, non-aRts applications?
Start them with artsdsp. For instance, if you normally would run
mpg123 foo.mp3
use
artsdsp mpg123 foo.mp3
now - this will redirect the sound output to aRts. As you see this method doesn't require changing existing apps. It is a bit hacky however, and does not yet fully support all features of the soundcard right now, so some apps might not work.
I can't run artsdsp on any app, it always crashes?
You need a more or less modern version of the glibc library, so artsdsp will not work reliable on older linux distributions. For instance, on debian/slink it doesn't work, on debian/potato (which is glibc 2.1.3 based), it does.
Are there theoretical limits which apps will never work with artsdsp?
No. Of course artsdsp will have a little more latency and a little more CPU usage. Other than that, consider every app that doesn't work with artsdsp a bug in artsdsp. Basically the way artsdsp works should, if implemented properly, make EVERY app work with it (including stuff like quake3).
What do I do if an app doesn't work with artsdsp?
You can wait for artsd to suspend or use the artsshell suspend command 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 brutal but working way to get rid of it is
killall artsd ; killall artswrapper
<start app here>
kcminit arts
Some aRts apps might crash, though, once you kill the server.
I sometimes get short pauses when listening to music, is this a bug?
This is no bug in aRts unfortunately, most likely your problem is caused since the linux kernel is not really good at realtime scheduling. There are situations where aRts will not be able to keep up with playback. You can however enable realtime rights (via KControl), and use a large latency setting (like 250ms or don't care), which should make it better.
Whats the effect of the response time setting anyway?
A lower value means that aRts will take less time to respond to external events (i.e. time time that it takes between closing a window and hearing a sound played by artsd), will use more cpu, and more likely cause dropouts.
The help text (in kcontrol) is irritating.
Is there anything else I can do to prevent pauses?
For users of IDE drives, you can use hdparm to set your IDE drive to the DMA mode. Warning: this may not work on your computer, which would mean that you have to do a hard reset. Probably you better read the hdparm documentation first. Anyway, I am using the following quite successful:
hdparm -c1 -d1 -k1 -K1 /dev/hda
You need to repeat that after every boot, so you might want to place it in a startup script (where you do it is distribution specific, for debian these are /etc/rc.boot).
Why is artsd taking that much CPU time?
Check your response time settings. On the other hand, the KDE2.0 version is not yet really optimized. This will improve, and until then no real prediction can be made how fast artsd can or can't be.
What do I need for network transparency?
Enable it in kcontrol (enable X11 server for security information and network transparency). Then go and copy your .mcoprc to all machines you plan to use network transparency from. Relogin. Make sure that the hosts that interact know each other by name (i.e. make sure that they have resolvable names or are in /etc/hosts).
This should be all you need to do. Anyway, here are a few more internals which may help you if things don't work at once.
The aRts sound server process "artsd" should only run one host, the one with the soundcard, 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 for GlobalComm:
GlobalComm=Arts::X11GlobalComm
for network transparency to work, on all machines involved. This is what KDE will put there if you enable "X11 server for security information" there.
Finally, in any KDE version in the 2.0.x series, there is a bug which applies if you don't have a domainname set. Clients of artsd try to find where to connect to via the <hostname>.<domainname> combination. If your domainname is empty, it will try to connect <hostname>. <- note the dot is too much. Adding an entry like this to /etc/hosts (i.e. orion. if your hostname is orion) works around the problem.
Can I debug it if it doesn't work?
Yes, if you have the source. go to kdelibs/arts/examples, make check there, then run
referenceinfo global:Arts_SimpleSoundServer
there you'll see what hostname and port aRts. For instance tcp:orion:1698 would mean that any client trying to use artsd network transparent should know how to reach "orion".
I can't use artsbuilder, it crashes on executing something?
The most likely cause is that you are using structures or modules which you shouldn't use with the KDE2.x version. Currently, unfortunately the documentation which is on the web refers to aRts-0.3.4.1, and like this is quite somewhat outdated.
The most often reported crash is:
> doing "execute structure" in artsbuilder results in the following: > > [artsd] Synth_PLAY: audio subsystem is already used
You should use a Synth_AMAN_PLAY instead of a Synth_PLAY module here, and the problem will go away - see also: artsbuilder help file (hit F1 in artsbuilder).
More recent artsbuilder versions (KDE2.1 beta 1 and higher) come with a set of examples, which you can use.
| Back to the index | stw@kde.org |