<para>&kde; använder &arts; för att spela upp ljud, och &arts; använder ljuddrivrutinerna i &Linux; kärna, antingen <acronym>OSS</acronym> eller <acronym>ALSA</acronym> (med emulering av <acronym>OSS</acronym>). Om ditt ljudkort antingen stöds av <acronym>ALSA</acronym> eller <acronym>OSS</acronym> och är riktigt inställt (dvs. alla andra &Linux;-program kan spela upp ljud), kommer det att fungera. Det finns dock några problem med specifik hårdvara, läs <link linkend="faq-hardware-specific">avsnittet om hårdvaruspecifika problem</link> om du får problem med artsd på din dator. </para>
<para>Under tiden har också stöd för diverse andra plattformar lagts till. Här är en fullständig lista över hur den senaste versionen av &arts; kan spela ljud. Om du har en plattform som inte stöds, fundera gärna på att anpassa &arts; till din plattform. </para>
<para>Kontrollera att &artsd; är länkad till <filename>libaudiofile</filename> (<userinput><command>ldd</command> <parameter>artsd</parameter></userinput>). Om den inte är det, ladda ner tdesupport, kompilera om allt, och det kommer att fungera. </para>
<para>Rättigheterna för filen <filename class="devicefile">/dev/dsp</filename> påverkar vilka användare som har ljud. För att låta alla använda den, gör så här: </para>
<para>Du kan uppnå samma effekt i ett terminalfönster med kommandot <userinput><command>chmod</command> <option>666</option> <parameter>/dev/dsp</parameter></userinput>. </para>
<para>För att begränsa tillgången av ljud till särskilda användare kan du använda gruppskydd. För vissa &Linux;-distributioner, till exempel Debian/Potato, ägs <filename class="devicefile">/dev/dsp</filename> redan av en grupp som heter <systemitem class="groupname">audio</systemitem>, så allt du behöver göra är att lägga till användarna till den här gruppen. </para>
<para>Det finns diverse andra enheter som tillhandahåller funktioner som ska kommas åt av multimediaprogram. Du kan behandla dem på samma sätt, antingen genom att göra dem tillgängliga för alla, eller använda grupper för att kontrollera åtkomsten. Här är en lista, som fortfarande kan vara ofullständig (dessutom om det finns flera enheter på formen <filename class="devicefile">midi0</filename>, <filename class="devicefile">midi1</filename>..., så finns bara 0-versionen med): </para>
<para>Försök först att använda de förvalda inställningarna i inställningscentralen (eller om du startar manuellt, ange inga extra väljare utom eventuellt <userinput><option>-F</option><parameter>10</parameter> <option>-S</option><parameter>4096</parameter></userinput> för latenstid). Särskilt <emphasis>full duplex fungerar troligen inte</emphasis> med diverse drivrutiner, så försök stänga av det. </para>
<para>Ett bra sätt att räkna ut varför &artsd; inte startar (eller kraschar när den kör) är att starta den manuellt. Öppna ett &konsole;-fönster och skriv: </para>
<para>Genom att göra detta får du förmodligen någon användbar information om varför den inte startade. Eller om den kraschar medan något särskilt pågår, kan du göra det och se <quote>hur</quote> den kraschar. Om du vill rapportera ett fel, kan en bakåtspårning skapad med <command>gdb</command> och/eller en <command>strace</command> hjälpa till att hitta problemet. </para>
<para>Du kan inte flytta &arts; helt perfekt. Problemet är att &artswrapper; har platsen för &artsd; inkompilerad av säkerhetsskäl. Du kan i alla fall använda <filename>.mcoprc</filename>-filen (TraderPath/ExtensionPath posterna) för att åtminstone få en flyttad &artsd; att hitta sina komponenter. Se <link linkend="the-mcoprc-file">kapitlet om <filename>.mcoprc</filename>-filen</link> för detaljer om hur man gör detta. </para>
<para>Långt svar: i den officiella utgåvan av gcc-3.0, finns det två fel som påverkar &arts;. Det första problemet med gcc-3.0, c++/2733, är ganska ofarligt (och har att göra med problem med asm-satsen). Det gör att convert.cc inte kan kompileras. Det har rättats i gcc-3.0 CVS, och kommer inte att vara ett problem med gcc-3.0.1 och senare. Ett sätt att gå förbi problemet har också lagts till i CVS-versionen av KDE/aRts. </para>
<para>Det andra problemet med gcc-3.0, c++/3145 (som orsakar felaktig kodgenerering för vissa fall av multipla virtuellt arv) är kritisk. Program som &artsd; kraschar helt enkelt när de startas om de har kompilerats med gcc-3.0. Även om vissa framsteg har gjorts i gcc-3.0 grenen när det här skrivs, kraschar fortfarande &artsd; väldigt ofta, oförutsägbart. </para>
<para>Det här avsnittet är ofullständigt. Om du har mer information om program som stöds eller inte, var vänlig skicka dem till upphovsmannen så att de kan läggas till här. </para>
<para>Eftersom &arts;-ljudservern som används av &kde; kör, använder den ljudenheten. Om servern är oanvänd i 60 sekunder, går den till vänteläge och släpper enheten automatiskt. </para>
<para>Om du startar artsd från KDE:s inställningscentral, är det förvalda värdet att gå till vänteläge efter 60 sekunder. Om du startar artsd från kommandoraden måste du använda väljaren -s för att ange väntelägesvärdet, annars är det förvalda beteendet att stänga av väntelägesfunktionen. </para>
<para>För närvarande går servern inte till vänteläge om full duplex används. Stäng av full duplex i inställningscentralen så går den till vänteläge. Att stänga av full duplex är i allmänhet en bra idé ändå, om du bara använder &arts; för att spela upp ljud och inte för att spela in. </para>
<para>Det här skickar ljudutmatning till &arts;. Den här metoden kräver inte några ändringar i programmet. Den är ändå något av en ful snabbfix, och stöder ännu inte alla funktioner i ljudkortsenheten, så vissa program kanske inte fungerar. </para>
<para>Du behöver en aktuell version av glibc-bilblioteket. &artsdsp; fungerar inte tillförlitligt på vissa äldre &Linux;-distributioner. Till exempel på Debian 2.1 (som är baserat på glibc 2.0) fungerar den inte, medan på Debian 2.2 (som är baserat på glibc 2.1.3), gör den det. </para>
<para>Nej. Att använda &artsdsp; kan resultera i något högre latenstider och <acronym>CPU</acronym>-användning än att använda &arts; programmeringsgränssnitt direkt. Förutom det, ska alla program som inte fungerar anses som ett fel i &artsdsp;. Tekniken som används av &artsdsp; ska, om den är riktigt implementerad, tillåta <emphasis>varje</emphasis> program att fungera med den (inklusive stora program som <application>Quake</application> 3). </para>
<para>Du kan vänta på att &artsd; går till vänteläge eller använda kommandot <userinput><command>artsshell</command> <option>suspend</option></userinput> för att begära att servern ska gå till vänteläge. Du kommer bara kunna få servern att gå till vänteläge om inget &arts;-program använder den för närvarande, och inga &arts;-program kan köra medan servern är i vänteläge. </para>
<para>Om servern är upptagen ser ett grovt men effektivt sätt att bli av med den ut så här: </para>
<para>Om du kör &kde; 1.x program, som spelar upp ljud via ljudservern i &kde; 1, måste du köra <application>kaudioserver</application> för att det ska fungera. Du kan starta <application>kaudioserver</application> på samma sätt som andra program som inte stöder &arts;: </para>
<para>Det här problemet liknar fallet med <application>kaudioserver</application>. Sådana program kräver en esd-server som kör. Du kan starta <command>esd</command> via &artsdsp;, och alla program som stöder <acronym>ESD</acronym> ska fungera bra, så här: </para>
<para>Nyare versioner av aRts (>= 1.2.0) kan också använda Enlightened Sound Daemon istället för direkt åtkomst av ljudkortet. På kommandoraden kan du använda väljaren -a, på följande sätt </para>
<para>för att få stöd för ESD. I stället, i KDE, kan du använda Inställningscentralen för att anpassa artsd att använda ESD, via Ljud -> Ljudserver -> Ljud I/O. </para>
<para>Det här är troligen inget fel, utan orsakas av det faktum att &Linux; kärna inte är särskilt bra på realtidsschemaläggning. Det finns situationer då &arts; inte kan hänga med i uppspelningen. Du kan dock aktivera realtidsrättigheter (via inställningscentralen), och använda en stor latenstidsinställning (som <guilabel>250 ms</guilabel> eller <guilabel>så stor som möjligt</guilabel>), vilket bör förbättra situationen. </para>
<para>Hjälptexten för den här inställningen i inställningscentralen kan vara förvirrande. Ett lägre värde betyder att &arts; reagerar snabbare på yttre händelser (dvs tiden det tar mellan ett fönster stängs och ljudet spelas av &artsd;). Den kommer också att använda mer <acronym>CPU</acronym>-resurser och vara mer benäget att orsaka pauser i ljudet.</para>
<para>För användare av <acronym>IDE</acronym>-enheter, kan man använda kommandot <command>hdparm</command> för att ställa in din <acronym>IDE</acronym>-enhet att använda <acronym>DMA</acronym>-läge. Ett varningens ord: Det här fungerar inte med all sorts hårdvara, och kan orsaka att man måste göra en hårdvaruåterställning, eller i ovanliga fall, förlust av data. Läs dokumentationen för kommandot <command>hdparm</command> för mer detaljer. Jag har använt följande kommando med lyckat resultat: </para>
<para>Du måste köra det här efter varje omstart, så du kanske vill lägga det i ett uppstartsskript för systemet (hur man gör detta är specifikt för varje distribution, på Debian &Linux; läggs det oftast i <filename>/etc/rc.boot</filename>). </para>
<para>Kontrollera att artswrapper verkligen är installerad suid <systemitem class="username">root</systemitem>, som det är meningen att den ska vara. Många distributioner (till exempel SuSE7.x) gör inte detta. Du kan kontrollera det med: ls -l $(which artswrapper). Bra: <screen>
</screen> Om du inte har med s:et, kan du få det med: <screen><prompt>%</prompt> <userinput><command>chown</command> <option>root</option> <parameter>$(which artswrapper)</parameter></userinput>
<para>Om du gör &artswrapper; SUID <systemitem class="username">root</systemitem>, kommer det troligen förbättra kvaliteten på ljudåtergivningen genom att reducera uppehåll i musiken. Dock ökar det också risken att ett fel i koden, eller en användare med uppsåt att skada kan krascha eller skada datorn på något sätt. Dessutom, att prioritera hög ljudkvalitet på fleranvändardatorer kan orsaka försämrad prestanda för användare som försöker använda datorn på ett <quote>produktivt</quote> sätt.</para>
<para>Kontrollera dina svarstidsinställningar. Dessutom är den nuvarande versionen inte egentligen optimerad. Det här kommer att bli bättre, och till dess kan inte någon riktig förutsägelse göras om hur snabb &artsd; kan vara. </para>
<para>Aktivera det i inställningscentralens inställningar för <guilabel>Ljudserver</guilabel> (<guilabel>Utbyt säkerhets- och referensinformation över X11-servern</guilabel> och <guilabel>Aktivera nätverkstransparens</guilabel>). Kopiera sedan din <filename>.mcoprc</filename>-fil till alla maskiner som du tänker använda nätverkstransparensen från. Logga in igen. Försäkra dig om att värddatorerna som ska samarbeta känner till varandras namn (dvs. de har namn som kan lösas upp eller finns i <filename>/etc/hosts</filename>). </para>
<para>Det här bör vara allt du behöver göra. Om det inte fungerar ändå, följer några ytterligare detaljer. &arts; ljudserverprocess &artsd; ska bara köras på en värddator, den med ljudkortet där ljud ska spelas upp. Den kan startas automatiskt vid inloggning av &kde; (om du anger det i inställningscentralen), eller manuellt med någonting i stil med: </para>
<para>för alla maskiner som är inblandade, för att nätverkstransparens ska fungera. Det är det här som aktiveras av inställningen <guilabel>Utbyt säkerhets- och referensinformation över X11-servern</guilabel> i inställningscentralen. </para>
<para>Till sist, i alla &kde;-versioner i 2.0.x serien, finns det ett fel som visar sig om du inte har ett domännamn inställt. Klienter till &artsd; försöker hitta anslutningen via kombinationen av <systemitem class="systemname"><replaceable>värddatornamn</replaceable>.<replaceable>domännamn</replaceable></systemitem>. Om domännamnet är tomt, försöker de ansluta till <systemitem class="systemname"><replaceable>värddatornamn</replaceable></systemitem>. (observera den extra punkten). Att lägga till en post som ser ut så här i <filename>/etc/hosts</filename> (dvs <userinput>orion.</userinput> om värddatornamnet är <systemitem class="systemname">orion</systemitem>) gör att man undviker problemet. </para>
<para>Om du har &kde;:s källkod, gå till <filename class="directory">tdelibs/arts/examples</filename>, och kör <userinput><command>make</command> <option>check</option></userinput> för att kompilera några program, inklusive <application>referenceinfo</application>. Kör sedan </para>
<para>Utmatningen anger värddatornamnet och porten som används av &arts;. Till exempel, <computeroutput>tcp:orion:1698</computeroutput> skulle betyda att alla klienter som försöker använda nätverkstransparens måste veta hur värddatorn <systemitem class="systemname">orion</systemitem> kan nås. </para>
<para>Det verkar som om det finns några få Linux-drivrutiner som inte fungerar bra tillsammans med aRts för vissa versioner av kärnan. Läs först den här listan innan du rapporterar ett fel. Om du märker att informationen i listan inte är fullständig, tveka inte att tala om det för oss. <informaltable> <tgroup cols="4">
<para>De vanliga problemen är att drivrutinen inte ger aRts tillräcklig eller tillräckligt noggrann information om när ljuddata ska skrivas. De flesta OSS-drivrutiner ger riktig information, men inte alla. </para>
<para>Du kan märka att vissa andra program (som xmms) inte behöver den här informationen, och därför fungerar på ett riktigt sätt till och med för din hårdvara. Men &arts; behöver den här informationen, så artsd kan sluta fungera. Det här är fortfarande ett fel i drivrutinen, och inte i &arts;. </para>
<para>Det finns två sorters beteende som artsd påvisar när den körs med en felaktig drivrutin. Antingen försöker den skicka ny data, men lyckas egentligen aldrig, vilket till slut leder till att för mycket CPU-last används, att detta rapporteras, och att den avslutas. Det andra problemet är att artsd kan få fel information om hur mycket data som ska skrivas. Då <emphasis>stoppar</emphasis> artsd med ett felmeddelande som: <screen>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
<para>Oftast använder artsd anropet select() för att ta reda på när ny data ska skrivas. Därefter använder den anropet ioctl(...GETOSPACE...), för att ta reda på hur mycket data som ska skrivas. Till sist skriver den data. </para>
<para>Ett problem uppstår om artsd antingen alltid väcks, eller om det finns mycket lite data att skriva. OSS-dokumentationen anger att anropet select() bara väcker en process om det finns minst ett fragment att skriva. Om artsd väcks när det inte finns någon, eller mycket lite, data att skriva, till exempel en sampling, försöker den skriva småbitar med ljuddata, vilket kan bli mycket kostsamt, och till slut ge för mycket CPU-last. </para>
<para>För att rätta detta, ska drivrutinen bara väcka artsd om ett helt fragment kan skrivas. </para>
<para>Oftast använder artsd anropet select() för att ta reda på när ny data ska skrivas. Därefter använder den anropet ioctl(...GETOSPACE...), för att ta reda på hur mycket data som ska skrivas. Till sist skriver den data. </para>
<para>Om artsd inte kan skriva så mycket data som anges av anropet ioctl, så stoppar den med felmeddelandet ovan. För att rätta detta, ska drivrutinen ange rätt storlek på det lediga utrymmet. </para>
<para>Den troligaste orsaken är att du använder gamla strukturer eller moduler som inte stöds i &kde; 2 versionen. Tyvärr gäller dokumentationen på nätet &arts;-0.3.4.1 som är helt föråldrad. Den oftast rapporterade kraschen är att om en struktur körs i aRts-byggaren fås felmeddelandet <errorname>[artsd] Synth_PLAY: ljuddelsystemet används redan.</errorname> </para>
<para>Du måste använda en Synth_AMAN_PLAY modul istället för Synth_PLAY och problemet försvinner. Se också aRts-byggarens hjälpfil (tryck på <keycap>F1</keycap> i aRts-byggaren). </para>
<para>Senare versioner av aRts-byggaren (&kde; 2.1 beta 1 och senare) levereras med ett antal exempel som du kan använda. </para>
