Balbuzie del lavandino PulseAudio

12

Ho installato raspbian sul mio Pi e configurato un sink PulseAudio con l'intenzione di trasmettere in streaming tutto l'audio dal mio desktop a un Pi, guidando gli altoparlanti.

Ho seguito questa bella descrizione: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=38&t=11124

Inizialmente, questo sembrava funzionare senza problemi. Tuttavia, l'audio inviato dal desktop sta costantemente balbettando sul Pi, come se ci fossero dei buffer underrun costanti con solo alcuni campioni mancanti nel mezzo.

Ho passato l'intera giornata a cercare la causa, ma senza successo. L'impostazione di base è:

connessione LAN cablata
raspbian pi più recente (26 settembre 2013) con gli ultimi aggiornamenti del firmware
PulseAudio 2.0 su entrambi i lati (desktop Ubuntu)
Riproduzione tramite mplayer, totem, ffplay
trasmissione di rete tramite module-native-protocol-tcp

Questo è quello che ho provato:

La riproduzione audio direttamente sul Pi funziona perfettamente.
Lo streaming su altri computer (desktop) funziona correttamente.
L'invio di audio con una connessione diretta (specificando $ PULSE_SERVER) funziona abbastanza bene con una balbuzie molto ridotta, ma è ancora soggetto al Problema-2 (vedi sotto)
L'invio di audio tramite il tunneling PulseAudio desktop garantisce una balbuzie costante
L'aumento delle priorità / programmazione in tempo reale ... non ha aiutato
Fissare la frequenza di campionamento a 48 kHz ... non ha aiutato
L'impostazione dell'algoritmo di ricampionamento su "banale" ... non ha aiutato
La regolazione di default-fragments / fragment-size ... non ha aiutato

Non riesco a trovare alcuna indicazione di un problema nei registri PulseAudio (mostrati da quando ho iniziato la riproduzione):

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 ...

Problema 2: come detto sopra, posso ottenere un audio abbastanza buono con una connessione diretta. Tuttavia, dopo alcuni salti all'interno dello stream (usando mplayer), il server PulseAudio si blocca e non riproduce alcun audio. A volte può essere ripristinato riavviando mplayer. A volte si blocca così tanto che è necessario riavviare PulseAudio. A volte si blocca anche quando cambio solo il livello del volume.

Secondo i documenti PulseAudio, il vantaggio di una connessione diretta su una connessione sintonizzata è di avere un migliore controllo del buffering, il che sembra indicare perché ottengo un buon audio con la connessione diretta: http://www.freedesktop.org/wiki/Software / PulseAudio / Documentazione / utente / rete /

Sono senza idee ora. Cosa potrebbe causare la balbuzie e il problema 2? Anche un'idea su come procedere al debug sarebbe apprezzata.

networking audio

— farindk
fonte

Come hai riprodotto l'audio direttamente? Non ho avuto problemi con Aplay, ma Paplay balbetta ed echo terribilmente.

— John La Rooy,

Ho usato mplayer, totem, madplay, ... Ma il fatto che diversi giocatori si comportino in modo diverso supporta la mia ipotesi che sembra essere un problema software con il buffering dei dati. Alcuni giocatori spingono più dati in tempo reale rispetto ad altri.

— Farindk,

Ho problemi a suonare solo le onde sinusoidali . Penso che dovrò risolverlo prima di poter provare lo streaming sulla LAN.

— John La Rooy,

6

tsched_buffer_sizeed tsched_buffer_watermarkerano le impostazioni che lo hanno fatto funzionare per me.

Eseguo PulseAudio come istanza di sistema, quindi la configurazione è attiva /etc/pulse/system.pa. Se invece si utilizza un'istanza di sessione, la configurazione sarà attiva /etc/pulse/default.pa.

Questo è il valore predefinito:

### 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

L'ho sostituito con questo: (cioè, l'ho commentato)

### 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

Quindi ho aggiunto la seguente riga:

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

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

— Phil
fonte

Buon punto. Ci ho provato, ma non ha aiutato. Anche con dimensioni del buffer molto più grandi. L'invio di audio tramite una connessione diretta impostando PULSE_SERVER su Pi fornisce un audio pulito, ma il semplice cambiamento del volume alla fine bloccherà la connessione. L'audio tramite tunneling dà ancora la balbuzie. La mia ipotesi è che questo è davvero un problema PulseAudio, perché con quelle dimensioni di buffer di grandi dimensioni (ho usato 4 MB), si dovrebbe vedere che l'audio viene decodificato in anticipo all'inizio di un file. Ma non è. Quindi ci deve essere qualcosa che rallenta la ricarica.

— Farindk,

Incontrare lo stesso tipo di problemi. Nel mio caso particolare, PULSE_SERVER + mplayer funziona come un incantesimo, mentre PULSE_SERVER + clementine (che credo stia usando gstreamer) balbetta terribilmente. Qualche idea su cosa differisca tra i due?

— Jonathan Protzenko,

@Protzenko: La mia ipotesi senza guardare a nessuna fonte è che mplayer potrebbe spingere i dati fino a quando PulseAudio non sta bloccando, mentre gstreamer potrebbe inviare dati con clock in base a un riferimento in tempo reale. Ciò significherebbe che i buffer sono molto più pieni nel primo caso e, di conseguenza, c'è un ritardo maggiore.

— Farindk,

Sto vedendo lo stesso problema PULSE_SERVER + ffmpeg bene, PULSE_SERVER + persiane

— mpd e sottotitoli

3

Il punto principale è che è necessario utilizzare module-tunnel-sink-new, ma è anche necessario apportare alcune altre modifiche per ottenere audio di rete privo di scatti sul raspberry pi 1.

Esegui pulseaudio sul raspberry pi con priorità in tempo reale:

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

Usiamo il termine mittente per indicare il computer che invia lo stream al tuo lampone pi.

Set default-fragmentse default-fragment-size-msecin daemon.confal mittente a questi valori:

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

Utilizzare module-tunnel-sink-newemettendo questo comando al mittente (il nome host di raspberry pi è RP1 e si dispone di mDNS che funziona sulla rete locale. Altrimenti, utilizzare l'indirizzo IP di raspberry pi).

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

Con queste impostazioni ottengo un audio privo di balbuzie da un raspberrypi 1 su una rete wireless a 54 Mbps (nella mia configurazione, il mittente utilizza Ethernet e RP1 utilizza Wlan). In realtà, funziona anche quando mittente e raspberrypi utilizzano wlan, almeno se non ci sono altri dispositivi sulla rete wireless.

— Hans Ekbrand
fonte

Funziona benissimo finora. Ho scoperto che per il mio Pi3 (con un debian / software un po 'più recente) ho dovuto cambiare qualcos'altro per poter raccogliere le impostazioni dei "frammenti predefiniti". (vale a dire qualcosa di impostazione tsched=0, vedi wiki.archlinux.org/index.php/PulseAudio/… )

— rien333

Se continui a soffrire di balbuzie, l'arch wiki consiglia anche di passare al protocollo di streaming rtp

— rien333

1

hai controllato questa pagina:

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

IMPOSTAZIONI DI FRAMMENTO PREDEFINITO

   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
fonte

Sì, ci ho provato, ma non ha aiutato. Come ho già detto, la riproduzione audio sul dispositivo stesso funziona bene. Presumo che si tratti di un problema di protocollo di rete con il tunneling PulseAudio. Anche il protocollo di connessione diretta funziona bene. Ora sono passato a un semplice hardware di streaming Bluetooth, affidabile e che utilizza RPi per altre cose.

— Farindk,

1

Per eliminare problemi di balbuzie o timeout, provare un downgrade FW:

sudo rpi-update eeb2e51c3e08cd5efa4246aa8dc54a09b25ada12

— user13034
fonte

1

ATTENZIONE Prestare attenzione a ciò che un rpi-updateuso in questo modo può fare al proprio sistema.

— earthmeLon

@earthmeLon potresti almeno darci un riferimento o provare a informarci cosa rpi-updatepuò fare in questo modo l'uso dei nostri sistemi ...

— user11171

Assicurati di leggere il manuale e fai qualche ricerca per capire come questo influisce sul tuo sistema e su eventuali pericoli.

— earthmeLon

0

Ho riconosciuto che questo problema potrebbe essere correlato alla versione del kernel. Dopo l'aggiornamento da 3.6.11 a 3.12.0 ho ricevuto costantemente questi underrun. Un downgrade al 3.6.11 ha risolto il problema per me.

— Manuel Faux
fonte

0

Ho letto questa pagina un paio di volte ... Sono stato anche frustrato dalla balbuzie della combinazione rete RaspberryPi-pulseaudio-rete. Ho cercato un po 'di più e ho trovato una pagina in cui ho trovato una parte della soluzione:

=> Disabilita module-suspend-on-idle in default.pa (o system.pa).

Ecco, la balbuzie è scomparsa!

Ora l'unico problema è che dopo un po '(da 10 a 20 secondi) la riproduzione si blocca: - /

Eventuali suggerimenti?

— Jørn Christensen
fonte