<para>&kde; utiliza &arts; para reproducir sonido, y &arts; utiliza los controladores de sonido del núcleo de &Linux;, ya sean <acronym>OSS</acronym> o <acronym>ALSA</acronym> (utilizando la emulación de <acronym>OSS</acronym>). Si su tarjeta de sonido está soportada por <acronym>ALSA</acronym> o por <acronym>OSS</acronym> y correctamente configurada (&ie;, cualquier otra apliación de Linux puede reproducir sonido), funcionará. Hay, sin embargo, algunos problemas con hardware específico, por favor, lea la <link linkend="faq-hardware-specific">sección sobre problemas con hardware específico</link> si tiene problemas con artsd en su ordenador. </para>
<para>Mientras tanto se ha añadido soporte para varias plataformas más. Ésta es una lista completa de cómo se puede reproducir sonido con la versión más reciente de &arts;. Si su plataforma no está soportada, por favor, considere realizar usted mismo las modificaciones oportunas para que funcione. </para>
<para>Compruebe que &artsd; está correctamente enlazado con <filename>libaudiofile</filename> (<userinput><command>ldd</command> <parameter>artsd</parameter></userinput>). Si no lo está, descargue el paquete tdesupport, recompílelo todo y funcionará. </para>
<para>Los permisos del archivo <filename class="devicefile">/dev/dsp</filename> afectan a que los usuarios tengan o no sonido. Para que funcione correctamente, haga esto: </para>
<para>Puede conseguir los mismos resultados desde una ventana de terminal con la orden <userinput><command>chmod</command> <option>666</option> <parameter>/dev/dsp</parameter></userinput>. </para>
<para>Para restringir el sonido a algunos usuarios específicos, puede utilizar los permisos de grupo. En algunas distribuciones de &Linux; como Debian/Potato, <filename class="devicefile">/dev/dsp</filename> ya aparece en propiedad de un grupo llamado <systemitem class="groupname">audio</systemitem>, así que lo único que tiene que hacer es añadir los usuarios a ese grupo. </para>
<para>Hay otros dispositivos que proporcionan la funcionalidad a la que acceden las aplicaciones multimedia. Puede tratarlos de la misma manera, bien haciéndolos accesibles para todo el mundo, o utilizando grupos para controlar el acceso. Esta es una lista, que puede estar incompleta (en caso de que haya varios dispositivos en la forma <filename class="devicefile">midi0</filename>, <filename class="devicefile">midi1</filename>, ..., aquí sólo se mostrará la versión 0): </para>
<para>En primer lugar: trate de utilizar los parámetros predeterminados en &kcontrol; (o si lo ha iniciado manualmente, no incluya argumentos adicionales salvo quizá <userinput><option>-F</option><parameter>10</parameter> <option>-S</option><parameter>4096</parameter></userinput> para latencia). En contreto es <emphasis>bastante probable que falle el full duplex</emphasis> (transmisión bidireccional) con varios controladores, así que pruebe a desactivarlo. </para>
<para>Una buena forma de investigar por qué no se inicia &artsd; (o se cuelga durante el funcionamiento) es cargarlo manualmente. Abra una ventana de &konsole; y teclee: </para>
<para>Al hacer esto, lo más probable es que obtenga suficiente información sobre los motivos de los fallos. O, si se cuelga al hacer una cosa concreta, puede hacerla en este momento para observar «cómo» falla. Si desea informar de un fallo, el generar un trazado inverso con <command>gdb</command> y/o <command>strace</command> puede ayudar a localizar el problema. </para>
<para>No se podrá mover &artsd; sin problemas directamente. El único inconveniente es que &artswrapper; guarda la localización de &artsd; compilada por motivos de seguridad. Usted puede, sin embargo, utilizar el archivo <filename>.mcoprc</filename> (entradas TraderPath/ExtensionPath) para indicar a &artsd; dónde puede localizar sus componentes. Vea el <link linkend="the-mcoprc-file">capítulo sobre el archivo <filename>.mcoprc</filename></link> para obtener más detalles sobre esto. </para>
<para>Respuesta más larga: en su publicación oficial, hay dos fallos en gcc-3.0 que afectan a &arts;. El primero, fallo gcc-3.0 c++/2733 es relativamente inofensivo (y está relacionado con problemas con las declaraciones del ensamblador). Impide la compilación de convert.cc. Ya ha sido corregido en el CVS de gcc-3.0, y no será un problema en gcc-3.0.1 y superiores. Además hay una solución en la versión CVS de KDE/aRts. </para>
<para>El segundo fallo de gcc-3.0, el c++/3145 (que trata sobre la generación de código erróneo en algunos casos de herencia virtual múltiple), es crítico. Las aplicaciones como &artsd; simplemente no funcionarán si están compiladas con gcc-3.0. Aunque se está haciendo algún progreso al respecto en la rama de gcc-3.0 en el momento de escribir esto, &artsd; sigue fallando habitualmente y de forma impredecible. </para>
<para>Algunas aplicaciones &kde; que aún no se incluyen en las publicaciones de &kde; (⪚, en kdenonbeta) también soportan &arts;, incluyendo: </para>
<listitem><para><application>xmms</application> (con el conector &arts;).</para></listitem>
<listitem><para>Real Networks <application>RealPlayer</application> 8.0 (funciona con &artsdsp;. Se está considerando el soporte nativo de &arts;).</para></listitem>
<para>Esta sección está incompleta, si tiene más información sobre aplicaciones soportadas o no soportadas, por favor, póngase en contacto con el autor para poder incluir aquí esos datos. </para>
<para>Ya que el servidor de sonido &arts;, utilizado por &kde;, está ocupando el dispositivo de sonido. Si el servidor está inactivo durante más de 60 segundos, se auto suspende y libera el dispositivo automáticamente. </para>
<para>Si inicia artsd desde el panel de control de KDE, el tiempo de suspensión predeterminado es de 60 segundos. Si inicia artsd desde la línea de órdenes necesitará utilizar la opción -s para especificar el tiempo para la suspensión. De otro modo, el comportamiento predeterminado es desactivar la característica de suspensión. </para>
<para>En este momento no hay suspensión si está en uso el full duplex. Apague el full duplex desde &kcontrol; para que funcione la suspensión. Desactivar el full duplex es una buena idea si &arts; se utiliza para la reproducción y no para la grabación de audio. </para>
<para>Esto reenviará la salida de sonido a &arts;. Este método no requiere realizar cambios en las aplicaciones. Es, sin embargo, una solución un poco engorrosa y que, además, no admite todas las características de las tarjetas de sonido, así que algunas aplicaciones podrían no funcionar. </para>
<para>Necesita una versión reciente de la biblioteca glibc. &artsdsp; no funcionará de forma fiable en distribuciones antiguas de &Linux;. Por ejemplo, en Debian 2.1 (basada en glibc 2.0) no funciona, mientras que en Debian 2.2 (basada en glibc 2.1.3), lo hace correctamente. </para>
<para>No. El uso de &artsdsp; puede resultar más lento y cargar más procesador que utilizar las <acronym>API</acronym>s de &arts; directamente. A parte de eso, cualquier aplicación que no funcione se deberá considerar como un fallo en &artsdsp;. La técnica utilizada por &artsdsp; debería, si está implementada correctamente, permitir que <emphasis>cualquier</emphasis> aplicación funcione (incluyendo aplicaciones grandes como <application>Quake</application> 3). </para>
<para>Puede esperar a que &artsd; entre en suspensión o utilizar la orden <userinput><command>artsshell</command> <option>suspend</option></userinput> para hacer que el servidor entre forzosamente en suspensión. Sólo podrá suspender el servidor si no hay ninguna aplicación utilizando &arts; en ese momento, y no se permitirá el funcionamiento de ninguna aplicación que utilice &arts; durante el tiempo que dure la suspensión. </para>
<para>Si el servidor está ocupado, este es un método un poco bruto, pero efectivo, de solucionarlo: </para>
<para>Si está ejecutando aplicaciones de &kde; 1.x, cuya salida de sonido es a través del servidor de audio de &kde; 1, deberá ejecutar <application>kaudioserver</application> para que funcionen. Puede iniciar <application>kaudioserver</application> de la misma forma que otras aplicaciones que no son de &arts;: </para>
<para>Deberá tener instalado kaudioserver (del mismo sitio del que haya obtenido las aplicaciones de &kde; 1.x), pertenece a &kde; 1.x y no a &kde; 2. </para>
<para>El problema es similar al de <application>kaudioserver</application>. Esas aplicaciones necesitan un servidor esd funcionando. Puede iniciar <command>esd</command> a través de &artsdsp;, y todas las aplicaciones <acronym>ESD</acronym> funcionarán correctamente, de esta manera: </para>
<para>Las nuevas versiones de aRts (>= 1.2.0) también pueden utilizar el demonio de sonido mejorado en lugar de acceder directamente a la tarjeta de sonido. En la línea de órdenes, puede utilizar la opción -a, de la siguiente forma: </para>
<para>para conseguir soporte de EsounD, en KDE podrá utilizar kcontrol para configurar artsd y utilizar esd a través de Sonidos y multimedia -> Sistema de sonido -> E/S sonido. </para>
<para>Lo más probable es que no, sino que esté causado por el hecho de que el núcleo de &Linux; no se lleva muy bien con el procesamiento a tiempo real. Hay situaciones en las que &arts; no es capaz de mantener el flujo de reproducción. Usted puede, sin embargo, activar derechos de tiempo real (a través de &kcontrol;), y utilizar un tiempo de latencia grande (como <guilabel>250ms</guilabel> o <guilabel>tan grande como sea posible</guilabel>), lo que debería mejorar la situación. </para>
<para>El texto de ayuda de este parámetro en &kcontrol; puede despistas. Un valor más bajo significa que &arts; tardará menos tiempo en responder a los eventos externos (&ie;, el tiempo que pasa desde que se selecciona una ventana hasta que se oye un sonido reproducido por &artsd;). Además utiliza más recursos de <acronym>CPU</acronym>, y lo más probable es que produzca más ruidos.</para>
<para>Los usuarios de los discos duros <acronym>IDE</acronym> puede utilizar la orden <command>hdparm</command> para poner sus discos en modo <acronym>DMA</acronym>. Una advertencia: esto no funciona con todo el hardware, y puede dar como resultado el tener que reiniciar el sistema o, en algún caso poco habitual, en pérdida de datos. Lea la documentación sobre la orden <command>hdparm</command> para obtener más detalles. Yo lo he utilizado con éxito: </para>
<para>Debe hacer esto después de cada inicio del sistema, así que lo mejor es que lo incluya en algún script al inicio del sistema (esto depende de las distribuciones, en Debian &Linux; lo normal es añadirlo a <filename>/etc/rc.boot</filename>). </para>
<para>Verifique que artswrapper está instalado con permisos suid de <systemitem class="username">root</systemitem>, como se supone que debería estarlo. Muchas distribuciones (SuSE7.x, por ejemplo) no hacen esto. Puede verificarlo utilizando: ls -l $(which artswrapper). Correcto: <screen>
</screen> Si no tiene la s, puede ponerla utilizando: <screen><prompt>%</prompt> <userinput><command>chown</command> <option>root</option> <parameter>$(which artswrapper)</parameter></userinput>
<para>Si hace &artswrapper; SUID <systemitem class="username">root</systemitem>, probablemente mejorará la calidad de su sistema de audio reduciendo las distorsión en la música. Sin embargo, se incrementará el riesgo de que un fallo en el código o un usuario malicioso pueda colgar o dañar su máquina. Adicionalmente, en las máquinas multi-usuario, priorizar la alta calidad de audio puede deteriorar el rendimiento para los usuarios que intenten hacer un uso «productivo» de la máquina.</para>
<para>Compruebe sus parámetros de tiempo de respuesta. Sin embargo, la versión actual no está muy optimizada. Esto mejorará, y hasta ese momento no se puede hacer una predicción real de lo rápido o lento que puede ser &artsd;. </para>
<para>Actívela en los parámetros del <guilabel>Servidor de sonido</guilabel> de &kcontrol; (<guilabel>activar el servidor X11 para información de seguridad</guilabel> y <guilabel>transparencia de red</guilabel>). Después copie su archivo <filename>.mcoprc</filename> a todas las máquinas en las que piense utilizar la transparencia de red. Vuelva a acceder al sistema. Asegúrese de que los ordenadores que está interaccionando conocen los nombres de los otros (&ie;, los nombres que resolverá o que se encuentren en el archivo <filename>/etc/hosts</filename>). </para>
<para>Esto debería ser todo. Sin embargo, si aún no funciona, aquí tiene algún detalle adicional. El proceso del servidor de sonido &arts;, &artsd;, sólo debe ejecutarse en uno de los sistemas, el que tenga la tarjeta de sonido que reproducirá el audio. Se puede iniciar automáticamente al acceder a &kde; (si está configurado en &kcontrol;), o de forma manual utilizando algo como: </para>
<para>en todas las máquinas involucradas, para hacer que funcione la transparencia de red. Esto es lo que se activa con el parámetro del panel de control <guilabel>del servidor X11 para información de seguridad</guilabel>. </para>
<para>Por último, en todas la versiones de &kde; de la serie 2.0.x, hay un error que influye si no está configurado el nombre del dominio. Los clientes de &artsd; tratan de buscar dónde conectarse a través de la combinación <systemitem class="systemname"><replaceable>nombresistema</replaceable>.<replaceable>nombredominio</replaceable></systemitem>. Si el nombre del dominio está vacío, tratará de conectarse a <systemitem class="systemname"><replaceable>nombresistema</replaceable></systemitem>. (tenga en cuenta el punto adicional). Si se añade una entrada como ésta al archivo <filename>/etc/hosts</filename> (&ie;, <userinput>orion.</userinput> si el nombre de su sistema es <systemitem class="systemname">orion</systemitem>), soluciona el problema. </para>
<para>Asumiendo que usted tiene acceso al código fuente de &kde;, vaya a <filename class="directory">tdelibs/arts/examples</filename>, y ejecute <userinput><command>make</command> <option>check</option></userinput> para compilar algunos programas, incluyendo <application>referenceinfo</application>. A continuación ejecute </para>
<para>La salida indicará el nombre del sistema y el puerto que están siendo utilizados por &arts;. Por ejemplo, <computeroutput>tcp:orion:1698</computeroutput> significa que cualquier cliente que intente utilizar la transparencia de red debería ser capaz de acceder al sistema <systemitem class="systemname">orion</systemitem>. </para>
<para>Parece ser que existen unos pocos controladores linux que no funcionan bien con aRts en algunas versiones del núcleo. Por favor, lea esta lista antes de informar de un fallo. Si encuentra que parte de la información de esta lista esta incompleta, por favor, no dude en comunicarlo. <informaltable> <tgroup cols="4">
<para>La causa más común es que el controlador no proporciona a aRts la suficiente información sobre cuándo se debe escribir información de sonido. La mayoría de los controladores OSS proporcionan la información correcta, pero no todos. </para>
<para>Puede que advierta que hay otras aplicaciones (como xmms) que no necesitan esta información, y que, sin embargo, funcionan correctamente incluso con su hardware. A pesar de todo, &arts; necesita esa información, o artsd no funcionará correctamente. Esto es un fallo del controlador, y no de &arts;. </para>
<para>Hay dos tipos de comportamientos que artsd muestra cuando se está ejecutando un controlador incorrecto. O bien trata de forma contínua de enviar nueva información, pero nunca lo consigue, lo que produce un consumo de toda la potencia de la CPU, informa de <emphasis>sobrecarga en la cpu</emphasis> y sale. El otro problema es que a artsd se le puede comunicar información incorrecta sobre la cantidad de datos a escribir. En este caso artsd <emphasis>se detendrá mostrando una advertencia</emphasis> de este aspecto: <screen>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
<para>Normalmente, artsd utiliza select() para descubrir cuándo se deben escribir nuevos datos. Entonces, utiliza la función ioctl(...GETOSPACE) para descubrir cuánta información debe escribir. Por último, escribe esa información. </para>
<para>Los problemas ocurren cuando se llama a artsd contínuamente o si hay para escribir cantidades de información mínimas. La documentación de OSS especifica que select() únicamente llama a un proceso si hay al menos un fragmento para escribir. Sin embargo, si se llama a artsd sin datos para escribir, o muy pocos, por ejemplo, una sola muestra, este se mantendrá escribiendo pequeños segmentos de datos de audio, lo que resulta muy costoso y puede, en determinados casos, sobrecargar la cpu. </para>
<para>Para solucionar esto, el controlador debe llamar a artsd únicamente si hay para escribir un fragmento completo. </para>
<para>Normalmente, artsd utiliza select() para descubrir cuándo se deben escribir nuevos datos. Entonces, utiliza la función ioctl(...GETOSPACE) para descubrir cuánta información debe escribir. Por último, escribe esa información. </para>
<para>Si artsd no puede escribir toda la información que indica la llamada a ioctl, producirá una advertencia. Para solucionarlo, el controlador debe proporcionar la información correcta sobre la cantidad de espacio libre. </para>
<para>La causa más probable es que está utilizando estructuras antiguas o módulos que no están soportados en la versión 2 de &kde;. Por desgracia, la documentación que se encuentra en la web hace referencia a &arts;-0.3.4.1, que ya está obsoleto. El error del que más se informa es: que ejecutar una estructura en &arts-builder; da como resultado el mensaje de error <errorname>[artsd] Synth_PLAY: el subsistema de audio ya está en uso.</errorname> </para>
<para>Utilizando el módulo Synth_AMAN_PLAY en lugar de Synth_PLAY, el problema desaparecerá. Consulte también el archivo de ayuda de &arts-builder; (pulse <keycap>F1</keycap> en &arts-builder;). </para>
<para>Las versiones más recientes de &arts-builder; (&kde; 2.1 beta 1 y posteriores) vienen con un conjunto de ejemplos que pueden ser utilizados. </para>
