¿Cómo puedo forzar el redescubrimiento de los dispositivos de sonido virtual PulseAudio?

8

Estoy usando la función PulseAudio de dispositivos de sonido de red (no Multicast / RTP) para reproducir sonido desde mi netbook en el equipo de audio conectado al HTPC cuando estoy en casa. Esto crea un dispositivo de sonido virtual que luego puedo usar en lugar del físico incorporado. La mayoría de las veces esto funciona bien. A veces, sin embargo, el dispositivo de sonido virtual simplemente no aparece. Desconectarse y volver a conectarse a la red ayuda a veces, pero no siempre, y es molesto y potencialmente malo para las conexiones TCP existentes.

Entonces mi pregunta básicamente es: ¿Hay alguna forma de decirle a PulseAudio "Oye, solo mira de nuevo si realmente no puedes encontrar un dispositivo de sonido de red"?

Editar: descargar y volver a cargar module-zeroconf-discovercon pacmdtampoco ayuda y no parece ser un problema de por sí, ya que avahi-browse -t --all | grep PulseAudiomuestra muchas cosas de aspecto correcto, incluso cuando los dispositivos no están listados en pavucontrol o pacmd list-sinks.

Edición 2: estoy usando Ubuntu 12.04 en ambos cuadros para toda la diferencia que pueda hacer.

— cristiano
fuente

Si le falta información para proporcionar comentarios útiles o incluso una respuesta, dígamelo.

— Christian

7

En la PC "Sink" (en cuyo altavoz quieres reproducir el sonido) abre el shell de comandos de PulseAudio yendo a Terminal y emitiendo el siguiente comando.

$ pacmd

Verá un shell similar a Python con el siguiente mensaje de bienvenida.

Welcome to PulseAudio! Use "help" for usage information. >>>
Enumere los dispositivos que pueden reproducir el sonido en la PC mediante el comando en el shell PulseAudio.
>>> list-sinks
Ahora verá una lista detallada de todos los sumideros de sonido.
Solo anote el nombre completo del fregadero de su elección. Aparecería como un atributo de la tarjeta de sonido. Por ejemplo en mi caso es:

1 sink(s) available. index: 0 name: <alsa_output.pci-0000_00_1b.0.analog-stereo>
...

La cadena de mi interés es solo "alsa_output.pci-0000_00_1b.0.analog-stereo"

Ahora vaya a la PC de origen (es decir, el origen de las transmisiones multimedia de audio), abra el terminal y emita el siguiente comando

$ pactl load-module module-tunnel-sink "server=192.168.1.105 sink=alsa_output.pci-0000_00_1b.0.analog-stereo sink_name=home_theater"

Aquí 192.168.1.105 es la dirección IP de la PC de sumidero, "alsa_output.pci-0000_00_1b.0.analog-stereo "es la cadena que acaba de copiar desde la terminal del receptor y" home_theater "es solo un nombre elegante para llamar a este dispositivo de salida de sonido virtual en su computadora.
Finalmente seleccione este dispositivo de sonido virtual por:
$ pacmd set-default-sink home_theater

Wallah !!

— Rishav Ambasta
fuente

Funcionó para mí: también funciona con el nuevo módulo de sumidero de túnel y solo con la dirección IP del host del sumidero sin necesidad de especificar el sumidero exacto (solo uso uno en este Raspberry Pi conectado a mi estéreo, por lo que no es necesario): 'pactl load-module module-tunnel-sink-new server = [2001: 470: ca90: 4: ba27: ebff: fee2: ada9] '- ¡gracias!

— Jean-Marc Liotier

4

Un simple sudo service avahi-daemon restarthace el truco, a pesar de que avahi-browseve los dispositivos antes de que se reinicie ese avahi. Gracias a Takkat por señalarme en la dirección correcta.

— cristiano
fuente

3

Esta respuesta no ha sido probada, por lo que podría no funcionar, pero puede llevarlo a la dirección correcta.

Puedo confirmar problemas no resueltos con un servicio Avahi que a veces no puede conectarse a un servidor PulseAudio. Puede que tengamos éxito reconectando reiniciando la red o el servidor pulseaudio, pero lamentablemente esto no siempre funciona.

Para superar este problema, podemos intentar establecer una transmisión de audio de red utilizando el protocolo TCP nativo para transmitir directamente a la IP en lugar de utilizar una resolución de nombre Avahi.

Para hacerlo, podemos tunelizar un sumidero remoto cargando el módulo-túnel-sumidero en el lado del receptor. En el remitente tenemos que habilitar el protocolo TCP nativo cargando module-native-protocol-tcp .

Vea también esta pregunta para la terminología y cómo definir la PULSE_SERVERvariable:

Cómo configurar automáticamente el receptor predeterminado de PulseAudio en el servidor remoto en el arranque - Ubuntu 9.04

Es una pregunta bastante antigua para Ubuntu 9.04, pero para mi conocimiento, la terminología y los procedimientos no han cambiado mucho desde entonces.

Siga también el Wiki PulseAudio sobre conexiones de red .

— Takkat
fuente

Gracias por el enlace. La solución allí también funciona en mi caso: sudo service avahi-daemon restartno esperaba eso porque avahi-browseve los dispositivos incluso antes del reinicio, pero supongo que el reinicio provoca que se vuelva a llamar a la devolución de llamada, que es todo lo que se necesita.

— Christian

@Christian: bueno, ayudó. He renunciado a Avahi por el momento.

— Takkat

Sin embargo, no estoy seguro de haber entendido tu propuesta. ¿Puedo usar la resolución de nombre DNS o tengo que conocer la IP? Prefiero no usar IP fijas, aunque podría decir que en el caso de HTPC, esto es algo correcto.

— Christian

1

Sí, puedo entender por qué. Sin embargo, acabo de escribir mi propia respuesta porque para las personas que tropiezan con esta pregunta porque tienen el mismo problema, parece la solución más simple.

— Christian

1

Puede intentarlo pulseaudio -k, lo que mata el servicio pulseaudio (parece que se inicia de nuevo automáticamente). Esto me ha devuelto las cosas antes.

La otra cosa que a veces ayuda es desmarcar y luego volver a marcar las casillas en Pulseaudio Preferences(aka paprefs). Las casillas de verificación están Make discoverable PulseAudio network sound devices available locallyen Network Access, y Enable network access to local sound devicesen Network Server. Obviamente, esto probablemente solo funcione para el que estás usando.

— Gibraltar
fuente