Pulseaudio network delays

Archive - Mycroft Project Hardware
1

Hy

My setup is looking like this:
Mycroft - Runs on a Linux computer (Lattepanda Alpha) and is connected to the LAN and has a a USB microphone
Homesound System - A soundbar is connected over HDMI to a Rpi where Pulseaudio is running as a server.

My HTPC is directly connected to a Beamer at the ceiling connected via LAN and playing th audio connected over the LAN to the RPI connected to the Soundbar. (works perfect)

Now all the sounds from Mycroft are also played over the RPI connected to the Soundbar (over the load-module module-native-protocol-tcp). However I experience a large delay of around 2 seconds.
So when I say Hy Mycroft it takes almost 3 seconds to hear the beep from the soundbar that Mycroft is listening.
How can I reduce this audio delay? Has someone a similar setup and can report how well its working?

Andy

2

Did you disable / unload the suspend on idle module?

3

you think of this part in the /etc/pulse/default.pa file: If so yes I did.

Automatically suspend sinks/sources that become idle for too long

#load-module module-suspend-on-idle

4

Could you post the content of the default.pa on the client and the server? Just wondering how you have it all setup.

Sometimes use the tunnel-sink is easier / better. Or perhaps send white noise continously might help as well.

Willing to have a look, think about it with you.

5

thx
On the “server” side so the RPi that is directly connect to the sound bar the default.pa has this additional line:
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24;172.16.10.0/24 auth-anonymous=1

And each client that likes to play some audio on the server has this line in the client.pa:
default-server = 192.168.1.192

I thought about the white noise thing this might help a lot keeping the audio channel open and ready for new things

Andy

6

Perhaps on the client side you could use the “module-tunnel-sink” instead;

load-module module-tunnel-sink server=192.168.1.192 sink_name=Remote

And set the “Remote” sink as the default sink of the pulseaudio client setup. Thenit might keep it alive, which might reduce the latency.

Worth a shot.

7

ok according to

pacmd list-sinks

with the tunnel I have a latency of around 250ms.
However when I ask a question in the CLI, for example “weather” I can see the answer in yellow but it further takes 3 seconds till I hear the answer through the speakers…
is this “normal”

8

I have noticed similar but its not constant.
I thought it was mimic that was slow pushing a wav to paplay rather than paplay.
I never did sort it because because the delay would come and go.

9

Its most likely paplay that does delay the whole process. You can watch the audio.log file and there you can see that receiving the audio file from the server (TTS) is rather quick but after that till it actually plays takes some time since paplay needs some time to start up and send the data through pulseaudio to your speakers