Esta seção responde algumas das perguntas frequentemente feitas sobre o &arts;. O &kde; suporta minha placa de som para saída de áudio? O &kde; usa o &arts; para tocar sons, e o &arts; usa os drivers de som do kernel do &Linux;, tanto os OSS como os ALSA (usando emulação OSS). Se sua placa de som é suportada seja pelo ALSA ou pelo OSS 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 seção para problemas com hardwares específicos se você tiver problemas com o artsd em sua máquina. 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. Método de E/S (entrada e saída) de áudio do &arts; Comentário paud Suporte para Dispositivo de Áudio Pessoal AIX alsa Drivers ALSA-0.5 e ALSA-0.9 do Linux libaudioio Suporte para biblioteca genérica LibAudioIO que funciona no Solaris nas Servidor de som NAS, útil para Terminais X com suporte ao NAS null Dispositivo de áudio nulo, descarta o som silenciosamente oss Suporte ao OSS (do inglês, Sistema de Som Aberto) (funciona no Linux, diversos BSDs e outras plataformas com os drivers OSS instalados) toss Suporte ao OSS em linhas de execução, que funciona melhor em alguns casos onde o suporte ao OSS padrão não funciona bem sgi Suporte ao Mídia Direta SGI para IRIX sun Suporte ao Solaris Eu não consigo tocar arquivos wav com o &artsd;! Verifique se o &artsd; está linkado ao libaudiofile (ldd artsd). Caso contrário, baixe o tdesupport, recompile tudo, e então funcionará. Eu ouço som quando eu logo como root mas nenhum outro usuário tem som! As permissões do arquivo /dev/dsp afetam quais usuários terão som. Para permitir que todos o usem, faça isto: Logue como root. Abra uma janela do &konqueror;. Vá para a pasta /dev. Clique no arquivo dsp com o botão direito do mouse, e selecione propriedades. Clique na aba Permissões. Habilite as caixas de verificação Leitura e Escrita em todas as seções. Clique em OK. Você pode obter o mesmo efeito na janela do terminal usando o comando chmod 666 /dev/dsp. 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 /dev/dsp já está como pertencente ao grupo chamado audio, de modo que tudo o que precisa fazer é adicionar os usuários a este grupo. Isto ajuda para o &artsd;, mas e sobre o &kmix;, &kmid;, &kscd;, &etc;? 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 midi0, midi1, ..., então somente a versão 0 é listada aqui): /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 O que eu posso fazer se o artsd não inicia ou trava ao rodar? 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 -F10 -S4096 para latência). Especialmente o full duplex é conhecido por não funcionar com diversos drivers, logo tente desabilitá-lo. 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: % artsd -F10 -S4096 Você pode também adicionar a opção -l0, que imprimirá mais informações sobre o que está acontecendo, como isto: % artsd -l0 -F10 -S4096 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 como ele trava. Se você desejar relatar um erro, produzir um rastro de execução com o gdb e/ou um strace pode ajudar a encontrar o problema. Eu posso mudar a localização do &artsd; (mover os arquivos compilados para outra pasta)? 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 .mcoprc (entradas TraderPath/ExtensionPath) para pelo menos fazer com que o &artsd; encontre seus componentes. Veja o capítulo sobre o arquivo .mcoprc para detalhes sobre como fazer isto. Eu posso compilar o &arts; com o gcc-3.0? Resposta curta: não, o &arts; não funcionará se você compilá-lo com o gcc-3.0. 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. 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. Que aplicativos rodam sob o &arts;? Obviamente, todos os aplicativos incluídos com o &kde; são compatíveis com o &arts;. Isto inclui: &noatun; &arts-builder; &aktion; &kmid; &kmidi; &kmix; &kscd; Jogos do &kde; como o &kpoker; e o &ktuberling; Alguns aplicativos do &kde; que ainda não foram incluídos na versão do &kde; (⪚ no kdenonbeta) também suportam o &arts;, incluindo: &brahms; Kaboodle Kdao Os seguintes aplicativos não-&kde; são também conhecidos por funcionar com o &arts;: xmms (com o plug-in do &arts;) Real Networks RealPlayer 8.0 (funciona com o &artsdsp;; suporte nativo ao &arts; está sendo considerado) Os seguintes aplicativos são conhecidos por não funcionarem com o &arts;: nenhum Veja também as respostas e perguntas na seção em aplicativos não-&arts;. 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. Tão logo o &kde; esteja rodando, nenhum outro aplicativo pode acessar meu dispositivo de som! 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. Você disse que ele suspende após 60 segundos, isto não funciona para mim! 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. 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. Como eu possa rodar aplicativos antigos não-&arts;? Execute-os usando o &artsdsp;. Por exemplo, se você normalmente rodaria: % mpg123 foo.mp3 ao invés disso use: % artsdsp mpg123 foo.mp3 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. Eu não posso rodar o &artsdsp; com qualquer aplicativo, ele sempre trava! 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. Existem limitações teóricas com alguns aplicativos que os impedirão de funcionar sempre com o &artsdsp;? Não. Usar o &artsdsp; pode causar um pouco mais de latência e uso da CPU que usando a API 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 qualquer aplicativo funcionar com ele (incluindo aplicativos complexos como o Quake 3). O que eu posso fazer se um aplicativo não funciona com o &artsdsp;? Você pode esperar que o &artsd; suspenda ou usar o comando artsshell suspend 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. Se o servidor estiver ocupado, uma maneira bruta mas efetica de obter o rid dele é: % killall artsd ; killall artswrapper Agora inicie seu próprio aplicativo. % kcminit arts Qualquer aplicativo &arts; atualmente em execução deverá cair, no entanto, uma vez que você mate o servidor. E os aplicativos escritos para o &kde; 1.x? 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 kaudioserver para fazê-los funcionar. Você pode iniciar o kaudioserver da mesma maneira que outros aplicativos não-&arts;: % artsdsp kaudioserver 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. E os aplicativos usando o daemon do som do enlightened, ESD? A observação é semelhante a feita com o kaudioserver. Como os aplicativos precisarão de um servidor esd rodando, você pode iniciar o esd através do &artsdsp;, e cada aplicativo compatível com o ESD deve funcinar bem, como isto: % artsdsp esd 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 % artsd -a esd 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. Eu algumas vezes escuto pausas curtas ao ouvir uma música, isto é um erro? 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 250ms ou não se preocupar), o que deverá melhorar a situação. Qual o efeito da configuração do tempo de resposta? 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 CPU, e causará uma maior probabilidade de saídas. Existe alguma coisa que eu possa fazer para evitar pausas? Para usuários de discos rígidos IDE, você pode usar o comando hdparm para colocar seu drive IDE no modo DMA. 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 hdparm para mais detalhes. Eu tenho usado com sucesso o seguinte comando: % hdparm -c1 -d1 -k1 -K1 /dev/hda 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 /etc/rc.boot). A prioridade de tempo real parece não ter nenhum efeito para mim? Verifique se o artswrapper está realmente instalado com suid root, 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: % ls -l $(which artswrapper) -rwsr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper Ruim: % ls -l $(which artswrapper) -rwxr-xr-x 1 root root 4556 Sep 24 18:05 /opt/kde2/bin/artswrapper Se você não tiver o the s, você pode obtê-lo usando: % chown root $(which artswrapper) % chmod 4755 $(which artswrapper) Se você tornar o &artswrapper; SUID root, 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 produtivo da máquina. Porque o &artsd; toma tanto tempo da CPU? 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. O que eu preciso para transparência de rede? Habilite-a nas configurações do Servidor de Som no &kcontrol; (habilite o servidor X11 para informações seguras e transparência de rede). Então copie seu .mcoprc 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 /etc/hosts). 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: % artsd -n -F 5 -S 8192 O parâmetro -n é para a transparência de rede, enquanto os outros configuram a latência. Se arquivo .mcoprc deve ter esta entrada: GlobalComm=Arts::X11GlobalComm em todas as máquinas envolvidas, para que a transparência de rede funcione. Isto é que é habilitado pela configuração servidor X11 para informações seguras do painel de controle. 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 máquina.domínio. Se seu nome de domínio for vazio, ele tentará conectar à máquina. (observe o ponto a mais). Adicionando uma entrada como esta no /etc/hosts (&ie; orion. se seu nome de máquina é orion) contornará o problema. Como eu depuro a transparência de rede se ela não funcionar? Considerando que você possui o código fonte do &kde;, vá para tdelibs/arts/examples, e rode make check para compilar alguns programas, incluindo referenceinfo. Então rode % ./referenceinfo global:Arts_SimpleSoundServer A saída indicará o nome de máquina e porta que está sendo usado pelo &arts;. Por exemplo, tcp:orion:1698 o que significa que qualquer cliente que tente usar a transparência de rede deve saber como chegar à maquina orion. Com qual hardware o artsd não funciona bem? 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. Driver Linux / Placa de som Falha sob Funciona sob Comentários driver i810 (Intel 810 + Áudio AC97) 2.4.9 2.4.18, 2.2.20, driver oss comercial, alsa-0.5.12a com emulação OSS driver causa sobrecarga da cpu (veja abaixo) chipset maestro 3/4 2.4.9 ? driver causa algumas vezes sobrecarga da cpu (veja abaixo) drivers aureal8820, aureal8830 do sourceforge 2.4.17 ? driver dispara assertivas / causa sobrecarga da cpu (veja abaixo) OSS 3.9.4g Comercial com Aureal Vortex ? ? travamento do sistema ymfpci 2.4.0, 2.4.12 2.4.17 driver dispara assertiva (veja abaixo) Porque existem problemas específicos de hardware e como vê-los? 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. 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;. 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 sobrecarga da cpu e terminar. O outro problema é que o artsd pode receber informações incorretas para processar. o artsd então interromperá com uma assertiva como: artsd: audiosubsys.cc:458: void Arts::AudioSubSystem::handleIO(int): Assertion `len == can_write' failed. Aborted O que está errado no driver se eu detecto um problema de sobrecarga da cpu? 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. 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 corrigir isto, o driver deve acordar o artsd somente se existir um fragmento completo para escrever. O que está errado no driver se eu detecto a assertiva? 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. 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. Eu não posso usar o &arts-builder;. Ele cai ao executar um módulo! 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 [artsd] Synth_PLAY: sub-sistema de áudio já está sendo usado. 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 F1 no &arts-builder;). Versões recentes do &arts-builder; (&kde; 2.1 beta 1 e posteriores) vem com um conjunto de exemplos que você pode usar.