Det här avsnittet besvarar några frågor som ofta ställs om &arts;. Stöder &kde; mitt ljudkort för ljuduppspelning? &kde; använder &arts; för att spela upp ljud, och &arts; använder ljuddrivrutinerna i &Linux; kärna, antingen OSS eller ALSA (med emulering av OSS). Om ditt ljudkort antingen stöds av ALSA eller OSS 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 avsnittet om hårdvaruspecifika problem om du får problem med artsd på din dator. 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. &arts; metod för ljud-I/O Kommentar paud Stöd för AIX personliga ljudenhet (Personal Audio Device) alsa Linux ALSA-0.5 och ALSA-0.9 drivrutiner libaudioio Stöd för det generella LibAudioIO-biblioteket som fungerar på Solaris nas NAS ljudserver, användbar för X-terminaler med NAS-stöd null Ljudenheten null, kastar bort ljudet utan att något hörs oss OSS (Open Sound System) stöd (fungerar på Linux, olika BSD-versioner och andra plattformar med OSS-drivrutiner installerade) toss Trådat OSS-stöd, som fungerar bättre i vissa fall då det vanliga OSS-stödet inte fungerar bra sgi Stöd för SGI Direct Media för IRIX sun Solaris-stöd Jag kan inte spela wav-filer med &artsd;! Kontrollera att &artsd; är länkad till libaudiofile (ldd artsd). Om den inte är det, ladda ner tdesupport, kompilera om allt, och det kommer att fungera. Jag hör ljud när jag är inloggad som root, men andra användare saknar ljud! Rättigheterna för filen /dev/dsp påverkar vilka användare som har ljud. För att låta alla använda den, gör så här: Logga in som root. Öppna ett &konqueror;-fönster. Gå till katalogen /dev. Klicka på filen dsp med höger musknapp, och välj egenskaper. Klicka på fliken Skydd. Markera rutorna Visa poster och Skriv poster i alla avdelningar. Klicka på Ok. Du kan uppnå samma effekt i ett terminalfönster med kommandot chmod 666 /dev/dsp. 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 /dev/dsp redan av en grupp som heter audio, så allt du behöver göra är att lägga till användarna till den här gruppen. Det här hjälper för &artsd;, men vad gäller för &kmix;, &tdemid;, &kscd; etc.? 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 midi0, midi1..., så finns bara 0-versionen med): /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 Vad kan jag göra om artsd inte startar eller kraschar när den kör? 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 -F10 -S4096 för latenstid). Särskilt full duplex fungerar troligen inte med diverse drivrutiner, så försök stänga av det. 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: % artsd -F10 -S4096 > Du kan också lägga till väljaren -l0, som skriver ut mer information om vad som händer, så här: % artsd -l0 -F10 -S4096 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 hur den kraschar. Om du vill rapportera ett fel, kan en bakåtspårning skapad med gdb och/eller en strace hjälpa till att hitta problemet. Kan jag flytta på &artsd; (flytta kompilerade filer till en annan katalog)? 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 .mcoprc-filen (TraderPath/ExtensionPath posterna) för att åtminstone få en flyttad &artsd; att hitta sina komponenter. Se kapitlet om .mcoprc-filen för detaljer om hur man gör detta. Kan jag kompilera &arts; med gcc-3.0? Ett kort svar: nej, &arts; fungerar inte om du kompilerar det med gcc-3.0. 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. 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. Vilka program kör med &arts;? Självklart så fungerar alla program som ingår i &kde; med &arts;. Detta innefattar: &noatun; aRts-byggare &aktion; &tdemid; &tdemidi; &kmix; &kscd; &kde;-spel som &kpoker; och &ktuberling; Vissa &kde;-program som ännu inte ingår i &kde;-utgåvor (t.ex. i kdenonbeta) stöder också &arts;, inklusive: &brahms; Kaboodle Kdao Följande program som inte hör till -&kde; är kända för att fungera med &arts;: xmms (med &arts;-insticksprogram) Real Networks RealPlayer 8.0 (fungerar med &artsdsp;; inbyggt &arts;-stöd undersöks) Följande program är kända för att inte fungera med &arts;: inga Se också svaren till frågorna i avsnittet om program som inte stöder &arts;. 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. Så fort &kde; kör, så kan inga andra program komma åt mitt ljudkort! 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. Du sa att den går till vänteläge efter 60 sekunder, det gör den inte för mig! 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. 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. Hur kan jag köra gamla program som inte stöder &arts;? Kör dem med &artsdsp;. Om du till exempel normalt skulle köra: % mpg123 foo.mp3 använd istället: % artsdsp mpg123 foo.mp3 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. Jag kan inte köra &artsdsp; med något program. Den kraschar alltid! 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. Finns det teoretiska begränsningar med vissa program som förhindrar att de någonsin fungerar med &artsdsp;? Nej. Att använda &artsdsp; kan resultera i något högre latenstider och CPU-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 varje program att fungera med den (inklusive stora program som Quake 3). Vad kan jag göra om ett program inte fungerar med &artsdsp;? Du kan vänta på att &artsd; går till vänteläge eller använda kommandot artsshell suspend 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. Om servern är upptagen ser ett grovt men effektivt sätt att bli av med den ut så här: % killall artsd ; killall artswrapper Starta nu ditt eget program. % kcminit arts Alla &arts;-program som för närvarande kör kan krascha, när du väl avslutar servern. Vad gäller för program skrivna för &kde; 1.x? Om du kör &kde; 1.x program, som spelar upp ljud via ljudservern i &kde; 1, måste du köra kaudioserver för att det ska fungera. Du kan starta kaudioserver på samma sätt som andra program som inte stöder &arts;: % artsdsp kaudioserver Du måste ha installerat kaudioserver (från samma källa där du skaffade &kde; 1.x programmen). Den hör till &kde; 1.x, inte &kde; 2. Vad gäller för program som använder Enlightened Sound Daemon, ESD? Det här problemet liknar fallet med kaudioserver. Sådana program kräver en esd-server som kör. Du kan starta esd via &artsdsp;, och alla program som stöder ESD ska fungera bra, så här: % artsdsp esd 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 % artsd -a esd 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. Ibland hör jag korta pauser när jag lyssnar på musik. Är detta ett fel? 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 250 ms eller så stor som möjligt), vilket bör förbättra situationen. Vad är effekten av svarstidsinställningen? 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 CPU-resurser och vara mer benäget att orsaka pauser i ljudet. Finns det någonting annat jag kan göra för att undvika pauser? För användare av IDE-enheter, kan man använda kommandot hdparm för att ställa in din IDE-enhet att använda DMA-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 hdparm för mer detaljer. Jag har använt följande kommando med lyckat resultat: % hdparm -c1 -d1 -k1 -K1 /dev/hda 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 /etc/rc.boot). Realtidsprioritet verkar inte få någon effekt för mig? Kontrollera att artswrapper verkligen är installerad suid root, 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: % ls -l $(which artswrapper) -rwsr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper Dåligt: % ls -l $(which artswrapper) -rwxr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper Om du inte har med s:et, kan du få det med: % chown root $(which artswrapper) % chmod 4755 $(which artswrapper) Om du gör &artswrapper; SUID root, 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 produktivt sätt. Varför tar &artsd; så mycket CPU-tid? 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. Vad måste jag göra för att få nätverkstransparens? Aktivera det i inställningscentralens inställningar för Ljudserver (Utbyt säkerhets- och referensinformation över X11-servern och Aktivera nätverkstransparens). Kopiera sedan din .mcoprc-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 /etc/hosts). 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: % artsd -n -F 5 -S 8192 Väljaren -n anger nätverkstransparens, medan de övriga anpassar latenstider. Din .mcoprc-fil måste innehålla den här raden: GlobalComm=Arts::X11GlobalComm för alla maskiner som är inblandade, för att nätverkstransparens ska fungera. Det är det här som aktiveras av inställningen Utbyt säkerhets- och referensinformation över X11-servern i inställningscentralen. 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 värddatornamn.domännamn. Om domännamnet är tomt, försöker de ansluta till värddatornamn. (observera den extra punkten). Att lägga till en post som ser ut så här i /etc/hosts (dvs orion. om värddatornamnet är orion) gör att man undviker problemet. Hur avlusar jag nätverkstransparens om det inte fungerar? Om du har &kde;:s källkod, gå till tdelibs/arts/examples, och kör make check för att kompilera några program, inklusive referenceinfo. Kör sedan % ./referenceinfo global:Arts_SimpleSoundServer Utmatningen anger värddatornamnet och porten som används av &arts;. Till exempel, tcp:orion:1698 skulle betyda att alla klienter som försöker använda nätverkstransparens måste veta hur värddatorn orion kan nås. Vilken hårdvara fungerar artsd inte bra tillsammans med? 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. Linux-drivrutin/ljudkort Fungerar inte med Fungerar med Anmärkning i810-drivrutin (Intel 810 + AC97 Audio) 2.4.9 2.4.18, 2.2.20, kommersiell OSS-drivrutin, alsa-0.5.12a med OSS-emulering drivrutinen orsakar för mycket CPU-last (se nedan) maestro 3/4-kretsar 2.4.9 ? drivrutinen orsakar ibland överlast av processorn (se nedan) aureal8820, aureal8830-drivrutiner från sourceforge 2.4.17 ? drivrutinen orsakar felmeddelande / för mycket CPU-last (se nedan) OSS kommersiell 3.9.4g med Aureal Vortex ? ? systemet låser sig ymfpci 2.4.0, 2.4.12 2.4.17 drivrutinen orsakar felmeddelande (se nedan) Varför finns det hårdvaruspecifika problem, och hur ser jag dem? 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. 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;. 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å stoppar artsd med ett felmeddelande som: artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): Assertion `len == can_write' failed. Aborted Vad är fel i drivrutinen om jag får problemet med för mycket CPU-last? 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. 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. För att rätta detta, ska drivrutinen bara väcka artsd om ett helt fragment kan skrivas. Vad är det för fel i drivrutinen om jag får det här felmeddelandet? 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. 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. Jag kan inte använda aRts-byggaren. Den kraschar när jag kör en modul! 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 [artsd] Synth_PLAY: ljuddelsystemet används redan. 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å F1 i aRts-byggaren). Senare versioner av aRts-byggaren (&kde; 2.1 beta 1 och senare) levereras med ett antal exempel som du kan använda.