<para>&kde; bruger &arts; til at afspille lyd, og &arts; bruger driverne kernen for &Linux;, enten <acronym>OSS</acronym> eller <acronym>ALSA</acronym> (med emulering af <acronym>OSS</acronym>). Hvis dit lydkort enten understøttes af <acronym>ALSA</acronym> eller <acronym>OSS</acronym> og er rigtigt indstillet (dvs. alle andre &Linux;-programmer kan afspille lyd), kommer det til at virke. Der er dog nogle problemer med specifik hardware, læs <link linkend="faq-hardware-specific">afsnittet om hardwarespecifikke problemer</link> hvis du har problemer med artsd på din maskine. </para>
<para>I mellemtiderne er støtte for diverse andre platforme også tilføjet. Her er en fuldstændig liste over hvordan den seneste version af &arts; kan afspille lyd. Hvis du har en platform som ikke understøttes, så overvej gerne at overføre &arts; til din platform. </para>
<para>Tjek at &artsd; er linket til <filename>libaudiofile</filename> (<userinput><command>ldd</command> <parameter>artsd</parameter></userinput>). Hvis den ikke er det, så hent tdesupport, kompilér alt, og det vil virke. </para>
<para>Tilladelserne for filen <filename class="devicefile">/dev/dsp</filename> påvirker hvilke brugere der har lyd. For at lade alle bruge den, gør sådan her: </para>
<para>Du kan opnå samme virkning i et terminalvindue med kommandoen <userinput><command>chmod</command> <option>666</option> <parameter>/dev/dsp</parameter></userinput>. </para>
<para>For at begrænse adgangen af lyd til særlige brugere kan du bruge gruppetilladelser. For visse &Linux;-distributioner, for eksempel Debian/Potato, ejes <filename class="devicefile">/dev/dsp</filename> allerede af en gruppe som hedder <systemitem class="groupname">audio</systemitem>, så alt du behøver gøre er at tilføje brugerne til denne gruppe. </para>
<para>Der er forskellige andre enheder som sørger for funktioner som der skal være adgang til for multimedieprogrammer. Du kan behandle dem på samme måde, enten ved at gøre dem tilgængelige for alle, eller bruge grupper for at kontrollere adgangen. Her er en liste, som måske stadigvæk er ufuldstændig (og hvis der er flere enheder på formen <filename class="devicefile">midi0</filename>, <filename class="devicefile">midi1</filename>..., så er 0-versionen kun med): </para>
<para>Forsøg først at bruge standardindstillingerne i &kcontrol; (eller hvis du starter manuelt, angive ingen ekstra flag bortset fra eventuelt <userinput><option>-F</option><parameter>10</parameter> <option>-S</option><parameter>4096</parameter></userinput> for latenstid). Særlig <emphasis>fuld dupleks virker formodentlig ikke</emphasis> med diverse drivere, så forsøg at deaktivere det. </para>
<para>En god måde at regne ud hvorfor &artsd; ikke starter (eller bryder sammen når den kørt) er at starte den manuelt. Åbn et &konsole;-vindue og skriv: </para>
<para>Ved at gøre dette får du formodentlig nogen nyttig information om hvorfor den ikke startede. Eller hvis den bryder sammen mens noget særligt foregår, kan du gøre det og se <quote>hvordan</quote> den bryder sammen. Hvis du vil rapportere en fejl, kan et backtrace oprettet med <command>gdb</command> og/eller en <command>strace</command> hjælpe med til at finde problemet. </para>
<para>Du kan ikke flytte &arts; helt perfekt. Problemet er at &artswrapper; har stedet for &artsd; indkompileret af sikkerhedsgrunde. Du kan imidlertid bruge <filename>.mcoprc</filename>-filen (TraderPath/ExtensionPath indgangene) til i det mindste at få en flyttet &artsd; til at finde sine komponenter. Se <link linkend="the-mcoprc-file">kapitlet om <filename>.mcoprc</filename>-filen</link> for detaljer om hvordan man gør dette. </para>
<para>Langt svar: i den officielle udgave af gcc-3.0, er der to fejl som påvirker &arts;. Det første problem med gcc-3.0, c++/2733, er ganske ufarligt (og har at gøre med problemer med asm-sætningen). Det gør at convert.cc ikke kan kompileres. Dette er rettet i gcc-3.0 CVS, og vil ikke være et problem med gcc-3.0.1 og senere. En måde at gå udenom problemet er også tilføjet i CVS-versionen af KDE/aRts. </para>
<para>Det andet problem med gcc-3.0, c++/3145 (som forårsager fejlagtig kodegenerering i visse tilfælde af multipel virtuel arv) er kritisk. Programmer som &artsd; bryder helt enkelt sammen når de startes hvis de er kompileret med gcc-3.0. Selvom visse fremskridt er gjort i gcc-3.0 grenen når dette skrives, bryder &artsd; stadigvæk vældigt ofte sammen, uforudsigeligt. </para>
<para>Dette afsnit er ufuldstændigt. Hvis du har mere information om programmer som understøttes eller ej, så vær venlig at sende dem til forfatteren så at de kan tilføjes her. </para>
<para>Når &arts;-lydserveren som bruges af &kde; kører, bruger den lydenheden. Hvis serveren er i tomgang i 60 sekunder, går den i autosuspension og slipper enheden automatisk. </para>
<para>Hvis du starter artsd fra KDE's kontrolcenter, er det standardværdien at gå i autosuspension efter 60 sekunder. Hvis du starter artsd fra kommandolinjen skal du bruge flaget -s for at angive ventetilstandsværdien, ellers er det standardopførsel at lukke af for autosuspensionsfunktionen. </para>
<para>For øjeblikket går serveren ikke i autosuspension hvis fuld dupleks bruges. Luk af for fuld dupleks i kontrolcentret så går den i autosuspension. At lukke af for fuld dupleks er i almindelighed en god idé alligevel, hvis du kun bruger &arts; til at afspille lyd og ikke til at indspille. </para>
<para>Dette sender lyduddata til &arts;. Denne metode kræver ikke nogen ændringer i programmet. Det er noget af et grimt fiks, og understøtter endnu ikke alle funktioner i lydkortsenheden, så visse programmer virker måske ikke. </para>
<para>Du behøver en ny udgave af glibc-bilblioteket. &artsdsp; virker ikke tilforladeligt på visse ældre &Linux;-distributioner. For eksempel på Debian 2.1 (som er baseret på glibc 2.0) virker den ikke, mens den gør det på Debian 2.2 (som er baseret på glibc 2.1.3). </para>
<para>Nej. Brugen &artsdsp; kan resultere i noget højere latenstider og <acronym>CPU</acronym>-brug end at bruge &arts; programmeringsgrænseflade direkte. Udover det, skal alle program som ikke virker anses som en fejl i &artsdsp;. Teknikken som bruges af &artsdsp; skal, hvis den er rigtigt implementeret, tillade <emphasis>hvert</emphasis> program at virke med den (inklusive store programmer såsom <application>Quake</application> 3). </para>
<para>Du kan vente på at &artsd; går i autosuspension eller bruge kommandoen <userinput><command>artsshell</command> <option>suspend</option></userinput> for at bede at servere om at gå i autosuspension. Du kommer kun til at kunne få serveren til at gå i autosuspension hvis intet &arts;-program bruger den for øjeblikket, og ingen &arts;-programmer kan køre mens serveren er i autosuspension. </para>
<para>Hvis serveren er optaget ser en grov men effektivt måde at slippe af med den sådan her ud: </para>
<para>Hvis du kører &kde; 1.x programmer, som afspiller lyd via lydserveren i &kde; 1, skal du køre <application>kaudioserver</application> for at det skal virke. Du kan starte <application>kaudioserver</application> på samme måde som andre programmer som ikke understøtter &arts;: </para>
<para>Dette problem ligner tilfældet med <application>kaudioserver</application>. Sådanne programmer kræver en esd-server som kører. Du kan starte <command>esd</command> via &artsdsp;, og alle programmer som understøtter <acronym>ESD</acronym> vil så virke godt, sådan her: </para>
<para>Nyere versioner af aRts (>= 1.2.0) kan også bruge Enlightened Sound Daemon i stedet for direkte adgang til lydkortet. På kommandolinjen kan du bruge flaget -a, på følgende måde </para>
<para>til at få understøttelse af ESD. I stedet for, i KDE, kan du bruge kontrolcentret til at indstille artsd til at bruge ESD, via Lyd -> Lydserver -> Lyd I/O. </para>
<para>Dette er formodentlig ikke en fejl, men forårsages af det faktum at &Linux; kernen ikke er særlig god til realtidsskemalægning. Der er situationer hvor &arts; ikke kan følge med i afspilningen. Du kan dog aktivere realtidsrettigheder (via kontrolcentret), og bruge en stor latenstidsindstilling (såsom <guilabel>250 ms</guilabel> eller <guilabel>så stor som muligt</guilabel>), hvilket bør forbedre situationen. </para>
<para>Hjælpeteksten for denne indstilling i kontrolcentret kan være forvirrende. En lavere værdi betyder at &arts; reagerer hurtigere på ydre begivenheder (dvs. tiden det tager mellem et vindue lukkes og lyden afspilles af &artsd;). Den kommer også til at bruge flere <acronym>CPU</acronym>-ressourcer og det vil være mere sandsynligt med pauser i lyden.</para>
<para>For brugere af <acronym>IDE</acronym>-enheder, kan man bruge kommandoen <command>hdparm</command> til at indstille din <acronym>IDE</acronym>-enhed til at bruge <acronym>DMA</acronym>-tilstand. Et advarselsord: Dette virker ikke med alle slags hardware, og kan forårsage at man skal lave en hardware-nulstilling, eller i sjældne tilfælde, tab af data. Læs dokumentationen for kommandoen <command>hdparm</command> for flere detaljer. Jeg har brugt følgende kommando med heldigt resultat: </para>
<para>Du skal køre dette efter hver boot, så måske vil du tilføje det i et opstartsscript for systemet (hvordan man gør dette er specifikt for hver distribution, på Debian &Linux; tilføjes det oftest i <filename>/etc/rc.boot</filename>). </para>
<para>Kontrollér at artswrapper virkelig er installeret suid <systemitem class="username">root</systemitem>, som det er meningen at den skal være. Mange distributioner (for eksempel SuSE7.x) gør ikke dette. Du kan kontrollere det med: ls -l $(which artswrapper). Godt: <screen>
</screen> Hvis du ikke har s'et med, kan du få det med: <screen><prompt>%</prompt> <userinput><command>chown</command> <option>root</option> <parameter>$(which artswrapper)</parameter></userinput>
<para>Hvis du gør &artswrapper; SUID <systemitem class="username">root</systemitem>, kommer det formodentlig til at forbedre kvaliteten på lydafgivelsen ved at reducere ophold i musikken. Dog øger det også risikoen for at en fejl i koden, eller en bruger med lyst til at skade kan få maskinen til at bryde sammen eller skade på anden måde. Desuden, at prioritere høj lydkvalitet på flerbrugermaskiner kan forårsage forværret ydelse for brugere som forsøger at bruge maskinen på en <quote>produktiv</quote> måde.</para>
<para>Kontrollér dine svarstidsindstillinger. Desuden er den nuværende version ikke egentlig optimeret. Dette vil blive bedre, og indtil da kan det ikke rigtigt forudsiges hvor hurtig &artsd; kan eller ikke kan være. </para>
<para>Aktivér det i kontrolcentrets indstillinger for <guilabel>Lydserver</guilabel> (<guilabel>Aktivér sikkerheds- og referenceinformation for X11-serveren</guilabel> og <guilabel>Aktivér netværkstransparens</guilabel>). Kopiér derefter din <filename>.mcoprc</filename>-fil til alle maskiner som du vil bruge netværkstransparensen fra. Log på igen. Sørg for at værtsmaskinerne som skal samarbejde kender hinandens navne (dvs. de har navne som kan opløses eller findes i <filename>/etc/hosts</filename>). </para>
<para>Dette skulle være alt du behøver at gøre. Hvis det ikke virker alligevel, følger nogen yderligere detaljer. &arts; lydserverprocessen &artsd; skal kun køres på en værtsmaskine, den med lydkortet hvor lyden skal afspilles. Den kan startes automatisk ved indlogning til &kde; (hvis du angiver det i kontrolcentret), eller manuelt med noget i retning af: </para>
<para>for alle maskiner som er involverede, for at netværkstransparens skal virke. Det er dette som aktiveres af indstillingen <guilabel>Aktivér sikkerheds- og referenceinformation over X11-serveren</guilabel> i kontrolcentret. </para>
<para>Til sidst, i alle &kde;-versioner i 2.0.x serien, er der en fejl som viser sig hvis du ikke har et domænenavn indstillet. Klienter for &artsd; forsøger at finde en forbindelse via kombinationen af <systemitem class="systemname"><replaceable>værtsmaskinenavn</replaceable>.<replaceable>domænenavn</replaceable></systemitem>. Hvis domænenavnet er tomt, forsøger de at forbinde til <systemitem class="systemname"><replaceable>værtsmaskinenavn</replaceable></systemitem>. (læg mærke til det ekstra punktum). At tilføje en post som ser sådan her ud i <filename>/etc/hosts</filename> (dvs. <userinput>orion.</userinput> hvis værtsmaskinenavnet er <systemitem class="systemname">orion</systemitem>) gør at man undgår problemet. </para>
<para>Hvis du har &kde;'s kildekode, gå til <filename class="directory">tdelibs/arts/examples</filename>, og kør <userinput><command>make</command> <option>check</option></userinput> for at kompilere nogle programmer, inklusive <application>referenceinfo</application>. Kør derefter </para>
<para>Udskriften angiver værtsmaskinenavnet og porten som bruges af &arts;. For eksempel, <computeroutput>tcp:orion:1698</computeroutput> ville betyde at alle klienter som forsøger at bruge netværkstransparens skal vide hvordan værtsmaskinen <systemitem class="systemname">orion</systemitem> kan nås. </para>
<para>Det virker som om der er nogle få Linux-drivere som ikke virker godt sammen med aRts for visse udgaver af kernen. Læs først denne liste inden du rapporterer en fejl. Hvis du finder at informationen i listen ikke er fuldstændig, så tøv venligst ikke med at fortælle os om det. <informaltable> <tgroup cols="4">
<para>De almindelige problemer er at driveren ikke giver aRts tilstrækkelig eller tilstrækkeligt nøjagtig information om hvornår lyddata skal skrives. De fleste OSS-drivere giver rigtig information, men ikke alle. </para>
<para>Du vil måske bemærke at visse andre programmer (såsom xmms) ikke behøver denne information, og derfor virker rigtigt til og med for din hardware. Men &arts; behøver denne information, så artsd vil måske ikke virke. Dette er stadigvæk en fejl i driveren, og ikke i &arts;. </para>
<para>Der er to slags opførsel som artsd påviser når den køres med en fejlagtig driver. Enten forsøger den at sende ny data, men det lykkes egentlig aldrig, hvilket til slut fører til en for stor CPU-belastning, dette rapporteres, og at den afsluttes. Det andet problem er at artsd kan få forkert information om hvor meget data der skal skrives. Så <emphasis>stopper</emphasis> artsd med et fejlmeddelelse som: <screen>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
<para>Oftest bruger artsd kaldet select() for at holde styr på hvornår ny data skal skrives. Derefter bruger den kaldet ioctl(...GETOSPACE...), for at holde styr hvor meget data som skal skrives. Til sidst skriver den data. </para>
<para>Et problem opstår hvis artsd enten altid vækkes, eller hvis der er meget lidt data at skrive. OSS-dokumentationen angiver at kaldet select() kun vækker en proces hvis der er mindst et fragment at skrive. Hvis artsd vækkes når der ikke er nogen, eller meget lidt, data at skrive, for eksempel en sampling, forsøger den at skrive små stumper med lyddata, hvilket kan blive meget kostbart, og til slut give for stor CPU-belastning. </para>
<para>For at rette dette, skal driveren kun vække artsd hvis et helt fragment kan skrives. </para>
<para>Oftest bruger artsd kaldet select() for at holde styr på hvornår ny data skal skrives. Derefter bruger den kaldet ioctl(...GETOSPACE...), for at holde styr hvor meget data som skal skrives. Til sidst skriver den data. </para>
<para>Hvis artsd ikke kan skrive så meget data som angives af kaldet ioctl, så stopper den med fejlmeddelelsen ovenfor. For at rette dette, skal driveren angive den rigtige størrelse på det ledige plads. </para>
<para>Den mest sandsynlige grund er at du bruger gamle strukturer eller moduler som ikke understøttes i &kde; 2 versionen. Desværre er dokumentationen på nettet for &arts;-0.3.4.1 som er helt forældet. Det oftest rapporterede sammenbrud er at hvis en struktur køres i &arts-builder; så fås fejlmeddelelsen <errorname>[artsd] Synth_PLAY: lydsystemet bruges allerede.</errorname> </para>
<para>Du skal bruge et Synth_AMAN_PLAY modul i stedet for Synth_PLAY så forsvinder problemet. Se også &arts-builder;'s hjælpefil (tryk på <keycap>F1</keycap> i &arts-builder;). </para>
<para>Nyere udgaver af &arts-builder; (&kde; 2.1 beta 1 og senere) levereres med et antal eksempler som du kan bruge. </para>
