J'ai un problème similaire avec Pulseaudio 6.0. Pulseaudio a tendance à ne pas jouer du tout ou à se verrouiller après quelques minutes de lecture. Utilisant également Arch Linux. J'ai essayé à la fois le mode utilisateur (en tant que root) et le mode système, car j'ai configuré le Pi sans tête.

Ce qui suit est l'erreur imprimée par Pulseaudio chaque fois qu'il se bloque (après environ une minute ou deux de lecture, généralement)

E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: ALSA nous a réveillés pour écrire de nouvelles données sur l'appareil, mais il n'y avait en fait rien à écrire!
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Il s'agit probablement d'un bogue dans le pilote ALSA '(null)'. Veuillez signaler ce problème aux développeurs ALSA.
E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Nous avons été réveillés avec POLLOUT set - cependant un snd_pcm_avail () ultérieur a renvoyé 0 ou une autre valeur <min_avail.

J'ai moi aussi de terribles problèmes avec le bcm2835 et le pulse 6.
Si je lance pulseaudio et lance paplay localement (sur le pi), il commence immédiatement à jouer avec l'audio tout brouillé. Certaines parties du PCM semblent être lues dans le désordre. Plus l'audio est lu, plus il s'aggrave jusqu'à ce que l'audio soit un bruit presque pur.
Tuer (CTRL + C) et exécuter paplay les fois suivantes provoque un modèle répétable de brouillage de l'audio ou de silence pur, jusqu'à ce que lors de la 8ème exécution, l'audio soit parfait. Jouez à nouveau et le cycle redémarre.
Le motif est brouillé, silencieux, brouillé, brouillé, silencieux, brouillé, silencieux, parfait.
Si j'utilise un casque USB, paplay fonctionne à chaque fois.
Je l'ai eu là où la lecture audio sur le casque USB est parfaite, puis je débranche le dongle USB et l'audio joue correctement sur le port analogique du pi. Arrêtez et redémarrez l'audio et il sera brouillé.

Ma configuration: pulseaudio + mpd + ncmpcpp.

Ma configuration de test consiste à démarrer une chanson et à lire / mettre en pause à plusieurs reprises. Après un maximum de 3 fois de lecture / pause, pulseaudio se bloque et doit être redémarré.
Cela ne se produit que sur mon Raspberry B + avec la puce bcm2835, à la fois avec les distributions basées sur Debian et Arch. Je n'ai aucun problème avec exactement la même configuration sur mon ordinateur de bureau avec une puce audio Intel. Le problème n'existait pas avec le noyau 3.6 (mais je ne veux pas utiliser une ancienne distribution).

Aucune des solutions de contournement disponibles sur le Web (tsched = 0, désactivation de module-suspend-on-idle, ...) n'a fonctionné. Je vais enfin abandonner ce problème car je n'ai pas trouvé de solution depuis plus d'un an maintenant. Soit je m'achète un Raspberry 2, soit j'utilise mpd avec le backend ALSA, car cela fonctionne très bien.

@maxnet ce problème a-t-il été résolu? Si oui, veuillez fermer ce problème.

Je ne pense pas. Il ne fonctionne pas non plus avec Raspberry 3 (ce qui n'est pas étonnant car il utilise la même puce / pilote: snd_bcm2835).

J'ai ce problème sur mon Raspberry 3 exécutant ubuntu 16.04. Comme solution de contournement, je vais mettre un délai de 5 secondes dans mon programme, mais cela gâche le naturel de la sortie (c'est un synthétiseur vocal)

Le même problème avec mon pi3 et mon ubuntu mate 16.04 et mpd semble fantastique à moins que je ne change de volume (ce qui provoque un bégaiement ou une perte de son) perd également le son de manière aléatoire parmi d'autres problèmes.

Même problème à Rpi B (pas 2 ou 3) avec le dernier noyau (684be4bc8cc343f60fdc3240c6d55d41d0a5b56c)

Peut confirmer ce problème avec un rpi3 exécutant Linux raspberrypi 4.9.27-v7+ #997 SMP Tue May 9 19:58:37 BST 2017 armv7l GNU/Linux sur raspbian .. Pulseaudio arrête généralement de jouer entre les pistes que je lui envoie depuis mpd (depuis un autre hôte via le réseau). Lorsque vous essayez de lire de l'audio flac 24 bits via mpd pour pulser, il ne joue que 2 secondes et se fige.

Confirmation du problème sur rpi3 exécutant 4.9.30-v7+ . Le remplissage de la liste de lecture mpds et le démarrage de la lecture fonctionneront généralement jusqu'à la fin de la liste de lecture, mais le changement manuel de pistes, l'arrêt et le redémarrage arrêteront la sortie audio de fonctionner, jusqu'à ce que je redémarre 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"
}

Avoir le même comportement problématique que celui décrit par @flittermice : déçu:
Le système est RPi2 exécutant une nouvelle installation de Raspbian Stretch (9.1) avec pulseaudio v10.0-1 + deb9u1, noyau 4.9.59+
J'ai lu des articles / tutoriels / threads connexes, mais la lecture MPD se bloque comme décrit ci-dessus, jusqu'à ce que je tue et redémarre pulseaudio.

Quelqu'un a-t-il encore trouvé une solution à cela? : cross_fingers:: sourire:

J'ai trouvé quelque chose d'intéressant (peut-être):
Lorsque pulseaudio se bloque (comme décrit ci-dessus), émettre une commande "paplay" deux fois (!) Reprend la lecture audio:
$ paplay /usr/share/sounds/alsa/Front_Center.wav

• La 1ère fois, la commande paplay expire (ou peut être interrompue par Ctrl + C)
• La deuxième fois que la commande paplay fonctionne, et maintenant le son du MPD est repris.

Fonctionne pendant une durée aléatoire, puis revient au comportement de

J'ai débogué plus loin dans ce problème, et j'ai trouvé que l'utilisation par Pulseaudio d'une fonction ésotérique ALSA appelée "rembobinage" est à l'origine de ce problème.
Malheureusement, il n'existe aucune option de configuration pour empêcher PA d'utiliser cette fonctionnalité.
Cette branche le désactive définitivement dans le code source: https://github.com/strfry/pulseaudio/tree/no_rewind
Si vous pouvez le construire et l'installer sur votre système, veuillez vérifier si cela résout votre problème.

J'ai débogué plus loin dans ce problème et j'ai trouvé que l'utilisation par Pulseaudio d'une fonctionnalité ésotérique ALSA
appelé "rembobinage" est à l'origine de ce problème.
Malheureusement, il n'existe aucune option de configuration pour empêcher PA d'utiliser cette fonctionnalité.

Mais Pulse peut-il fonctionner correctement si vous supprimez cette fonctionnalité?

Gardez à l'esprit qu'une partie des fonctionnalités qu'il offre en tant que serveur audio consiste à mélanger un son qui peut provenir de plusieurs applications ensemble.
Et je peux imaginer que si vous voulez pouvoir laisser de nouvelles applications ajouter instantanément des sons au mixage, vous avez besoin d'un moyen de supprimer une partie du tampon existant.
Sinon, vous ne pouvez ajouter un nouveau son qu'à la fin de la mémoire tampon, et aura un décalage, ce que l'application ne peut pas attendre. Et ce qui peut poser problème à certaines fins (par exemple, vidéo avec son)

@maxnet Un correctif approprié (le mien ne l'est pas) fixerait la latence à une valeur plutôt faible, ce qui élimine le besoin de rembobinage, au prix d'une charge CPU / consommation d'énergie légèrement plus élevée.
Cela fonctionne bien pour mon application à faible latence, pour jouer de la musique avec MPD, il peut être un peu ennuyeux de ne pas avoir de rembobinage (sans patcher PA pour ne faire que des tampons à faible latence).

Avoir toujours une faible latence, impliquerait l'utilisation de minuscules tampons.
Ce qui ne me semble pas idéal non plus.

Je dirais qu'un correctif approprié serait dans le module du noyau ...

@strfry : la relation avec le rembobinage ALSA semble raisonnable. Lorsque pulseaudio devient "malheureux", il se termine généralement par cette ligne:

D: [alsa-sink-bcm2835 ALSA] source.c: Traitement du rembobinage ...

Cependant, je suis quelque peu d'accord avec @maxnet , et il y a probablement une raison pour qu'ALSA fasse cela en premier lieu ...: wink:

Est-ce uniquement non fonctionnel sur le Raspberry Pi ou un problème général de pulseaudio + ALSA?
Étant toujours un problème depuis plus de 3 ans maintenant, devons-nous le signaler aux développeurs de pulseaudio / ALSA plutôt qu'ici?

@ pjotrek-b Elle n'est pas fonctionnelle uniquement avec la «carte» son intégrée de Raspberry PI. Nous utilisons avec succès pulseaudio comme serveur de son réseau avec une carte son USB pendant plusieurs mois sans problèmes.

Je peux confirmer la déclaration de @jekhor .
La même configuration fonctionne parfaitement avec ma carte son USB (snd_usb_audio) sur le Raspberry Pi.

Comme l'indique le fichier journal: "E: [alsa-sink-bcm2835 ALSA] alsa-sink.c: Il s'agit probablement d'un bogue dans le pilote ALSA '(null)'. Veuillez signaler ce problème aux développeurs ALSA.". Est-ce que quelqu'un sait comment faire ça?

@jekhor : Merci d'avoir

Ce qui est maintenant déroutant, c'est que j'ai toujours pensé que c'était comme ça:
application > pulseaudio > ALSA > driver > hardware

Si tel est le cas, comment les mêmes applications qui ont ce problème peuvent-elles fonctionner parfaitement lorsqu'elles utilisent directement ALSA?
application > ALSA > driver > hardware

Maintenant, si ce problème est spécifique à la carte son / puce intégrée de RPi, comment se fait-il que ces problèmes n'apparaissent pas non plus avec une utilisation uniquement alsa? :confus:

@strfry : J'ai trouvé un article assez détaillé sur "Rewinding" dans la documentation de pulseaudio .

J'en ai lu des parties et cela ne me semble plus "ésotérique" maintenant. Depuis que vous avez regardé son code: avez-vous des idées sur ce qui pourrait faire en sorte que pulseaudio "reste bloqué"?
Comme je l'ai mentionné ci-dessus, exécuter "paplay" deux fois semble lui donner un "coup de pouce" pour se remettre au travail ...: sourire:

@ pjotrek-b Bien sûr, cela a du sens étant donné les objectifs de conception de Pulseaudio. Il est "ésotérique" dans le sens où 99% des applications ALSA normales n'utiliseront jamais le rembobinage, et donc déclencheront un chemin moins testé dans le pilote ALSA. Malheureusement, Pulseaudio n'a pas d'option pour désactiver l'utilisation de cette fonctionnalité potentiellement boguée (comme d'autres, par exemple la planification basée sur la minuterie).
Je n'ai pas débogué les détails exacts, mais fondamentalement Pulseaudio reste bloqué dans une boucle sans fin, car ALSA ne parvient pas à signaler correctement le moment où il est temps d'écrire à nouveau des données audio sur l'appareil.
Malgré les possibilités de contourner cela du côté de Pulseaudio, il s'agit d'un bogue dans le pilote ALSA.
Je soupçonne que l'émission de nouveaux flux générera les événements que Pulseaudio attend quand il se bloque.

@flittermice Je suppose que dans ce cas, le développeur ALSA responsable est quelqu'un des développeurs du noyau Raspberry Pi qui a écrit le pilote snd_bcm2835, donc ce référentiel serait le bon endroit pour signaler cela.

Un exemple de code simple qui démontre un comportement clairement incorrect d'ALSA lors de l'utilisation de rembobinage serait probablement utile aux développeurs du noyau lorsqu'ils examinent de plus près ce bogue.

@ pjotrek-b Bien sûr, cela a du sens étant donné les objectifs de conception de Pulseaudio. Il est "ésotérique" dans le sens où 99% des applications ALSA normales n'utiliseront jamais le rembobinage, et donc déclencheront un chemin moins testé dans le pilote ALSA. Malheureusement, Pulseaudio n'a pas d'option pour désactiver l'utilisation de cette fonctionnalité potentiellement boguée (comme d'autres, par exemple la planification basée sur la minuterie).
Je n'ai pas débogué les détails exacts, mais fondamentalement Pulseaudio reste bloqué dans une boucle sans fin, car ALSA ne parvient pas à signaler correctement le moment où il est temps d'écrire à nouveau des données audio sur l'appareil.
Malgré les possibilités de contourner cela du côté de Pulseaudio, il s'agit d'un bogue dans le pilote ALSA.
Je soupçonne que l'émission de nouveaux flux générera les événements que Pulseaudio attend quand il se bloque.

@flittermice Je suppose que dans ce cas, le développeur ALSA responsable est quelqu'un des développeurs du noyau Raspberry Pi qui a écrit le pilote snd_bcm2835, donc ce référentiel serait le bon endroit pour signaler cela.

Un exemple de code simple qui démontre un comportement clairement incorrect d'ALSA lors de l'utilisation de rembobinage serait probablement utile aux développeurs du noyau lorsqu'ils examinent de plus près ce bogue.

Si tel est le cas, comment les mêmes applications qui ont ce problème peuvent-elles fonctionner parfaitement lorsqu'elles utilisent directement ALSA?

Les applications utilisant directement ALSA n'ont généralement pas besoin d'utiliser le rembobinage.
Ils savent exactement quel son ils veulent faire jouer dans les secondes à venir et l'envoient à l'appareil audio.

Il est utilisé dans les situations où il y a un changement de plan.
Si Pulse a déjà envoyé l'audio pendant les 2 secondes suivantes à l'appareil, et que soudain un client Pulse différent se connecte et souhaite également lire le son - sans avoir à attendre que ces 2 secondes soient terminées en premier - il doit indiquer le son périphérique pour supprimer le tampon précédent et le remplacer par de nouvelles données contenant le son supplémentaire.

Bien sûr, si vous utilisez de minuscules tampons qui contiennent des millisecondes au lieu de secondes d'audio, vous pouvez vous passer de rembobinage.
Cependant, je ne pense pas que ce soit préféré.
Sous Linux, il n'y a aucune garantie sur la quantité de temps processeur qu'une application obtient, ni sur le fait qu'elle soit répartie uniformément, ce n'est pas un système d'exploitation en temps réel.
Si une autre application en utilise beaucoup et que Pulse n'obtient pas suffisamment de temps pour garder ce minuscule tampon rempli à tout moment, elle sera insuffisante et votre son va bégayer.

Comme je l'ai mentionné ci-dessus, exécuter "paplay" deux fois semble lui donner un "coup de pouce" pour se remettre au travail ...: sourire:

Pulse Audio ferme également la connexion au périphérique audio 5 secondes après la déconnexion du dernier client qui l'utilise, si aucun autre client ne se connecte pendant cette période.
Et le rouvre la prochaine fois qu'un client veut l'utiliser.
Donc, s'il y a suffisamment de temps entre vos commandes, cela pourrait aussi être la raison pour laquelle cela fonctionne à nouveau.

@strfry et @maxnet :
Merci beaucoup pour ces réponses détaillées!

Est-ce que quelqu'un sait si c'est toujours un problème dans le dernier Raspbian (avec le noyau 4.14.y)?

Ce problème sera clos dans les 30 jours à moins que d'autres interactions ne soient publiées. Si vous souhaitez que ce problème reste ouvert, veuillez ajouter un commentaire. Un problème fermé peut être rouvert sur demande.

Je vérifierais, mais je n'ai actuellement pas le temps de le tester ...: déçu:
Juste au cas où: puis-je le rouvrir si je le teste après 30 jours et que cela pose toujours un problème?

Bien que je sois à peu près sûr qu'il n'y a pas eu d'améliorations, je ne peux pas beaucoup contribuer à ce bug particulier. J'ai acheté une carte son USB externe avec un chipset PCM2704 et je suis maintenant satisfait du pilote snd_usb_audio.
Utiliser la sortie HDMI du raspi aurait été une bonne option, mais mon raspi refuserait même de démarrer avec le câble HDMI branché sur l'ampli-tuner AV ... mais c'est une autre histoire.

Fermeture faute d'activité. Veuillez demander à être rouvert si vous pensez que ce problème est toujours d'actualité.

Peut confirmer que cela arrive à mon Rasp Pi 3
J'exécute ArchARM avec la version 4.14.69 du noyau

Peut confirmer que cela se produit toujours sur mon RPI3:

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

En essayant d'utiliser mpd avec pulseaudio, j'obtiens:

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.

Y a-t-il une chance que nous puissions rouvrir ce numéro?

Peut confirmer que cela arrive à mon Rasp Pi 3
J'exécute ArchARM avec la version 4.14.69 du noyau
C'était à cause d'une mauvaise autorisation, je l'ai fait fonctionner.

@ l4rzy : vous nous

@flittermice : Oups, j'ai mal compris la situation depuis que j'ai commenté cela pendant des mois. Ce n'était pas une question d'autorisations.
J'ai essayé de configurer mon Raspberry Pi 3 pour un serveur audio Pulse du réseau local, cela fonctionnait de manière transparente, mais après un certain temps sans rien lire, le serveur audio Pulse s'est automatiquement arrêté. Plus tard, j'installe mpd pour lire de la musique à partir de SoundCloud, qui ouvre toujours une connexion à Pulse et la maintient en marche. Pas une mauvaise solution de contournement, je pense.

@ l4rzy : Travailler autour est la voie à suivre :-)

BTW: Avez-vous déjà essayé de ne pas charger "module-suspend-on-idle" dans default.pa?

module de charge module suspendu au repos

@flittermice j'ai essayé. Ça n'aide pas.

Pulseaudio ne fonctionne toujours pas avec snd_bcm2835. Pouvez-vous rouvrir ce numéro, s'il vous plaît?

Je peux confirmer que cela ne fonctionne pas non plus pour moi. J'ai testé différents codes et options de compilation et je n'ai pas pu le faire fonctionner. Je suis sur ArchLinux ARM et tous les logiciels les plus récents. Je suis heureux d'aider au débogage si possible.

Pour moi, autant que je sache, le problème vient de la taille de la mémoire tampon signalée par le module bcm2835_alsa. Le tampon audio signalé à l'impulsion est de 8816 bits, ou juste assez pour environ 1,56 ms d'audio à partir d'un flux réseau. Je ne suis pas assez geek du matériel pour trouver les spécifications, mais quelque chose semble bizarre ici. Selon ALSA lui-même (c'est-à-dire pas le module d'impulsions), la taille du tampon est beaucoup plus logique de 131072 bits. Si je devais deviner, pulse pense qu'il ne peut pas garder le tampon plein pour la carte et essaie de rembobiner parce qu'on lui dit qu'il y a une limite logicielle de 8816 bits ... mais peut-être que je suis loin de la base ici.

Juste eu le même problème (c'est vraiment ennuyeux), @ JamesH65 pourriez-vous le rouvrir pour le suivre davantage?

Hmmm ... Je ne peux pas reproduire cela avec Raspberry Pi 3 B v1.2 et le dernier noyau 4.19.34 (mis à jour par rpi-update à https://github.com/Hexxeh/rpi-firmware/commit/99c274691c07480762dcda91a0ebfe3c4f519307). Je ne sais pas pourquoi, le pilote ne semble pas changé depuis 2016. Peut-être que certains changements de firmware VC?

Salut, sur Raspberry Pi 4 B v1.1, le noyau 5.3.0-1014 a le même problème avec la décoloration du son avec pulseaudio v13.0. Le son est perdu si une sortie stéréo est sélectionnée dans pavucontrol. y-a-t'il une solution?

@acegallagher :

Le tampon audio signalé à l'impulsion est de 8816 bits, ou juste assez pour environ 1,56 ms d'audio à partir d'un flux réseau.

Je pense que c'est parce que PulseAudio détecte les puits comme Mono par défaut (à cause de ce problème ), et la taille de la mémoire tampon par défaut pour ceux-ci est inférieure.
Essayez de mettre à jour le fichier de configuration du profil par défaut de PA afin que des récepteurs stéréo soient créés à la place, car cela obligera PA à créer des puits avec device.buffering.buffer_size = "17632" , ce qui semble mieux!

@ olevenets2

Salut, sur Raspberry Pi 4 B v1.1, le noyau 5.3.0-1014 a le même problème avec la décoloration du son avec pulseaudio v13.0. Le son est perdu si une sortie stéréo est sélectionnée dans pavucontrol. y-a-t'il une solution?

Assurez-vous de mettre à load-module module-udev-detect et non load-module module-alsa-sink dans votre /etc/pulse/default.pa .