<para>O &kde; usa o &arts; para tocar sons, e o &arts; usa os drivers de som do kernel do &Linux;, tanto os <acronym>OSS</acronym> como os <acronym>ALSA</acronym> (usando emulação <acronym>OSS</acronym>). Se sua placa de som é suportada seja pelo <acronym>ALSA</acronym> ou pelo <acronym>OSS</acronym> e estiver corretamente configurada (&ie; qualquer outro aplicativo &Linux; pode gerar som), ele funcionará. Existem no entanto alguns problemas com alguns hardwares específicos, por favor leia a <link linkend="faq-hardware-specific">seção para problemas com hardwares específicos</link> se você tiver problemas com o artsd em sua máquina. </para>
<para>Entretanto, suporte para diversas outras plataformas também tem sido adicionado. Aqui está uma lista completa de como a versão mais recente do &arts; pode tocar som. Se você tiver uma plataforma não suportada, por favor considere portar o &arts; para sua plataforma. </para>
<para>Verifique se o &artsd; está linkado ao <filename>libaudiofile</filename> (<userinput><command>ldd</command> <parameter>artsd</parameter></userinput>). Caso contrário, baixe o tdesupport, recompile tudo, e então funcionará. </para>
<para>As permissões do arquivo <filename class="devicefile">/dev/dsp</filename> afetam quais usuários terão som. Para permitir que todos o usem, faça isto: </para>
<para>Você pode obter o mesmo efeito na janela do terminal usando o comando <userinput><command>chmod</command> <option>666</option> <parameter>/dev/dsp</parameter></userinput>. </para>
<para>Para restringir o acesso ao som para usuários específicos, você pode usar as permissões de grupo. Em algumas distribuições &Linux;, por exemplo o Debian/Potato, o <filename class="devicefile">/dev/dsp</filename> já está como pertencente ao grupo chamado <systemitem class="groupname">audio</systemitem>, de modo que tudo o que precisa fazer é adicionar os usuários a este grupo. </para>
<para>Existem vários outros dispositivos que fornecem funcionalidades acessadas por aplicativos multimídia. Você pode tratá-los da mesma maneira, seja tornando-os acessíveis para todos, ou usando grupos para controlar o acesso. Aqui está uma lista, que pode ainda estar incompleta (se existirem também diversos dispositivos em uma forma tipo <filename class="devicefile">midi0</filename>, <filename class="devicefile">midi1</filename>, ..., então somente a versão 0 é listada aqui): </para>
<para>Primeiro de tudo: tente usar as configurações padrão no &kcontrol; (ou se você está iniciando manualmente, não forneça opções adicionais além talvez de <userinput><option>-F</option><parameter>10</parameter> <option>-S</option><parameter>4096</parameter></userinput> para latência). Especialmente <emphasis>o full duplex é conhecido por não funcionar</emphasis> com diversos drivers, logo tente desabilitá-lo. </para>
<para>Uma boa maneira de descobrir porque o &artsd; não inicia (ou trava ao rodar) é iniciá-lo manualmente. Abra uma janela do &konsole;, e faça o seguinte: </para>
<para>Fazendo isso, você provavelmente obterá algumas informações úteis sobre porque ele não inicia. Ou, se ele trava ao fazer isto ou aquilo, você pode fazer isto ou aquilo, e ver <quote>como</quote> ele trava. Se você desejar relatar um erro, produzir um rastro de execução com o <command>gdb</command> e/ou um <command>strace</command> pode ajudar a encontrar o problema. </para>
<para>Você não pode mudar a localização do &arts;. O problema é que o &artswrapper; possui a localização do &artsd; compilado devido a razões de segurança. Você pode no entanto usar o arquivo <filename>.mcoprc</filename> (entradas TraderPath/ExtensionPath) para pelo menos fazer com que o &artsd; encontre seus componentes. Veja o <link linkend="the-mcoprc-file">capítulo sobre o arquivo <filename>.mcoprc</filename></link> para detalhes sobre como fazer isto. </para>
<para>Resposta longa: Na versão oficial, existem dois erros do gcc-3.0 que afetam o &arts;. O primeiro, o erro c++/2733 do gcc-3.0 é relativamente inofensivo (e tem apresentado problemas com a sentença asm). Ele quebra a compilação do convert.cc. Isto foi concertado no gcc-3.0 do CVS, e não será mais um problema com o gcc-3.0.1 e superior. Um trabalho a respeito também foi adicionado à versão CVS do KDE/aRts. </para>
<para>O segundo erro do gcc-3.0, o c++/3145 (que é geração de código errado para alguns casos de herança virtual múltipla) é crítico. Aplicativos como o &artsd; simplesmente travarão na inicialização quando compilados com o gcc-3.0. Apesar de algum progresso ter sido feito no ramdo gcc-3.0 do CVS quando escrevia este documento, o &artsd; ainda trava muito frequentemente, imprevisivelmente. </para>
<listitem><para><application>xmms</application> (com o plug-in do &arts;)</para></listitem>
<listitem><para>Real Networks <application>RealPlayer</application> 8.0 (funciona com o &artsdsp;; suporte nativo ao &arts; está sendo considerado)</para></listitem>
<para>Esta seção está incompleta -- Se você tiver informações sobre aplicativos que suportam ou não suportam, por favor envie-as ao autor de modo que ele possa incluí-las aqui. </para>
<para>Uma vez que o servidor de som &arts; usado pelo &kde; está rodando, ele está usando o dispositivo de som. Se o servidor ficar ocioso por 60 segundos, ele auto-suspendará e liberará o dispositivo automaticamente. </para>
<para>Se você iniciar o artsd a partir do painel de controle do KDE, o padrão é para suspender após 60 segundos. Se você iniciar o artsd a partir da linha de comando, você precisa usar a opção -s para especificar o tempo para auto-suspensão, caso contrário, seu padrão é desabilitar o recurso de auto-suspensão. </para>
<para>Atualmente ele não suspende quando usa o full duplex. Desligue o full duplex a partir do &kcontrol; e ele suspenderá. Desabilitar o full duplex é geralmente uma boa idéia de qualquer jeito se você usa somente o &arts; para tocar áudio e não para gravar. </para>
<para>Isto redirecionará a saída de som para o &arts;. Este método não necessita de mudanças nos aplicativos. Se alguma coisa der errado no entanto, saiba que nem todos os recursos da placa de som são suportados, assim alguns aplicativos podem não funcionar. </para>
<para>Você precisa de uma versão recente da biblioteca glibc; o &artsdsp; não funcionará de maneira confiável em algumas distribuições antigas do &Linux;. Por exemplo, no Debian 2.1 (que é baseado no glibc 2.0) ele não funciona, enquanto no Debian 2.2 (que é baseado no glibc 2.1.3) ele funciona. </para>
<para>Não. Usar o &artsdsp; pode causar um pouco mais de latência e uso da <acronym>CPU</acronym> que usando a <acronym>API</acronym> do &arts; diretamente. Por outro lado, qualquer aplicativo que não funcione deve ser considerado um erro do &artsdsp;. A técnica usada pelo &artsdsp; deve, se implementada corretamente, permitir <emphasis>qualquer</emphasis> aplicativo funcionar com ele (incluindo aplicativos complexos como o <application>Quake</application> 3). </para>
<para>Você pode esperar que o &artsd; suspenda ou usar o comando <userinput><command>artsshell</command> <option>suspend</option></userinput> para pedir ao servidor que ele se suspenda. Você somente será capaz de suspender o servidor se nenhum aplicativo &arts; estiver atualmente o usando, e nenhum aplicativo &arts; será capaz de rodar quando o servidor estiver suspenso. </para>
<para>Se o servidor estiver ocupado, uma maneira bruta mas efetica de obter o rid dele é: </para>
<para>Se você estiver rodando aplicativos do &kde; 1.x, que produzem som através do servidor de áudio do &kde; 1, você precisará rodar o <application>kaudioserver</application> para fazê-los funcionar. Você pode iniciar o <application>kaudioserver</application> da mesma maneira que outros aplicativos não-&arts;: </para>
<para>Você precisará ter instalado o kaudioserver (a partir do código de onde você obteve seus aplicativos do &kde; 1.x) - ele fica no &kde; 1.x, não no &kde; 2. </para>
<para>A observação é semelhante a feita com o <application>kaudioserver</application>. Como os aplicativos precisarão de um servidor esd rodando, você pode iniciar o <command>esd</command> através do &artsdsp;, e cada aplicativo compatível com o <acronym>ESD</acronym> deve funcinar bem, como isto: </para>
<para>Versões mais novas do aRts (>= 1.2.0) também pode usar o daemon de som enlightened ao invés de acessar diretamente a placa de som. Na linha de comando, você pode usar a opção -a, como </para>
<para>para ter suporte ao EsounD, e no KDE, você pode usar o kcontrol para fazer com que o artsd use o esd através de Som -> Servidor de Som -> E/S de Som. </para>
<para>Isto não é propriamente um erro, mas causado pelo fato do kernel do &Linux; não ser muito bom no agendamento em tempo real. Existem situações onde o &arts; não será capaz de manter uma execução constante. Você pode, no entanto, habilitar permissões de tempo real (através do &kcontrol;), e usar uma configuração de latência maior 9como <guilabel>250ms</guilabel> ou <guilabel>não se preocupar</guilabel>), o que deverá melhorar a situação. </para>
<para>O texto de ajuda para esta configuração no &kcontrol; pode ser mau entendido. Um valor menor significa que o &arts; levará menos tempo para responder a eventos externos (&ie; o tempo que ele leva entre fechar uma janela e ouvir o som tocado pelo &artsd;). Isto também usará mais recursos da <acronym>CPU</acronym>, e causará uma maior probabilidade de saídas.</para>
<para>Para usuários de discos rígidos <acronym>IDE</acronym>, você pode usar o comando <command>hdparm</command> para colocar seu drive <acronym>IDE</acronym> no modo <acronym>DMA</acronym>. Um alerta: isto não funciona para todo hardware, e pode fazer com que o disco rígido reinicie ou em casos raros, perca dados. Leia a documentação do comando <command>hdparm</command> para mais detalhes. Eu tenho usado com sucesso o seguinte comando: </para>
<para>Você precisa rodar isto após cada boot, assim você pode desejar colocá-lo no script de inicialização do sistema (como fazer isto é específico da distribuição, no Debian &Linux; ele é colocado normalmente no <filename>/etc/rc.boot</filename>). </para>
<para>Verifique se o artswrapper está realmente instalado com suid <systemitem class="username">root</systemitem>, como deveria estar. Muitas distribuições (o SuSE7.x por exemplo) não fazem isto. Você pode verificar isto usando: ls -l $(which artswrapper). Bom: <screen>
</screen> Se você não tiver o the s, você pode obtê-lo usando: <screen><prompt>%</prompt> <userinput><command>chown</command> <option>root</option> <parameter>$(which artswrapper)</parameter></userinput>
<para>Se você tornar o &artswrapper; SUID <systemitem class="username">root</systemitem>, ele provavelmente melhorará a qualidade da reprodução do seu áudio reduzindo intervalos na música. No entanto, isto também aumento o risco que um erro no código ou um usuário malicioso possa travar ou talvez danificar sua máquina. Além disso, em máquinas com vários usuários, priorizar áudio de alta qualidade pode resultar na deterioração do desempenho para os usuários que estão tentando fazer um uso mais <quote>produtivo</quote> da máquina.</para>
<para>Verifique suas configurações de tempo de resposta. No entanto, a versão atual ainda não é realmente otimizada. Isto melhorará, e até agora nenhuma previsão real pode ser feita do quão rápido o &artsd; pode ou não ser. </para>
<para>Habilite-a nas configurações do <guilabel>Servidor de Som</guilabel> no &kcontrol; (<guilabel>habilite o servidor X11 para informações seguras</guilabel> e <guilabel>transparência de rede</guilabel>). Então copie seu <filename>.mcoprc</filename> para todas as máquinas que planeja usar transparência de rede. Logue novamente. Certifique-se de que as máquinas que interagirem conhecem as outras pelo nome (&ie; elas devem possuir nomes resolvíveis ou estarem no <filename>/etc/hosts</filename>). </para>
<para>Isto deve ser tudo o que você precisa fazer. No entanto, se isto ainda não funcionar aqui vão mais alguns detalhes adicionais. O processo do servidor de som &arts;, o &artsd;, somente deve rodar em uma máquina, a que tiver a placa de som onde o som será tocado. Ele pode ser iniciado automaticamente no login pelo &kde; (se você configurar isto no &kcontrol;), ou manualmente usando algo como: </para>
<para>em todas as máquinas envolvidas, para que a transparência de rede funcione. Isto é que é habilitado pela configuração <guilabel>servidor X11 para informações seguras</guilabel> do painel de controle. </para>
<para>Finalmente, em qualquer versão do &kde; da série 2.0.x, existe um erro que se manifesta se você não possui um conjunto de nomes de domínio. Clientes do &artsd; tentam encontrar onde conectar através da combinação <systemitem class="systemname"><replaceable>máquina</replaceable>.<replaceable>domínio</replaceable></systemitem>. Se seu nome de domínio for vazio, ele tentará conectar à <systemitem class="systemname"><replaceable>máquina</replaceable></systemitem>. (observe o ponto a mais). Adicionando uma entrada como esta no <filename>/etc/hosts</filename> (&ie; <userinput>orion.</userinput> se seu nome de máquina é <systemitem class="systemname">orion</systemitem>) contornará o problema. </para>
<para>Considerando que você possui o código fonte do &kde;, vá para <filename class="directory">tdelibs/arts/examples</filename>, e rode <userinput><command>make</command> <option>check</option></userinput> para compilar alguns programas, incluindo <application>referenceinfo</application>. Então rode </para>
<para>A saída indicará o nome de máquina e porta que está sendo usado pelo &arts;. Por exemplo, <computeroutput>tcp:orion:1698</computeroutput> o que significa que qualquer cliente que tente usar a transparência de rede deve saber como chegar à maquina <systemitem class="systemname">orion</systemitem>. </para>
<para>Parece que existem alguns poucos drivers linux que não funcionam bem com o aRts em algumas versões do kernel. Por favor leia esta lista antes de relatar um erro. Se você achar que alguma informação nesta lista está incompleta, por favor não hesite em informar-nos. <informaltable> <tgroup cols="4">
<para>O problema mais comum é que o driver não fornece ao aRts informações suficientes ou suficientemente precisas ao escrever dados de som. A maioria dos drivers OSS fornecem as informações corretas, mas nem todos. </para>
<para>Você deve saber que alguns outros aplicativos (como o xmms) podem não precisar destes dados, e assim funcionarem corretamente com seu hardware. No entanto, o &arts; precisa destes dados, assim o artsd deve falhar. Isto ainda assim é um erro no driver, e não no &arts;. </para>
<para>Existem dois tipos de comportamento que o artsd expõe ao ser rodado em um driver incorreto. Ele pode continuamente tentar obter novos dados, mas nunca consegí-los, o que eventualmente leva a consumir todos os recursos da CPU e reportar uma <emphasis>sobrecarga da cpu</emphasis> e terminar. O outro problema é que o artsd pode receber informações incorretas para processar. o artsd então <emphasis>interromperá com uma assertiva</emphasis> como: <screen>artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int):
<para>Normalmente, o artsd usa o select() para descobrir onde escrever novos dados. Então, ele usa um ioctl(...GETOSPACE...) para descobrir quantos dados escrever. Finalmente, ele escreve os dados. </para>
<para>Um problema ocorre se o artsd é despertado sempre ou se existem quantidades mínimas de dados para escrever. A documentação do OSS especifica que o select() somente acorda um processo se existir pelo menos um fragmento para escrever. No entanto, se o artsd é acordado e não existirem dados para escrever, ou muito pouco dado, por exemplo, uma amostra, então ele ficará escrevendo pequenos pedaços de dados de áudio, o que pode ser muito custoso, e eventualmente sobrecarregar a cpu. </para>
<para>Para corrigir isto, o driver deve acordar o artsd somente se existir um fragmento completo para escrever. </para>
<para>Normalmente, o artsd usa o select() para descobrir onde escrever novos dados. Então, ele usa um ioctl(...GETOSPACE...) para descobrir quantos dados escrever. Finalmente, ele escreve os dados. </para>
<para>Se o artsd não puder escrever tantos dados quanto os indicados pelo ioctl, ele falhará na assertiva. Para corrigir isto, o driver deve fornecer a quantidade correta de espaço livre. </para>
<para>A causa mais provável é que você está usando estruturas ou módulos antigos que não são mais suportados pela versão 2 do &kde;. Infelizmente a documentação que existe na web referente ao &arts; 0.3.4.1 está um pouco desatualizada. A maioria das quedas frequentemente reportadas é: que executando uma estrutura no &arts-builder; resulta na mensagem de erro <errorname>[artsd] Synth_PLAY: sub-sistema de áudio já está sendo usado.</errorname> </para>
<para>Você deve usar um Synth_AMAN_PLAY ao invés do módulo Synth_PLAY e o problema terminará. Veja também o arquivo de ajuda do &arts-builder; (clique <keycap>F1</keycap> no &arts-builder;). </para>
<para>Versões recentes do &arts-builder; (&kde; 2.1 beta 1 e posteriores) vem com um conjunto de exemplos que você pode usar. </para>
