<para>&kde; utilise &arts; pour le son, et &arts; utilise les pilotes sonores du noyau de &Linux;, soit <acronym>OSS</acronym>, soit <acronym>ALSA</acronym> (en utilisant l'émulation <acronym>OSS</acronym>). Si votre carte son est reconnue par <acronym>ALSA</acronym> ou <acronym>OSS</acronym> et correctement configurée (&cad; que les autres applications &Linux; l'utilisent sans problème), ça marchera. Il y a cependant des problèmes avec certains matériels spécifiques, lisez la <link linkend="faq-hardware-specific"> section pour les problèmes spécifiques au matériel</link> si vous avez des problèmes avec artsd sur votre machine. </para>
<para>En attendant, la gestion pour d'autres plates-formes diverses a été ajoutée. Voici une liste complète de la façon dont les versions les plus récentes de &arts; peuvent lire le sons. Si vous avez une plate-forme non gérée, veuillez porter &arts; sur votre plate-forme. </para>
<entry>Gestion de OSS (Open Sound System). Fonctionne sous Linux, divers BSD et d'autres plates-formes sur lesquelles les pilotes OSS sont installés.</entry>
<para>Vérifiez que &artsd; est lié à <filename>libaudiofile</filename> (<userinput><command>ldd</command><parameter>artsd</parameter></userinput>). Si ce n'est pas le cas, téléchargez tdesupport, recompilez tout et ça devrait marcher. </para>
<para>Les permission du fichier <filename class="devicefile">/dev/dsp</filename> déterminent quels utilisateurs ont accès au son. Pour permettre à tout le monde de l'utiliser, faites ceci: </para>
<para>Vous pouvez obtenir le même effet dans un terminal en utilisant la commande <userinput><command>chmod</command> <option>666</option> <parameter>/dev/dsp</parameter></userinput>. </para>
<para>Pour restreindre l'accès au son à certains utilisateurs, vous pouvez utiliser les permissions de groupe. Avec certaines distributions &Linux;, par exemple Debian/Potato, <filename class="devicefile">/dev/dsp</filename> appartient déjà au groupe <systemitem class="groupname">audio</systemitem>, donc vous devez juste ajouter les utilisateurs à ce groupe. </para>
<para>Il y a d'autres périphériques qui fournissent des fonctionnalités auxquelles accèdent des applications multimédia. Vous pouvez les traiter de la même manière, soit en les rendant accessibles à tout le monde, soit en utilisant des groupes pour contrôler les accès. Voici une liste, qui est vraisemblablement incomplète (s'il y a plusieurs périphériques de la forme <filename class="devicefile">midi0</filename>, <filename class="devicefile">midi1</filename>, &etc; seule la version avec le zéro est listée ici): </para>
<para>Tout d'abord, essayez d'utiliser les réglages par défaut du ¢reConfiguration; (ou si vous démarrez manuellement, ne donnez pas d'options supplémentaires outre <userinput><option>-F</option><parameter>10</parameter> <option>-S</option><parameter>4096</parameter></userinput> pour les temps de réponse). Tout particulièrement, <emphasis>full duplex est susceptible de ne pas fonctionner</emphasis> avec divers pilotes, donc essayez de le désactiver. </para>
<para>Une bonne façon de vous rendre compte pourquoi &artsd; ne démarre pas (ou plante en cours de fonctionnement) est de démarrer manuellement. Ouvrez une fenêtre &konsole;, et saisissez: </para>
<para>En faisant ceci, vous obtiendrez sûrement des informations utiles. S'il plante en faisant ceci ou cela, vous pouvez refaire ceci et cela et voir <quote>comment</quote> il plante. Si vous voulez faire un rapport de bogue, générer un <quote>backtrace</quote> avec <command>gdb</command> et/ou un <command>strace</command> peut aider à régler le problème. </para>
<para>Vous ne pouvez pas modifier le dossier de &arts; de manière parfaite. Le problème est que la localisation de &artsd; est compilée dans &artswrapper; pour des raisons de sécurité. Vous pouvez cependant utiliser le fichier <filename>.mcoprc</filename> (entrées TraderPath/ExtensionPath) pour qu'un &artsd; déplacé puisse au moins trouver ses composants. Voyez le <link linkend="the-mcoprc-file">chapitre à propos du fichier <filename>.mcoprc</filename></link> pour plus de détails. </para>
<para>Réponse longue: dans les versions officielles, il y a deux bogues gcc-3.0 affectant &arts;. Le premier, gcc-3.0 bug c++/2733est relativement innofensif (et a à voir avec des problèmes avec les instructions asm). Il fait échouer la compilation de convert.cc. Il a été corrigé dans le CVS de gcc-3.0, et ne sera plus un problème avec gcc-3.0.1et supérieur. Une solution temporaire a également été ajoutée dans la version CVS de KDE/aRts. </para>
<para>Le second bogue, c++/3145 (qui provoque la génération de mauvais code dans le cas d'héritages virtuels multiples) est critique. Des applications comme &artsd; planteront simplement au démarrage lorsqu'elles sont compilées avec gcc-3.0. Même si des progrès ont été effectués dans la branche de gcc-3.0, au moment où ces lignes sont écrites, &artsd; plante toujours relativement souvent, de manière imprévisible. </para>
<listitem><para><application>xmms</application> (avec le module externe &arts;)</para></listitem>
<listitem><para>Real Networks <application>RealPlayer</application> 8.0 (fonctionne avec &artsdsp;; le support natif de &arts; est en cours d'étude)</para></listitem>
<para>Cette section est incomplète - si vous avez plus d'informations sur les applications reconnues ou non, prévenez l'auteur afin de les inclure ici. </para>
<para>Lorsque le serveur sonore de &arts; est utilisé par &kde;, il utilise le périphérique sonore. Si le serveur ne fait rien pendant 60 secondes, il est suspendu automatiquement et libère le périphérique. </para>
<para>Si vous démarrez artsd depuis le centre de configuration de KDE, la suspension automatique est réglée par défaut à 60 secondes. Si vous démarrez artsd depuis la ligne de commande, vous devrez utiliser l'option -s pour spécifier le temps de suspension automatique, sinon elle sera désactivée par défaut. </para>
<para>Actuellement, il n'est pas suspendu si le mode full duplex est activé. Désactivez-le depuis le ¢reConfiguration;. Il est conseillé généralement de désactiver le mode full duplex si vous utilisez &arts; pour lire de l'audio et pas pour enregistrer. </para>
<para>Ceci redirigera la sortie son vers &arts;. Cette méthode ne nécessite pas de modifications de l'application. Ce n'est pas très élégant, et ne gère pas toutes les caractéristiques de la carte son donc il est possible que ça ne fonctionne pas pour certaines applications. </para>
<para>Vous avez besoin d'une version récente des librairies glibc; &artsdsp; ne fonctionnera pas de manière sûre sur certaines vieilles distributions de &Linux;. Par exemple, avec une Debian 2.1 (basée sur glibc 2.0), ça ne fonctionnera pas, tandis que ça fonctionnera avec une Debian2.2 (basée sur glibc 2.1.3). </para>
<para>Non, utiliser &artsdsp; peut entraîner des temps de latence et une augmentation légère de l'utilisation du processeur par rapport à l'utilisation directe des <acronym>API</acronym> de &arts;. À part ça, si ça ne fonctionne pas pour une application, il faut considérer ça comme un bogue dans &artsdsp;. La technique utilisée par &artsdsp; devrait, si elle est implantée correctement, permettre à <emphasis>toute</emphasis> application de fonctionner avec (y compris les grosses applications comme <application>Quake</application> 3). </para>
<para>Vous pouvez attendre que &artsd; se suspende automatiquement, ou utiliser la commande <userinput><command>artsshell</command><option>suspend</option></userinput> pour demander au serveur de se suspendre. Vous ne pourrez le suspendre que si plus aucune application reconnaissant &arts;ne l'utilise, et ensuite plus aucune de ces applications ne pourra le réutiliser lorsqu'il sera suspendu. </para>
<para>Si le serveur est occupé, un moyen un peu rude, mais efficace de s'en débarrasser est: </para>
<para>Si vous exécutez des applications &kde; 1, qui envoient les signaux audio vers le serveur audio de &kde; 1, vous devrez exécuter <application>kaudioserver</application> pour les faire fonctionner. Vous pouvez démarrer <application>kaudioserver</application> de la même façon que les applications non-&arts;: </para>
<para>La méthode est similaire à celle pour <application>kaudioserver</application>. De telles applications nécessitent que le serveur esd fonctionne. Vous pouvez démarrer <command>esd</command> via &artsdsp;, et chaque application utilisant <acronym>ESD</acronym> devrait fonctionner correctement, comme ceci: </para>
<para>Les version de aRts plus récentes (>=1.2.0) peuvent également utiliser le démon sonore d'enlightment au lieu d'accéder directement à la carte son. Sur la ligne de commande, vous pouvez utiliser l'option -a, comme </para>
<para>pour activer la gestion de EsounD, tandis que dans KDE, vous pouvez utiliser le centre de configuration pour configurer artsd pour utiliser esd via Son -> Serveur sonore -> Entrées/sorties. </para>
<para>Ce n'est probablement pas un bogue, mais dû au fait que le noyau de &Linux; n'est pas adapté à l'ordonnancement temps-réel. Il y a des situations où &arts; ne pourra pas continuer à jouer. Vous pouvez cependant activer les droits temps-réel (via le ¢reConfiguration;), et utiliser un temps de réponse important (comme<guilabel>250ms</guilabel> ou <guilabel> le plus grand possible</guilabel>), ce qui devrait améliorer la situation. </para>
<para>Le texte d'aide pour ce réglage dans le ¢reConfiguration; peut être trompeur. Une valeur faible signifie que &arts; aura moins de temps pour répondre à un événement extérieur (&cad; le temps qui sépare le moment ou une fenêtre est fermée, et le moment ou un son est joué par &artsd;). Plus de ressources processeur seront aussi utilisées, ce qui peut entraîner des interruptions brèves du son.</para>
<para>Pour les utilisateurs de lecteurs <acronym>IDE</acronym>, vous pouvez utiliser la commande <command>hdparm</command> pour placer votre lecteur <acronym>IDE</acronym> en mode <acronym>DMA</acronym>. Attention, ça ne fonctionne pas avec tous les matériels, et peut vous obliger à redémarrer la machine, ou plus rare, peut entraîner des pertes de données. Lisez la documentation sur la commande <command>hdparm</command> pour de plus amples informations. J'ai utilisé avec succès la commande suivante: </para>
<para>Vous devez lancer ceci après chaque démarrage, donc placez-le dans un script de démarrage de votre système (la façon de procéder dépend de votre distribution, sur une Debian &Linux;, la commande est souvent ajoutée dans <filename>/etc/rc.boot</filename>). </para>
<para>Vérifiez que artswrapper est installé suid <systemitem class="username">root</systemitem>, comme il est supposé l'être. Beaucoup de distributions (SuSE7.x for instance) ne le font pas. Vous pouvez vérifier ceci en utilisant: ls -l $(which artswrapper). Bon: <screen>
</screen> Si vous n'avez pas le s, vous pouvez l'obtenir en utilisant: <screen><prompt>%</prompt> <userinput><command>chown</command> <option>root</option> <parameter>$(which artswrapper)</parameter></userinput>
<para>Si vous rendez artswrapper SUID <systemitem class="username">root</systemitem>, ceci améliorera sensiblement la qualité de la lecture audio en réduisant les coupures dans la musique. Cependant, ceci augmente également le risque qu'un bogue dans le code ou qu'un utilisateur malicieux ne fasse planter ou bloquer votre machine. De plus, sur des machines multiutilisateurs, donner la priorité à un son de haute qualité peut diminuer les performances pour les utilisateurs qui essaient d'utiliser la machine de manière <quote>productive</quote>.</para>
<para>Vérifiez le réglage du temps de réponse. Cependant, la version actuelle n'est pas encore vraiment optimisée. Ça devrait s'améliorer, mais jusque là, aucune estimation sur la vitesse de &artsd; ne peut vraiment être faite. </para>
<para>Activez-la à partir de <guilabel>Serveur de son</guilabel> dans le ¢reConfiguration;(<guilabel>Échanger les informations de sécurité et de référence sur le serveur X11</guilabel> et <guilabel>Activer la transparence réseau</guilabel>). Copiez ensuite votre fichier <filename>.mcoprc</filename> sur toutes les machines à partir desquelles vous voulez utiliser la transparence réseau. Connectez-vous à nouveau. Assurez-vous que les hôtes mis en jeu se connaissent bien entre eux (&cad; qu'ils ont des noms résolvables ou qu'ils sont dans <filename>/etc/hosts</filename>). </para>
<para>Ce devrait être tout ce que vous avez à faire. Cependant, si ça ne fonctionne toujours pas, il y a quelques détails supplémentaires. Le processus du serveur de son de &arts;, &artsd;, ne doit être exécuté que sur un hôte, celui contenant la carte son qui va être utilisée. Ce processus peut être démarré automatiquement à la connexion à &kde; (vous configurez ceci dans le ¢reConfiguration;), ou manuellement en utilisant quelque chose comme: </para>
<para>sur toutes les machines mises en jeu, afin de faire fonctionner la transparence réseau. C'est ce qui est activé par le réglage <guilabel>Échanger les informations de sécurité et de référence sur le serveur X11</guilabel> du centre de configuration de &kde;. </para>
<para>Enfin, dans toutes les versions de &kde; de la série 2.0.x, un bogue apparaît si vous n'avez pas de nom de domaine. Les clients de &artsd; essaient de trouver où se connecter via la combinaison <systemitem class="systemname"><replaceable>hostname</replaceable>.<replaceable>domainname</replaceable></systemitem> Si votre nom de domaine est vide, ils essaieront de se connecter à <systemitem class="systemname"><replaceable>hostname</replaceable></systemitem>. (notez le point supplémentaire). Il est possible de contourner ce problème en ajoutant une entrée à <filename>/etc/hosts</filename> (&cad; <userinput>orion.</userinput> si votre nom d'hôte est <systemitem class="systemname">orion</systemitem>). </para>
<para>Si vous avez le code source de &kde;, allez dans <filename class="directory">tdelibs/arts/examples</filename>, et exécutez <userinput><command>make</command> <option>check</option></userinput> pour compiler certains programmes, dont <application>referenceinfo</application>. Exécutez ensuite </para>
<para>La sortie indiquera le nom d'hôte et le port en cours d'utilisation par &arts;. Par exemple, <computeroutput>tcp:orion:1698</computeroutput> signifierait que tout client essayant d'utiliser la transparence réseau devrait savoir comment atteindre l'hôte <systemitem class="systemname">orion</systemitem>. </para>
<para>Il semble qu'il y a quelques pilotes linux qui ne fonctionnent pas très bien avec aRts avec certaines versions du noyau. Veuillez lire cette liste avant de signaler un bogue. Si vous trouvez des informations incomplètes dans cette liste, n'hésitez pas à nous le faire savoir. <informaltable> <tgroup cols="4">
<para>Le problème courant est que le pilote ne fournit pas à aRts suffisamment d'informations ou de manière trop peu précise sur le moment auquel écrire les données sonores. La plupart des pilotes OSS fournissent correctement ces informations, mais pas tous. </para>
<para>Vous avez peut-être remarqué que certaines autres applications (comme xmms) n'ont pas besoin de ces données, et ainsi fonctionnement correctement même avec votre matériel. Cependant, &arts; a besoin de ces données, donc artsd peut ne pas fonctionner. Ceci est un bogue dans le pilote, pas dans &arts;. </para>
<para>Il y a deux sortes de comportement possibles pour artsd lorsqu'il fonctionne avec un pilote incorrect. Soit il tente continuellement d'apporter de nouvelles données, mais n'y parvient jamais, ce qui peut amener éventuellement à une consommation excessive du processeur donnant une <emphasis>surcharge processeur</emphasis> et sort. L'autre problème est que &artsd; peut se voir fournir de mauvaises informations sur la quantité d'informations à écrire. Artsd <emphasis>s'arrêtera alors avec une assertion</emphasis> comme: <screen>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
<para>Habituellement, artsd utilise select() pour trouver quand écrire de nouvelles données. Ensuite, il utilise un ioctl(...GETOSPACE...) pour trouver la quantité d'informations à écrire. Enfin, il écrit ces données. </para>
<para>Un problème survient si artsd est réveillé soit en permanence, soit si il y a une quantité minimale de données à écrire. La documentation OSS spécifie que select() ne réveille un processus que s'il y a au moins un fragment à écrire, ou très peut, par exemple un échantillon, alorsalors il continuera à écrire de petits morceaux de données audio, ce qui peut devenir très coûteux, et éventuellement surcharger le processeur. </para>
<para>Pour corriger ceci, le pilote devrait réveiller artsd uniquement s'il y a un fragment entier à écrire. </para>
<para>Habituellement, artsd utilise select() pour trouver quand écrire de nouvelles données. Ensuite, il utilise un ioctl(...GETOSPACE...) pour trouver la quantité d'informations à écrire. Enfin, il écrit ces données. </para>
<para>Si artsd ne peut pas écrire autant de données que ce qui est spécifié par ioctl, il échouera dans son assertion. Pour corriger ceci, le pilote doit fournir la quantité correcte d'espace libre. </para>
<para>La cause la plus probable est que vous utilisez de vieilles structures ou de vieux modules qui ne sont pas reconnus pas la version pour &kde; 2. Malheureusement, la documentation disponible sur internet se réfère à &arts;-0.3.4.1 qui est une ancienne version. Le plantage le plus souvent rencontré est l'apparition du message d'erreur <errorname>[artsd] Synth_PLAY:audio subsystem is already used.</errorname> dans &arts-builder; lorsqu'une structure est exécutée. </para>
<para>Utilisez un module Synth_AMAN_PLAY plutôt qu'un module Synth_PLAY et le problème disparaîtra. Voyez aussi l'aide de &arts-builder; en appuyant sur <keycap>F1</keycap> depuis &arts-builder;). </para>
<para>Les versions récentes de &arts-builder; (&kde; 2.1 beta1 et suivantes) sont livrées avec plusieurs exemples. </para>