From e2de64d6f1beb9e492daf5b886e19933c1fa41dd Mon Sep 17 00:00:00 2001 From: toma Date: Wed, 25 Nov 2009 17:56:58 +0000 Subject: Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. BUG:215923 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdemultimedia@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- doc/artsbuilder/faq.docbook | 1112 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1112 insertions(+) create mode 100644 doc/artsbuilder/faq.docbook (limited to 'doc/artsbuilder/faq.docbook') diff --git a/doc/artsbuilder/faq.docbook b/doc/artsbuilder/faq.docbook new file mode 100644 index 00000000..c5b111ec --- /dev/null +++ b/doc/artsbuilder/faq.docbook @@ -0,0 +1,1112 @@ + + +Questions and answers + + +This section answers some frequently asked questions about &arts;. + + + +General Questions + + + + +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 (&ie; any other &Linux; application can output +sound), it will work. There are however some problems with some specific +hardware, please read the section +for hardware specific problems if you're having problems with artsd +on your machine. + + +Meanwhile also support for various other platforms has been added. Here is +a complete list of how the most recent version of &arts; can play sound. If +you have an unsupported platform, please consider porting &arts; to your +platform. + + + + + + +&arts; audio I/O method +Comment + + + + + +paud +Support for AIX Personal Audio Device + + + +alsa +Linux ALSA-0.5 and ALSA-0.9 drivers + + + +libaudioio +Support for generic LibAudioIO library which works on Solaris + + + +nas +NAS sound server, useful for X Terminals with NAS support + + + +null +Null audio device, discards sound silently + + + +oss +OSS (Open Sound System) support (works on Linux, various BSDs and + other platforms with OSS drivers installed) + + + +toss +Threaded OSS support, which works better in some cases where the + standard OSS support doesn't work well + + + +sgi +SGI Direct Media support for IRIX + + + +sun +Solaris support + + + + + + + + + + + +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 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: + + + + + +Log in as root. + + + + + +Open a &konqueror; window. + + + + + +Go into the /dev folder. + + + + + +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 +/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. + + + + + + + +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 + + + + + + + + +What can I do if artsd doesn't start or crashes while running? + + + + +First of all: try using the default settings in &kcontrol; (or if you +are starting manually, don't give additional options besides maybe +10 +4096 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 10 4096 + + +You can also add the option, which will print more +information about what is happening, like this: + +% artsd 10 4096 + + +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. + + + + + + +Can I relocate &artsd; (move compiled files to another +folder)? + + + + +You can't relocate &arts; perfectly. The problem is that &artswrapper; +has the location of &artsd; compiled in due to security reasons. You can +however use the .mcoprc file +(TraderPath/ExtensionPath entries) to at least make a relocated &artsd; +find it's components. See the chapter +about the .mcoprc file for details on how to +do this. + + + + + + +Can I compile &arts; with gcc-3.0? + + + + +Short answer: no, &arts; will not work if you compile it with gcc-3.0. + + + +Long answer: In the official release, there are two gcc-3.0 bugs which affect +&arts;. The first, gcc-3.0 bug c++/2733 is relatively harmless (and has to do +with problems with the asm statement). It breaks compilation of convert.cc. It +has been fixed in the gcc-3.0 CVS, and will no longer be a problem with +gcc-3.0.1 and higher. A workaround has also been added to the CVS version +of KDE/aRts. + + +The second gcc-3.0 bug, c++/3145 (which is generation of wrong code for some +cases of multiple virtual inheritance) is critical. Applications like &artsd; +will simply crash on startup when compiled with gcc-3.0. Even if some progress +has been made in the gcc-3.0 branch at time of this writing, still &artsd; +crashes quite often, unpredictably. + + + + + +What applications run under &arts;? + + + + +Obviously, all of the applications included with &kde; are +&arts;-aware. This includes: + + + +&noatun; +&arts-builder; +&aktion; +&kmid; +&kmidi; +&kmix; +&kscd; +&kde; games such as &kpoker; and +&ktuberling; + + + +Some &kde; applications that are not yet included in the &kde; release +(⪚ in kdenonbeta) also support &arts;, including: + + + +&brahms; +Kaboodle +Kdao + + + +The following non-&kde; applications are known to work with &arts;: + + + +xmms (with &arts; +plug-in) +Real Networks RealPlayer 8.0 +(works with &artsdsp;; native &arts; support is being +considered) + + + +The following applications are known not to work +with &arts;: + + + +none + + + +See also the answers to the questions in the section on +non-&arts; applications. + + + +This section is incomplete -- if you have more information on supported +and unsupported applications, please send them to the author so they can +be included here. + + + + + + + +Non-&arts; Applications + + + + +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. + + + + + + + +You said it suspends after 60 seconds, it doesn't for me! + + + + +If you start artsd from the KDE control panel, the default is to suspend +after 60 seconds. If you start artsd from the command line you need to +use the -s option to specify the autosuspend time, otherwise it will +default to disabling the autosuspend feature. + + +Currently it doesn't suspend when using full duplex. Turn full duplex +off from the &kcontrol; and it will suspend. Disabling full duplex is +generally a good idea anyway if you only use &arts; for playing audio +and not recording. + + + + + + + +How can I run old, non-&arts; applications? + + + + + +Run them using the &artsdsp;. For instance, if you normally would run: + + +% mpg123 + +instead use: + +% artsdsp + + +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. + + + + + + + +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. + + + + + + + +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). + + + + + + + +What can I do if an application doesn't work with &artsdsp;? + + + + +You can wait for &artsd; to suspend or use the command +artsshell + 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 ; killall +Now start your own application. +% kcminit + + + +Any currently running &arts; applications may crash, however, once you +kill the server. + + + + + + +What about applications written for &kde; 1.x? + + + + +If you are running &kde; 1.x applications, which output sound via the +&kde; 1 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 + + + +You will need to have installed kaudioserver (from the same source where +you got your &kde; 1.x applications from) - it belongs to &kde; 1.x, not +&kde; 2. + + + + + + + +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 + + +Newer versions of aRts (>= 1.2.0) also can also use the enlightened sound +daemon instead of directly accessing the soundcard. On the command line, you +can use the -a option, such as + + +% artsd + + +to get EsounD support, whereas in KDE, you can use kcontrol to configure artsd +to use esd via Sound -> Sound Server -> Sound I/O. + + + + + + + +Latency + + + + +I sometimes hear short pauses when listening to music, is this a bug? + + + + +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. + + + + + + + +What's the effect of the response time setting? + + + + +The help text for this setting in the &kcontrol; can be misleading. A +lower value means that &arts; will take less time to respond to external +events (&ie;. 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. + + + + + + +Is there anything else I can do to prevent pauses? + + + + +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 /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). + + + + + + + +Realtime priority doesn't seem to have any effect for me? + + + + +Verify that artswrapper is really installed suid root, like it is supposed to +be. A lot of distributions (SuSE7.x for instance) don't do this. You can verify +this using: ls -l $(which artswrapper). Good: + +% ls $(which artswrapper) +-rwsr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper + +Bad: + +% ls $(which artswrapper) +-rwxr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper + +If you are not having the s, you can get it using: + +% chown $(which artswrapper) +% chmod $(which artswrapper) + + + +If you make &artswrapper; SUID root, it will likely improve the quality +of your audio playback by reducing gaps in the music. However, it +also increases the risk that a bug in the code or a malicious user can +crash or otherwise harm your machine. In addition, on multi-user +machines, prioritizing high-quality audio may result in deteriorated +performance for the users who are trying to make +productive use of the machine. + + + + + + + + +Why is &artsd; taking so much CPU time? + + + + +Check your response time settings. However, the current 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. + + + + + + +Network Transparency + + + + +What do I need for network transparency? + + + + +Enable it in the &kcontrol; 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 (&ie; 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 5 8192 + + + +The 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/hosts (&ie; orion. if +your hostname is orion) +works around the problem. + + + + + + + + +How do I debug network transparency if it doesn't work? + + + + +Assuming you have the &kde; source code, go to kdelibs/arts/examples, and run +make to +compile some programs, including +referenceinfo. Then run + + + +% ./referenceinfo + + + +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. + + + + + + + +Hardware specific questions + + + + +What hardware artsd doesn't work well with? + + + + +It seems that there are a few linux drivers which don't work well with aRts in +some kernel versions. Please read this list before reporting a bug. If you +find that some information in this list is incomplete, please don't hesitate +to let us know. + + + + + +Linux Driver / Soundcard +Fails under +Works under +Remarks + + + + + +i810 driver (Intel 810 + AC97 Audio) +2.4.9 +2.4.18, 2.2.20, commercial oss driver, alsa-0.5.12a with OSS emulation +driver causes cpu overload (see below) + + + +maestro 3/4 chipset +2.4.9 +? +driver sometimes causes cpu overload (see below) + + + +aureal8820, aureal8830 drivers from sourceforge +2.4.17 +? +driver triggers assertion / causes cpu overload (see below) + + + +OSS Commercial 3.9.4g with Aureal Vortex +? +? +system lockup + + + +ymfpci +2.4.0, 2.4.12 +2.4.17 +driver triggers assertion (see below) + + + + + + + + + + + + + + + + +Why are there hardware specific problems and how do I see them? + + + + +The usual problem is that the driver doesn't supply aRts with enough or accurate +enough information on when to write sound data. Most OSS drivers do supply +correct information, but not all. + + +You might notice that some other applications (like xmms) may not need this +data, and thus work correctly even with your hardware. However, &arts; needs +this data, so artsd might fail. This is still a bug in the driver, and not +in &arts;. + + +There are two kinds of behavior that artsd exposes on being run on an incorrect +driver. Either, it continously tries to feed new data, but never really +succeeds, which eventually leads to consuming all CPU power and reporting +cpu overload and exiting. The other problem is that artsd +might get supplied with wrong information how much to write. Artsd will then +stop with an assertion like: + +artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): +Assertion `len == can_write' failed. +Aborted + + + + + + + + +What is wrong in the driver if I get the cpu overload problem? + + + + +Usually, artsd uses select() to find out when to write new data. Then, it +uses an ioctl(...GETOSPACE...) to find out how much data to write. Finally, +it writes this data. + + +A problem occurs if artsd is woken up either always or if there are minimal +amounts of data to write. The OSS documentation specifies that select() only +wakes up a process if there is at least one fragment to write. However, if +artsd is woken up if there isn't data to write, or very little, for instance +one sample, then it will keep writing little pieces of audio data, which can +be very costly, and eventually overload the cpu. + + +To fix this, the driver should wake up artsd only if there is a full fragment +to write. + + + + + + + +What is wrong in the driver if I get the assertion? + + + + +Usually, artsd uses select() to find out when to write new data. Then, it +uses an ioctl(...GETOSPACE...) to find out how much data to write. Finally, +it writes this data. + + +If artsd can't write as much data as indicated by the ioctl, it will fail in +the assertion. To fix this, the driver should supply the correct amount of +free space. + + + + + + +Other Issues + + + + +I can't use &arts-builder;. It crashes when executing a module! + + + + +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 &arts-builder; 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 &arts-builder; help file (hit +F1 in &arts-builder;). + + + +Recent versions of &arts-builder; (&kde; 2.1 beta 1 and later) come with +a set of examples which you can use. + + + + + + + -- cgit v1.2.1