Como eu crio um dispositivo de reprodução sob pavucontrol?

1

Primeiro, confesso minha falta de compreensão do áudio do Linux. Parece grande, confuso e um pouco assustador.

O que eu estou tentando fazer é canalizar o áudio do programa HAM Radio gqrx para o decodificador de fala digital dsd , como visto em outros exemplos que flutuam pela web.

Mas depois de criar um dispositivo de som virtual em /dev/dsp/ usando:

padsp -- dsd -i /dev/dsp -o /dev/dsp -fa -ma

Não vejo o dsd listado em dispositivos de reprodução quando abro pavucontrol (mas vejo gqrx listado)? Eu tentei muitas coisas diferentes, mas não consigo obter dsd listado em dispositivos de reprodução. Esta etapa é necessária para ir mais longe e usar os outros coletores de áudio para ouvir a saída.

Obrigado antecipadamente ...

    
por user2925489 30.12.2017 / 20:50

1 resposta

0

Para tornar o áudio do Linux menos assustador, uma rápida visão geral da história de áudio do Linux (google para mais detalhes):

O primeiro sistema de som amplamente usado no Linux foi o Open Sound System (OSS) , que usava dispositivos como /dev/dsp . Agora o OSS é obsoleto, mas ainda existem programas antigos que o usam exclusivamente, de modo que quase todos os outros sistemas de áudio fornecem uma camada de emulação, como padsp do Pulseaudio.

Hoje, o sistema básico de áudio usado no Linux é ALSA . Ele se tornou parte do kernel e fornece drivers para o hardware. Os dispositivos parecem com /dev/snd/pcmC0D0p (cartão 0, dispositivo 0, reprodução) ou /dev/snd/pcmC1D2c (cartão 1, dispositivo 2, captura), mas todos usam uma biblioteca ( libalsa ) em vez dos dispositivos diretamente, porque você não pode canalizar coisas para eles como para /dev/dsp . O ALSA pode ser configurado via /.asoundrc , mas este arquivo de configuração não é muito amigável.

A maioria dos sistemas de desktop hoje também vem com o Pulseaudio. Ele executa uma parte superior do ALSA e não apenas fornece uma camada de compatibilidade para OSS, mas também uma camada de compatibilidade para programas que tentam acessar o ALSA (usando um dispositivo pseudo-ALSA chamado pulse ). Você já viu pavucontrol , também há pacmd e pactl para controlar o Pulseaudio a partir da linha de comando (não me pergunte por que há dois deles ...).

Voltar para o seu problema. O que você deve ver na guia de reprodução e na guia de gravação de pavucontrol após a execução

padsp -- dsd -i /dev/dsp -o /dev/dsp -fa -ma

é algo como OSS emulation[dsd] . Possivelmente você ficou confuso com a parte "emulação de OSS" (que está lá porque padsp faz emulação de OSS). Se você realmente não vê isso, por favor edite sua pergunta com quaisquer erros que possam aparecer depois de executar o comando acima, e também com a saída de pactl list short clients enquanto o comando estiver rodando. Então podemos tentar depurar o que está errado.

No Pulseaudio, cada coletor de áudio (por exemplo, hardware de reprodução de sua placa de som) também tem uma fonte de áudio associada .monitor . Você canaliza áudio de um aplicativo para outro aplicativo conectando o segundo aplicativo a uma fonte .monitor do coletor no qual o primeiro aplicativo está sendo executado. Você pode fazer isso em puvacontrol , conforme descrito nos tutoriais que você já leu.

No seu caso, você deseja monitorar a saída de som de gqrx , para que você possa usar apenas o coletor de áudio de hardware. Você poderia também criar um coletor de áudio "virtual" com .monitor source associado, mas você não ouviria o áudio.

snd_aloop é uma maneira diferente (e um pouco complicada) de fazer loopback somente no ALSA. Como você está executando o Pulseaudio, não use .

Editar

Eu recriei seu problema seguindo esta entrada de blog sobre como configurar dsd e gqrx , exceto que recebo cinco fluxos (o que você vê em Reproduzir e Gravar em pavucontrol são fluxos de áudio, não dispositivos), exceto os três. Lembro-me vagamente de que tive algum problema semelhante com padsp no passado (ele criou vários fluxos quando deveria criar apenas um), mas funcionou, no entanto, apenas ignorando os fluxos extras. Eu também dei uma olhada rápida em padsp.c , e os fluxos só parecem ser criados quando a E / S acontece. É provavelmente por isso que não há fluxo de reprodução (ainda). É possível que padsp tenha mudado desde que a entrada do blog foi escrita e algo ficou complicado no processo.

Portanto, escolha um dos fluxos de OSS emulation[dsd] em Registro (estas são as entradas de dsd , não tem nada a ver com o que você deseja gravar), conecte-o ao .monitor input de qualquer coletor gqrx está jogando, alimente-o com dados válidos (eu não posso fazer isso aqui, porque eu não sei quais dados ele espera, então eu não posso testar), e veja se você obter um fluxo de reprodução.

Se você quiser apenas reproduzir a saída do dsd em seu hardware, crie um coletor virtual com

pacmd load-module module-null-sink sink_name=gqrx_to_dsd  sink_properties=device.description=GQRX-to-DSD

selecione este coletor como saída de gqrx e a .monitor deste coletor como entrada de dsd . Em seguida, selecione o seu coletor de áudio de hardware como saída de dsd (você deve obter um fluxo de reprodução).

    
por 31.12.2017 / 09:08