PulseAudio évier bégayant

12

J'ai installé raspbian sur mon Pi et configuré un récepteur PulseAudio avec l'intention de diffuser tout l'audio de mon bureau vers un Pi, en pilotant les haut-parleurs.

J'ai suivi cette belle description: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

Au début, cela semblait fonctionner sans problème. Cependant, l'audio envoyé depuis le bureau bégaie constamment sur le Pi, comme s'il y avait des sous-exécutions de tampon constantes avec seulement quelques échantillons manquants entre les deux.

J'ai passé toute la journée à essayer de trouver la cause, mais en vain. La configuration de base est la suivante:

connexion LAN filaire
dernière raspbian pi (26 sept. 2013) avec les dernières mises à jour du firmware
PulseAudio 2.0 des deux côtés (bureau Ubuntu)
Lecture via mplayer, totem, ffplay
transmission réseau via module-native-protocol-tcp

Voici ce que j'ai essayé:

La lecture audio directement sur le Pi fonctionne parfaitement.
La diffusion sur d'autres ordinateurs (de bureau) fonctionne correctement.
L'envoi audio avec une connexion directe (en spécifiant $ PULSE_SERVER) fonctionne assez bien avec très peu de bégaiement, mais toujours sujet au problème 2 (voir ci-dessous)
L'envoi audio via le tunnel PulseAudio de bureau permet un bégaiement constant
Augmentation des priorités / planification en temps réel ... n'a pas aidé
Fixer le taux d'échantillonnage à 48 kHz ... n'a pas aidé
Définir l'algorithme de rééchantillonnage sur "trivial" ... n'a pas aidé
L'ajustement des fragments par défaut / taille des fragments ... n'a pas aidé

Je ne trouve aucune indication d'un problème dans les journaux PulseAudio (affichés depuis le début de la lecture):

D: [alsa-sink] protocol-native.c: Requesting rewind due to end of underrun.
D: [alsa-sink] sink-input.c: Requesting rewind due to uncorking
D: [pulseaudio] sink.c: Suspend cause of sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo is 0x0000, resuming
I: [alsa-sink] alsa-sink.c: Trying resume...
I: [alsa-sink] alsa-util.c: cannot disable ALSA period wakeups
D: [alsa-sink] alsa-util.c: Maximum hw buffer size is 341 ms
D: [alsa-sink] alsa-util.c: Set buffer size first (to 16384 samples),  period size second (to 16384 samples).
I: [alsa-sink] alsa-util.c: ALSA period wakeups were not disabled
D: [alsa-sink] alsa-sink.c: Latency set to 25.00ms
D: [alsa-sink] alsa-sink.c: hwbuf_unused=60736
D: [alsa-sink] alsa-sink.c: setting avail_min=15665
I: [alsa-sink] alsa-sink.c: Time scheduling watermark is 15.00ms
I: [alsa-sink] alsa-sink.c: Resumed successfully...
I: [alsa-sink] alsa-sink.c: Starting playback.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [pulseaudio] module-suspend-on-idle.c: Sink alsa_output.platform-bcm2835_AUD0.0.analog-stereo becomes busy.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] alsa-sink.c: Cutting sleep time for the initial iterations by half.
D: [alsa-sink] ratelimit.c: 115 events suppressed
D: [alsa-sink] alsa-sink.c: Wakeup from ALSA!
... no more output, but stuttering continues ...

Problème 2: comme indiqué ci-dessus, je peux obtenir un son tout à fait correct avec une connexion directe. Cependant, après quelques sauts dans le flux (à l'aide de mplayer), le serveur PulseAudio se bloque et ne lit aucun son du tout. Parfois, il peut être relancé en redémarrant mplayer. Parfois, il se bloque si mal que PulseAudio doit être redémarré. Parfois, il se bloque même lorsque je ne modifie que le volume.

Selon les documents PulseAudio, l'avantage d'une connexion directe sur une connexion tunnelée est d'avoir un meilleur contrôle de la mise en mémoire tampon, ce qui semble indiquer pourquoi j'obtiens un bon son avec la connexion directe: http://www.freedesktop.org/wiki/Software / PulseAudio / Documentation / Utilisateur / Réseau /

Je suis à court d'idées maintenant. Qu'est-ce qui pourrait causer le bégaiement et le problème 2? Une simple idée de la façon de procéder au débogage serait également appréciée.

networking audio

— farindk
source

Comment avez-vous joué l'audio directement? Je n'ai eu aucun problème avec aplay, mais paplay bégaie et résonne terriblement.

— John La Rooy

J'ai utilisé mplayer, totem, madplay, ... Mais le fait que les différents joueurs se comportent différemment supporte ma supposition que cela semble être un problème logiciel avec la mise en mémoire tampon des données. Certains joueurs poussent plus de données en temps réel que d'autres.

— farindk

J'ai du mal à jouer des ondes sinusoïdales . Je pense que je devrai résoudre ce problème avant de pouvoir essayer de diffuser sur le LAN.

— John La Rooy

6

tsched_buffer_sizeet tsched_buffer_watermarkétaient les paramètres qui l'ont fait fonctionner pour moi.

J'exécute mon PulseAudio en tant qu'instance système, donc la configuration est là /etc/pulse/system.pa. Si vous utilisez une instance de session à la place, la configuration sera alors disponible /etc/pulse/default.pa.

C'est la valeur par défaut:

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
load-module module-detect
.endif

Je l'ai remplacé par ceci: (ie, je l'ai commenté)

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
#load-module module-udev-detect
.else
### Use the static hardware detection module (for systems that lack udev/hal  support)
#load-module module-detect
.endif

J'ai ensuite ajouté la ligne suivante:

load-module module-alsa-card device_id=0 tsched=true tsched_buffer_size=1048576 tsched_buffer_watermark=262144

Voir http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index6h3

— Phil
source

Bon point. J'ai essayé, mais cela n'a pas aidé. Même avec des tailles de tampon beaucoup plus grandes. L'envoi d'audio via une connexion directe en définissant PULSE_SERVER sur le Pi donne un son clair, mais le simple changement de volume finira par geler la connexion. L'audio via tunneling donne toujours le bégaiement. Je suppose que c'est vraiment un problème PulseAudio, car avec cette grande taille de tampon (j'ai utilisé 4 Mo), il faut voir que l'audio est décodé bien à l'avance au début d'un fichier. Mais ce n'est pas. Il doit donc y avoir quelque chose qui ralentit la recharge.

— farindk

Rencontrant le même genre de problèmes. Dans mon cas particulier, PULSE_SERVER + mplayer fonctionne comme un charme, tandis que PULSE_SERVER + clémentine (qui, je crois, utilise gstreamer) bégaie terriblement. Une idée de ce qui diffère entre les deux?

— Jonathan Protzenko

@Protzenko: Ma supposition sans regarder aucune source est que mplayer pourrait pousser les données jusqu'à ce que PulseAudio se bloque, tandis que gstreamer pourrait envoyer des données cadencées par une référence en temps réel. Cela signifierait que les tampons sont beaucoup plus remplis dans le premier cas, et par conséquent, il y a un retard plus important.

— farindk

Je vois le même problème PULSE_SERVER + ffmpeg bien, volets PULSE_SERVER + mpd et sous

— exécutions

3

Le point principal est que vous devez utiliser module-tunnel-sink-new, mais vous devez également apporter quelques autres modifications pour obtenir un audio réseau sans bégaiement sur le raspberry pi 1.

Exécutez pulseaudio sur le Raspberry Pi avec une priorité en temps réel:

pulseaudio --start --high-priority=yes --realtime=yes

Utilisons le terme expéditeur pour désigner l'ordinateur qui envoie le flux à votre Raspberry Pi.

Définir default-fragmentset default-fragment-size-msecdans daemon.confà l' expéditeur à ces valeurs:

default-fragments = 8
default-fragment-size-msec = 12

Utilisez-la module-tunnel-sink-newen lançant cette commande à l' expéditeur (en supposant que le nom d'hôte de votre raspberry pi est RP1 et que vous avez mDNS travaillant sur votre réseau local. Sinon, utilisez simplement l'adresse IP de votre raspberry pi).

pactl load-module module-tunnel-sink-new server=RP1.local

Avec ces paramètres, j'obtiens un son sans bégaiement à partir d'un raspberrypi 1 sur un réseau sans fil fonctionnant à 54 Mbps (dans ma configuration, l' expéditeur utilise Ethernet et RP1 utilise WLAN). En fait, cela fonctionne même lorsque l' expéditeur et le raspberrypi utilisent wlan, du moins s'il n'y a pas d'autres appareils sur le réseau sans fil.

— Hans Ekbrand
source

Fonctionne très bien jusqu'à présent. J'ai trouvé que pour mon Pi3 (avec un debian / logiciel quelque peu plus récent), je devais changer autre chose pour que les paramètres des "fragments par défaut" soient récupérés. (à savoir, quelque chose de réglage tsched=0, voir wiki.archlinux.org/index.php/PulseAudio/… )

— rien333

Si vous rencontrez toujours du bégaiement, le wiki arch recommande également de passer au protocole de streaming rtp

— rien333

1

avez-vous consulté cette page:

http://manpages.ubuntu.com/manpages/lucid/man5/pulse-daemon.conf.5.html

RÉGLAGES PAR DÉFAUT PAR DÉFAUT

   Some hardware drivers  require  the  hardware  playback  buffer  to  be
   subdivided  into  several  fragments.  It  is  possible to change these
   buffer metrics for machines with high  scheduling  latencies.  Not  all
   possible  values  that  may  be  configured  here  are available in all
   hardware. The driver will to find the nearest setting supported. Modern
   drivers that support timer-based scheduling ignore these options.

   default-fragments= The default number of fragments. Defaults to 4.

   default-fragment-size-msec=The  duration of a single fragment. Defaults
   to 25ms (i.e. the total buffer is thus 100ms long).

— Alter Schwede
source

Oui, j'ai essayé, mais cela n'a pas aidé. Comme je l'ai mentionné, la lecture audio sur l'appareil lui-même fonctionne bien. Je suppose que c'est un problème de protocole réseau avec le tunnelage PulseAudio. Même le protocole de connexion directe fonctionne bien. Je suis maintenant passé à un simple matériel de streaming Bluetooth, qui est fiable et utilise le RPi pour d'autres choses.

— farindk

1

Pour vous débarrasser des problèmes de bégaiement ou de temporisation, essayez une rétrogradation FW:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12

— user13034
source

1

AVERTISSEMENT Soyez conscient de ce que l' rpi-updateutilisation de cette manière peut faire à votre système.

— earthmeLon

@earthmeLon vous pourriez au moins donner une référence ou essayer de nous informer de ce que l'utilisation rpi-updatede cette façon peut faire pour nos systèmes ...

— user11171

Assurez-vous de lire le manuel et de faire des recherches pour comprendre comment cela affecte votre système et les dangers potentiels.

— earthmeLon

0

J'ai reconnu que ce problème pouvait être lié à la version du noyau. Après la mise à niveau de 3.6.11 vers 3.12.0, je recevais constamment ces sous-exécutions. Un retour à 3.6.11 a résolu le problème pour moi.

— Manuel Faux
source

0

J'ai lu cette page plusieurs fois ... J'ai également été frustré par le bégaiement de la combinaison RaspberryPi-pulseaudio-network. J'ai cherché un peu plus et j'ai trouvé une page où j'ai trouvé une partie de la solution:

=> Désactiver le module-suspend-on-idle dans le default.pa (ou system.pa).

Voici, le bégaiement a disparu!

Maintenant, le seul problème est qu'après un certain temps (10 à 20 secondes), la lecture se bloque: - /

Aucune suggestion?

— Jørn Christensen
source