[pulseaudio-discuss] Underrunning null sink

[Travis Brown]

Hi,

I am using Pulseaudio to send data from an application to 3 different outputs simultaneously: HDMI, analog output and a G.722 RTP stream. To accomplish this, I set up a null sink call g722 using the following setting in be default.pa:

load-module module-null-sink sink_name=g722 sink_properties=device.description=“g722”
load-module module-combine-sink sink_name=combined slaves=alsa_output.pci-0000_00_03.0.hdmi-stereo-extra1,alsa_output.pci-0000_00_1b.0.analog-stereo,g722

It actually works pretty great. I use ffmpeg to pull data from the g722 monitor and transcode it and send it out via multicast to the phones/speakers.

/usr/bin/ffmpeg -re -f pulse -i g722.monitor -filter_complex aresample=16000,asetnsamples=n=160 -vn -ac 1 -acodec g722 -f rtp udp://224.0.2.60:50000 <udp://224.0.2.60:50000>

The issue I am having is that ffmpeg underruns most of the time UNTIL I start pavucontrol. Starting pavucontrol makes things behave beautifully. ffmpeg gets a constant stream of data and the audio sounds great. What I cannot figure out is what pavucontrol is doing to make things better. It must be setting up something for the VU meters, but I am not sure that would actually improve things, or why it would.

Thanks,
Travis

[Travis Brown]

After playing around with this for about 6 hours, I found some interesting data. The latency on the g722 (since renamed to ip_mcast) null-sink hovers around 20mS when I have pavucontrol running, and around 600mS when I don’t have it running. Since G722 requires pretty consistent 20Ms packets, this is certainly the problem. The max request size is also obviously different. Is it possible to adjust the max request size? That is the only thin gI can think of that would really impact the latency here.

Thanks again,
Travis

Good:
index: 2
name: <ip_mcast>
driver: <module-null-sink.c>
flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
state: IDLE
suspend cause:
priority: 1000
volume: mono: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 20.63 ms
max request: 1 KiB
max rewind: 1 KiB
monitor source: 3
sample spec: s16le 1ch 16000Hz
channel map: mono
Mono
used by: 0
linked by: 1
configured latency: 40.00 ms; range is 0.50 .. 2000.00 ms
module: 4
properties:
device.description = "ip_mcast"
device.class = "abstract"
device.icon_name = "audio-card”

Bad:
index: 2
name: <ip_mcast>
driver: <module-null-sink.c>
flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
state: IDLE
suspend cause:
priority: 1000
volume: mono: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 657.77 ms
max request: 62 KiB
max rewind: 62 KiB
monitor source: 3
sample spec: s16le 1ch 16000Hz
channel map: mono
Mono
used by: 0
linked by: 0
configured latency: 2000.00 ms; range is 0.50 .. 2000.00 ms
module: 4
properties:
device.description = "ip_mcast"
device.class = "abstract"
device.icon_name = "audio-card"

Post by Travis Brown
Hi,
load-module module-null-sink sink_name=g722 sink_properties=device.description=“g722”
load-module module-combine-sink sink_name=combined slaves=alsa_output.pci-0000_00_03.0.hdmi-stereo-extra1,alsa_output.pci-0000_00_1b.0.analog-stereo,g722
It actually works pretty great. I use ffmpeg to pull data from the g722 monitor and transcode it and send it out via multicast to the phones/speakers.
/usr/bin/ffmpeg -re -f pulse -i g722.monitor -filter_complex aresample=16000,asetnsamples=n=160 -vn -ac 1 -acodec g722 -f rtp udp://224.0.2.60:50000 <udp://224.0.2.60:50000>
The issue I am having is that ffmpeg underruns most of the time UNTIL I start pavucontrol. Starting pavucontrol makes things behave beautifully. ffmpeg gets a constant stream of data and the audio sounds great. What I cannot figure out is what pavucontrol is doing to make things better. It must be setting up something for the VU meters, but I am not sure that would actually improve things, or why it would.
Thanks,
Travis

[Travis Brown]

After digging into this a bit more, it appears that the latency on the null sink is all over the place when pavucontrol is NOT running. For example, here is a case when it is not running:

index: 2
name: <ip_mcast>
driver: <module-null-sink.c>
flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
state: IDLE
suspend cause:
priority: 1000
volume: mono: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 1147.05 ms
max request: 62 KiB
max rewind: 62 KiB
monitor source: 3
sample spec: s16le 1ch 16000Hz
channel map: mono
Mono
used by: 0
linked by: 0
configured latency: 2000.00 ms; range is 0.50 .. 2000.00 ms
module: 4
properties:
device.description = "ip_mcast"
device.class = "abstract"
device.icon_name = "audio-card”


When pavucontrol is running, I get much more reasonable latencies (20-30mS).

index: 2
name: <ip_mcast>
driver: <module-null-sink.c>
flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
state: IDLE
suspend cause:
priority: 1000
volume: mono: 65536 / 100% / 0.00 dB
balance 0.00
base volume: 65536 / 100% / 0.00 dB
volume steps: 65537
muted: no
current latency: 20.63 ms
max request: 1 KiB
max rewind: 1 KiB
monitor source: 3
sample spec: s16le 1ch 16000Hz
channel map: mono
Mono
used by: 0
linked by: 1
configured latency: 40.00 ms; range is 0.50 .. 2000.00 ms
module: 4
properties:
device.description = "ip_mcast"
device.class = “abstract"


The biggest thing I notices is obviously the max request size. pavucontrol probably sets that to 1 KiB and restores it to 62 KiB when it exists. Is this something that can be changed from a config file?

Thanks again,
Travis