Tengo un problema similar con Pulseaudio 6.0. Pulseaudio tiende a no reproducirse en absoluto o a bloquearse después de unos minutos de reproducción. También usando Arch Linux. He probado tanto el modo de usuario (que se ejecuta como root) como el modo de sistema, ya que tengo el Pi configurado sin cabeza.

El siguiente es el error impreso por Pulseaudio cada vez que se cuelga (después de aproximadamente uno o dos minutos de reproducción, generalmente)

E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA nos despertó para escribir nuevos datos en el dispositivo, ¡pero en realidad no había nada que escribir!
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Lo más probable es que se trate de un error en el controlador ALSA '(nulo)'. Informe este problema a los desarrolladores de ALSA.
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Nos despertaron con el conjunto POLLOUT; sin embargo, un snd_pcm_avail () posterior devolvió 0 u otro valor <min_avail.

Yo también estoy teniendo problemas terribles con el bcm2835 y el pulso 6.
Si inicio pulseaudio y ejecuto paplay localmente (en el pi), comienza a reproducirse inmediatamente con el audio distorsionado. Algunas partes del PCM suenan como si se estuvieran reproduciendo fuera de orden. Cuanto más tiempo se reproduce el audio, peor se pone hasta que el audio es casi puro ruido.
Matar (CTRL + C) y ejecutar paplay las veces siguientes provoca un patrón repetible de distorsionar el audio o silencio puro, hasta que en la octava ejecución se reproduce el audio perfecto. Tócala de nuevo y el ciclo se reinicia.
El patrón es confuso, silencioso, confuso, confuso, silencioso, confuso, silencioso, perfecto.
Si utilizo unos auriculares USB, la reproducción funciona siempre.
Lo he tenido donde tengo la reproducción de audio a través del auricular USB perfecto, y luego desconecto el dongle USB y el audio se reproduce correctamente desde el puerto analógico del pi. Detenga y reinicie el audio y se distorsionará.

Mi configuración: pulseaudio + mpd + ncmpcpp.

Mi configuración de prueba es iniciar una canción y reproducir / pausar repetidamente. Después de un máximo de 3 veces de reproducción / pausa, pulseaudio se colgará y deberá reiniciarse.
Esto solo sucede en mi Raspberry B + con el chip bcm2835, tanto con distribuciones basadas en Debian como en Arch. No tengo problemas con exactamente la misma configuración en mi PC de escritorio con un chip de sonido Intel. El problema no existía con el kernel 3.6 (pero no quiero usar una distribución antigua).

Ninguna de las soluciones alternativas que se encuentran en la web (tsched = 0, deshabilitar el módulo-suspender en inactivo, ...) ha funcionado. Finalmente renunciaré a este problema porque no encontré una solución durante más de un año. O me compraré una Raspberry 2 o usaré mpd con el backend de ALSA, porque eso funciona muy bien.

@maxnet, ¿ se ha resuelto este problema? En caso afirmativo, cierre este problema.

No lo creo. Tampoco funciona con Raspberry 3 (lo cual no es de extrañar porque usa el mismo chip / controlador: snd_bcm2835).

Tengo este problema en mi Raspberry 3 con ubuntu 16.04. Como solución, pondré un retraso de tiempo de espera de 5 segundos en mi programa, pero eso estropea la naturalidad de la salida (es un sintetizador de voz)

El mismo problema con mi pi3 y ubuntu mate 16.04 y mpd suena fantástico a menos que cambie el volumen (lo que causa tartamudeo o pérdida de sonido) también pierde el sonido al azar entre otros problemas. Realmente frustrante.

Mismo problema en Rpi B (no 2 o 3) con el último kernel (684be4bc8cc343f60fdc3240c6d55d41d0a5b56c)

Puede confirmar ese problema con un rpi3 ejecutando Linux raspberrypi 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux en raspbian .. Pulseaudio generalmente deja de reproducirse entre las pistas que le envío desde mpd (desde otro host a través de la red). Al intentar reproducir audio flac de 24 bits a través de mpd para pulsar, solo se reproduce 2 segundos y se congela.

Confirmando problema en rpi3 ejecutando 4.9.30-v7+ . Llenar la lista de reproducción de mpds y comenzar la reproducción generalmente funcionará hasta que se complete la lista de reproducción, pero cambiar manualmente las pistas, detener y reiniciar, detendrá la salida de audio hasta que reinicie mpd.

audio_output {
        type            "alsa"
        name            "ALSA Output"
#       device          "hw:0,0"        # optional
        mixer_type      "software"      # optional
#       mixer_device    "default"       # optional
#       mixer_control   "PCM"           # optional
#       mixer_index     "0"             # optional
#       auto_resample   "no"
#       auto_channels   "no"
#       auto_format     "no"
}

Tener el mismo comportamiento problemático descrito por @flittermice : decepcionado:
El sistema es RPi2 y ejecuta una instalación nueva de Raspbian Stretch (9.1) con pulseaudio v10.0-1 + deb9u1, kernel 4.9.59+
He estado leyendo artículos / tutoriales / hilos relacionados, pero la reproducción de MPD se cuelga como se describe arriba, hasta que elimino y reinicio pulseaudio.

¿Alguien ha encontrado una solución a esto todavía? : dedos_cruzados:: sonrisa:

Encontré algo interesante (tal vez):
Cuando pulseaudio se cuelga (como se describe arriba), emitir un comando "paplay" dos veces (!) Reanuda la reproducción de audio:
$ paplay /usr/share/sounds/alsa/Front_Center.wav

• La primera vez, el comando paplay expira (o puede ser interrumpido por Ctrl + C)
• La segunda vez que funciona el comando paplay, ahora se reanuda el sonido de MPD.

Funciona durante una cantidad de tiempo aleatoria, luego vuelve al comportamiento de

Profundí más en este problema y descubrí que el uso de Pulseaudio de una característica esotérica de ALSA llamada "rebobinado" está causando este problema.
Desafortunadamente, no existe una opción de configuración para evitar que PA use esa función.
Esta rama lo deshabilita permanentemente en el código fuente: https://github.com/strfry/pulseaudio/tree/no_rewind
Si puede compilarlo e instalarlo en su sistema, verifique si eso soluciona su problema.

Profundicé más en este problema y descubrí que el uso de Pulseaudio de una función esotérica de ALSA
llamado "rebobinado" está causando este problema.
Desafortunadamente, no existe una opción de configuración para evitar que PA use esa función.

Pero, ¿puede Pulse funcionar correctamente si elimina esa característica?

Tenga en cuenta que parte de la funcionalidad que ofrece como servidor de sonido es mezclar sonido que puede originarse en varias aplicaciones juntas.
Y me imagino que si desea permitir que las nuevas aplicaciones agreguen sonidos a la mezcla al instante, necesita una forma de descartar parte del búfer existente.
De lo contrario, solo puede agregar sonido nuevo al final del búfer y tendrá un retraso, lo que la aplicación puede no esperar. Y que puede ser un problema para algunos propósitos (por ejemplo, video con sonido)

@maxnet Una solución adecuada (la mía no lo es) fijaría la latencia en un valor bastante bajo, lo que elimina la necesidad de rebobinar, a costa de una carga de CPU / consumo de energía ligeramente mayor.
Funciona bien para mi aplicación de baja latencia, para reproducir música con MPD, puede ser un poco molesto no tener que rebobinar (sin parchear PA para hacer solo búferes de baja latencia).

Tener siempre una latencia baja, implicaría usar búferes diminutos.
Lo que tampoco me suena ideal.

Diría que una solución adecuada estaría en el módulo del kernel ...

@strfry : la relación con el rebobinado de ALSA suena razonable. Cuando pulseaudio se vuelve "infeliz", generalmente termina en esta línea:

D: [alsa-sink-bcm2835 ALSA] source.c: Procesando rebobinado ...

Sin embargo, estoy algo de acuerdo con @maxnet , y probablemente haya una razón para que ALSA haga esto en primer lugar ...: guiño:

¿Es esto solo no funcional en Raspberry Pi o un problema general de pulseaudio + ALSA?
Siendo todavía un problema durante más de 3 años, ¿deberíamos informar esto a los desarrolladores de pulseaudio / ALSA en lugar de aquí?

@ pjotrek-b No es funcional solo con la 'tarjeta' de sonido incorporada Raspberry PI. Utilizamos pulseaudio como servidor de sonido en red con éxito con una tarjeta de sonido USB durante varios meses sin problemas.

Puedo confirmar la declaración de @jekhor .
La misma configuración funciona perfectamente con mi tarjeta de sonido USB (snd_usb_audio) en la Raspberry Pi.

Como dice el archivo de registro: "E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Lo más probable es que se trate de un error en el controlador ALSA '(nulo)'. Informe este problema a los desarrolladores de ALSA". ¿Alguien sabe como hacer esto?

@jekhor : ¡Gracias por aclarar esto! :sonreír:

Lo que ahora es desconcertante es que, siempre pensé que era así:
application > pulseaudio > ALSA > driver > hardware

Si es así, ¿cómo pueden las mismas aplicaciones que tienen este problema funcionar sin problemas cuando se usa ALSA directamente?
application > ALSA > driver > hardware

Ahora bien, si este problema es específico de la tarjeta de sonido / chip integrado de RPi, ¿cómo es que estos problemas no aparecen también con el uso exclusivo de Alsa? :confuso:

@strfry : Encontré un artículo bastante detallado sobre "Rebobinar" en la documentación de pulseaudio .

He leído partes de él y ya no me parece tan "esotérico". Ya que ha mirado su código: ¿Alguna idea de qué podría hacer que pulseaudio "se atasque"?
Como mencioné anteriormente, ejecutar "paplay" dos veces parece darle un "empujón" para volver a trabajar de nuevo ...: smile:

@ pjotrek-b Seguro que tiene sentido dados los objetivos de diseño de Pulseaudio. Es "esotérico" en el sentido de que el 99% de las aplicaciones normales de ALSA nunca utilizarán el rebobinado y, por lo tanto, activarán una ruta menos probada en el controlador ALSA. Desafortunadamente, Pulseaudio no tiene la opción de deshabilitar el uso de esta función potencialmente defectuosa (como otras, por ejemplo, programación basada en temporizador).
No he depurado los detalles exactos, pero básicamente Pulseaudio se atasca en un bucle sin fin, porque ALSA no informa correctamente cuándo es el momento de escribir datos de audio en el dispositivo nuevamente.
A pesar de las posibilidades de solucionar esto por parte de Pulseaudio, se trata de un error en el controlador ALSA.
Mi sospecha es que la emisión de nuevas transmisiones generará los eventos que Pulseaudio está esperando cuando se atasque.

@flittermice Supongo que en este caso, el desarrollador responsable de ALSA es uno de los desarrolladores del kernel de Raspberry Pi que escribió el controlador snd_bcm2835, por lo que este repositorio sería el lugar adecuado para informar esto.

Un ejemplo de código simple que demuestre un comportamiento claramente incorrecto de ALSA cuando se usa el rebobinado probablemente sería útil para los desarrolladores del kernel cuando examinaran más de cerca este error.

@ pjotrek-b Seguro que tiene sentido dados los objetivos de diseño de Pulseaudio. Es "esotérico" en el sentido de que el 99% de las aplicaciones normales de ALSA nunca utilizarán el rebobinado y, por lo tanto, activarán una ruta menos probada en el controlador ALSA. Desafortunadamente, Pulseaudio no tiene la opción de deshabilitar el uso de esta función potencialmente defectuosa (como otras, por ejemplo, programación basada en temporizador).
No he depurado los detalles exactos, pero básicamente Pulseaudio se atasca en un bucle sin fin, porque ALSA no informa correctamente cuándo es el momento de escribir datos de audio en el dispositivo nuevamente.
A pesar de las posibilidades de solucionar esto por parte de Pulseaudio, se trata de un error en el controlador ALSA.
Mi sospecha es que la emisión de nuevas transmisiones generará los eventos que Pulseaudio está esperando cuando se atasque.

@flittermice Supongo que en este caso, el desarrollador responsable de ALSA es uno de los desarrolladores del kernel de Raspberry Pi que escribió el controlador snd_bcm2835, por lo que este repositorio sería el lugar adecuado para informar esto.

Un ejemplo de código simple que demuestre un comportamiento claramente incorrecto de ALSA cuando se usa el rebobinado probablemente sería útil para los desarrolladores del kernel cuando examinaran más de cerca este error.

Si es así, ¿cómo pueden las mismas aplicaciones que tienen este problema funcionar sin problemas cuando se usa ALSA directamente?

Las aplicaciones que utilizan ALSA directamente normalmente no necesitan utilizar el rebobinado.
Saben exactamente qué sonido quieren reproducir en los próximos segundos y lo envían al dispositivo de audio.

Se utiliza en situaciones en las que hay un cambio de planes.
Si Pulse ya ha enviado el audio durante los siguientes 2 segundos al dispositivo y, de repente, un cliente Pulse diferente se conecta y quiere reproducir el sonido también, sin tener que esperar a que esos 2 segundos terminen primero, tiene que decirle al sonido. dispositivo para descartar el búfer anterior y reemplazarlo con nuevos datos que tienen el sonido adicional mezclado.

Claro, si usa pequeños búferes que contienen milisegundos en lugar de segundos de audio, podría hacerlo sin rebobinar.
Sin embargo, no creo que se prefiera.
Bajo Linux no hay garantías sobre la cantidad de tiempo de CPU que recibe una aplicación, ni de que se divida de manera uniforme, no es un sistema operativo en tiempo real.
Si otra aplicación está usando mucho, y Pulse no tiene suficiente tiempo para mantener ese pequeño búfer lleno en todo momento, se agotará y su sonido se tartamudeará.

Como mencioné anteriormente, ejecutar "paplay" dos veces parece darle un "empujón" para volver a trabajar de nuevo ...: smile:

Pulse Audio también cierra la conexión al dispositivo de sonido 5 segundos después de que se desconecta el último cliente que lo usó, si no se conectan otros clientes durante ese tiempo.
Y lo vuelve a abrir la próxima vez que un cliente quiera usarlo.
Entonces, si hay suficiente tiempo entre sus comandos, esa también podría ser la razón por la que está funcionando nuevamente.

@strfry y @maxnet :
¡Muchas gracias por estas respuestas detalladas!

¿Alguien sabe si esto sigue siendo un problema en el último Raspbian (con kernel 4.14.y)?

Este problema se cerrará dentro de los 30 días a menos que se publiquen más interacciones. Si desea que este problema permanezca abierto, agregue un comentario. Un problema cerrado puede reabrirse si se solicita.

Lo comprobaría, pero actualmente no tengo tiempo para probarlo ...: decepcionado:
Por si acaso: ¿Puedo volver a abrirlo si lo pruebo después de 30 días y sigue siendo un problema?

Aunque estoy bastante seguro de que no ha habido mejoras, no puedo contribuir mucho para este error en particular. Compré una tarjeta de sonido USB externa con un chipset PCM2704 y ahora estoy contento con el controlador snd_usb_audio.
Usar la salida HDMI del raspi habría sido una buena opción, pero mi raspi incluso se negaría a arrancar con el cable HDMI enchufado al receptor AV ... pero esa es otra historia.

Cierre por falta de actividad. Solicite que se vuelva a abrir si cree que este problema sigue siendo relevante.

Puedo confirmar que esto le pasa a mi Rasp Pi 3
Estoy ejecutando ArchARM con la versión del kernel 4.14.69

Puedo confirmar que esto todavía está sucediendo en mi RPI3:

Linux 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux

Tratando de usar mpd con pulseaudio obtengo:

Nov 05 09:25:17 noise systemd[1]: Started Music Player Daemon.
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] server-lookup.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:19 noise pulseaudio[1567]: [pulseaudio] main.c: Unable to contact D-Bus: org.freedesktop.DBus.Error.NotSupported: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Most likely this is a bug in the ALSA driver '(null)'. Please report this issue to the ALSA developers.
Nov 05 09:25:20 noise pulseaudio[1567]: [alsa-sink-bcm2835 ALSA] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

¿Alguna posibilidad de que podamos reabrir este problema?

Puedo confirmar que esto le pasa a mi Rasp Pi 3
Estoy ejecutando ArchARM con la versión del kernel 4.14.69
Esto se debió a un permiso incorrecto, lo hice funcionar.

@ l4rzy : nos estás dando curiosidad. ¿Qué permisos?

@flittermice : Vaya,
Intenté configurar mi Raspberry Pi 3 para un servidor de audio Pulse de red local, funcionó sin problemas, pero después de un tiempo sin reproducir nada, el servidor de audio Pulse se apagó automáticamente. Luego instalo mpd para reproducir música de SoundCloud, que siempre abre una conexión a Pulse y lo mantiene funcionando. No es una mala solución, creo.

@ l4rzy : Trabajar es el camino a seguir :-)

Por cierto: ¿Alguna vez intentó no cargar "module-suspend-on-idle" en default.pa?

módulo de carga módulo-suspensión en inactivo

@flittermice lo intenté. No ayuda.

Pulseaudio todavía no funciona con snd_bcm2835. ¿Puede reabrir este problema, por favor?

Puedo confirmar que tampoco me funciona. He estado probando diferentes códigos y opciones de compilación y no he podido hacer que funcione. Estoy en ArchLinux ARM y todo el software más nuevo. Me complace ayudar a depurar si es posible.

Para mí, por lo que puedo decir, el problema proviene del tamaño del búfer informado por el módulo bcm2835_alsa. El búfer de audio informado a pulso es de 8816 bits, o lo suficiente para aproximadamente 1,56 ms de audio de una transmisión de red. No soy lo suficientemente experto en hardware para encontrar las especificaciones, pero algo parece estar mal aquí. Según la propia ALSA (es decir, no el módulo de pulsos) el tamaño del búfer es mucho más lógico de 131072 bits. Si tuviera que adivinar, pulse piensa que no puede mantener el búfer lleno para la tarjeta e intenta rebobinar porque se le dice que hay un límite de software de 8816 bits ... pero tal vez estoy fuera de lugar aquí.

Acabo de tener el mismo problema (es realmente molesto), @ JamesH65, ¿ podrías volver a

Hmmm ... No puedo reproducir esto con Raspberry Pi 3 B v1.2 y el último kernel 4.19.34 (actualizado por rpi-update a https://github.com/Hexxeh/rpi-firmware/commit/99c274691c07480762dcda91a0ebfe3c4f519307). No tengo idea de por qué, el controlador parece no haber cambiado desde 2016. ¿Quizás algunos cambios en el firmware de VC?

Hola, en Raspberry Pi 4 B v1.1, el kernel 5.3.0-1014 tiene el mismo problema con la atenuación del sonido con pulseaudio v13.0. El sonido se pierde si se selecciona una salida estéreo en pavucontrol. ¿Hay alguna solución?

@acegallagher :

El búfer de audio informado a pulso es de 8816 bits, o lo suficiente para aproximadamente 1,56 ms de audio de una transmisión de red.

Creo que esto se debe a que PulseAudio está detectando los sumideros como Mono por defecto ( debido a este problema ), y el tamaño de búfer predeterminado para estos es menor.
Intente actualizar el archivo de configuración de perfil predeterminado de PA para que se creen sumideros estéreo en su lugar, ya que esto hará que PA cree sumideros con device.buffering.buffer_size = "17632" , ¡lo que parece mejor!

@ olevenets2

Hola, en Raspberry Pi 4 B v1.1, el kernel 5.3.0-1014 tiene el mismo problema con la atenuación del sonido con pulseaudio v13.0. El sonido se pierde si se selecciona una salida estéreo en pavucontrol. ¿Hay alguna solución?

Asegúrese de actualizar el archivo de configuración de perfil predeterminado de PA para que la salida estéreo realmente funcione usando PA en el RPI 4, y asegúrese de tener load-module module-udev-detect y no load-module module-alsa-sink en su /etc/pulse/default.pa .