Sound lag about pulseaudio-dlna

[belugame]

I also face this problem with Ubuntu sending music to my Yamaha stereo. Can this issue be reopened?

[sixtyfive]

@bill-mcgonigle I tried with all codices back then. Meanwhile I've moved on to Pulseaudio's module-native-protocol-tcp and won't be looking back.

[RayDar]

I see that in pavucontrol, some output devices have 'advanced' options that include a 'latency offset'. Would it be possible to enable this feature on the pulseaudio-dlna devices? This way, we might be able to enter a very large number for that value which might make the audio on the DLNA renderer somewhat match the video on the computer screen. (Great work by the way).

[masmu]

I have seen that feature myself, but its greyed out here and i have no clue how and if you can enable it. If you guys find how to do that i am happy to add this to the README 😃

But i doubt it will be useful. Take a look at the following:

    index: 12
        name: <wohnzimmer>
        driver: <module-null-sink.c>
        flags: DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
        state: RUNNING
        ...
        current latency: 11,38 ms
        ...
        configured latency: 20,00 ms; range is 0,50 .. 2000,00 ms

The configured latency is set to 20ms and you can set it to 0,50 to 2000ms. So, you can't decrease the delay just delay it even more.
The current latency is about 11,38ms but i have a real latency about 1-2 seconds. That comes from the buffer of the UPNP Renderer. UPNP uses HTTP streaming and a buffer which collects enough data to ensure your music will continue playing even if there are situations where your bandwidth is too low. Imagine there won't be a buffer and you hear your music without delay. Everytime your device does not recieve enough data, your playback would stop and you would hear stuttering.
So the buffer is a protection with a price named real time playback.

In general removing the buffer is a bad idea. This thing was invented for a good reason.
I think the problem to solve is not the delay itself, but that the delay has no fixed value. Imagine your delay would be always 3 seconds, you could instruct your video player to play the video time shifted with -3 seconds. VLC can do this.

I did a quick google research if DLNA is capable of setting a fixed delay. No results yet.
What do you think?

[Takkat-Nebuk]

I believe a latency of 2 s only is already pretty good for a network stream. If however we need to sync the network stream with a local video output we may introduce a longer latency for compensation.

This can not be done with the null-sink used. But we may run the recorder parec with a parameter --latency-msec=MSEC or similar for sox (delay X X). I don't know with lame or flac.

[RayDar]

My UPNP renderer (an Onkyo HT-RC360) must have a really large buffer. After several tests, it seems the audio starts up about 27.5 seconds (27500 ms) after the video begins. I appreciate Takkat-Nebuk's suggested work-around but this cannot be done on many players (ex. watching Youtube video).

[masmu]

@Takkat-Nebuk: Great idea!
I did a quick test, but the --latency-msec option has no effect here. I tried it with 15000ms so that the sound should be delayed by 15 seconds. No effect as said. I think this option has another purpose.

@RayDar:
The buffer of your device must not be that big. It is just filled slowly. Your device normally starts to play when the buffer is full the first time. So, if your network is slow this takes time, even if the buffer isn't big.
27.5 seconds is a huge delay (at least for my setup). Is it attached by cable or wifi?

[RayDar]

@masmu I am using a wired gigabit (CAT6) ethernet network.

[masmu]

@RayDar That is really weird. You should have a delay about 1-2 seconds as it is here in my setup. Perhaps a slow computer (the one which pulseaudio runs on)? Raspberry Pi or stuff like that?

[RayDar]

@masmu I am using it on my development laptop. /proc/cpuinfo includes this line:
model name : Intel(R) Core(TM) i7-4700MQ CPU @ 2.40GHz

[masmu]

@RayDar Ok, fair enough. This machine can handle the task 😄
Is the laptop also attached by wire?

[RayDar]

@masmu OK. It's not the reciever. I just tried with BubbleUPnP on my Nexus 7 sending audio (over wifi) to that same HT-RC360 renderer. The delay, at the worst, was 2.5 seconds (2500 ms)

[masmu]

@RayDar Ok, i wanted to please you to do that the next step.
Could you try different encoders? I recently saw an odd traffic dump when using lame as encoder (with is the default). So, please test every other encoder than lame.

[RayDar]

Changing to the WAV encoder makes the video only about 2 - 3 seconds ahead of the audio. This is much better. BTW, the flac encoder messes up the HT-RC360 so bad that it needs to be unplugged. The ogg encoder errors out but doesn't require the receiver to reboot.

[masmu]

@RayDar: Glad to hear that the wav encoder works far better for you and sorry for the unplug 😄. But I will think about that. I had that feeling for a different encoder because of the mentioned lame traffic dump. I was filled with a repeating sign. It seems as there a some devices which can handle this without any trouble and there are some which need more time for that.

Its a bit weird. I am sending the pure encoded bytes directly to the stream. I think i have to read a bit more about the lame encoder and ask a few questions in their mailing list. Sadly i am not an encoder expert 😃

[masmu]

@RayDar If you are willing to experiment more... You can change the lame command line easily yourself.
It is in upnp/server.py in line 147 and it is set to raw-input and to a constant bitrate of 320.
Simply change it, save and restart pulseaudio-dlna. Perhaps the HT-RC360 manual reveals more of what the device is capable of and what not.

Since you have the device i think there is more you can do for the project as i can do for you.

[RayDar]

I have done some experimenting and cannot come up with something that reduces the audio lag (from 27 seconds!) with the lame encoder. If the guys on the lame mailing list give you some options that might work, I can try them for you.

In the meantime, I will use the WAV encoder. It would be great if the pulseaudio system knew that the renderer has about 2.5 seconds of latency, that would probably help the video synchronization.

[MobiusHorizons]

Hey guys, the reason this happens is because dlna is not a realtime protocol, so the player buffers for an unspecified time. Sometimes the buffer may be implemented in size, instead of time length, so wav (which is huge) buffers fast, but mp3 or opus (which are small) buffer for a while.

Does anyone know if DLNA broadcasts the player position? if it does, we could possibly set the latency on the stream so that the audio is synchronous. Probably not with our current parec solution, but it could be done.

[masmu]

@MobiusHorizons
During my rewrite of the streaming server i was experiencing exactly that.
mp3 with 320 kbits/s and flac were buffering much faster than ogg. If you force ogg also to use 320 kbits/s it also buffers faster.
Btw, many devices use open source projects in their firmware. So, for example my D-Link DCH-M225/E uses mplayer to get the stream. And mplayer uses a default buffer of 320 kb.
I am currently thinking of an option to specifiy the bitrate. So, people could influence that.
Increasing the bitrate by default is not a good idea, because there might be situations were you want a lower bitrate, e.g. weak network throughput.

[MobiusHorizons]

Yeah, I was wondering if you can set the latency In pulse itself based on the current position of the dlna renderer.
Another aproach might be to send a very high bitrate section of silence to fill the buffer.

[MobiusHorizons]

I'll give the second approach a try when I get home

[masmu]

@MobiusHorizons
It is still a work in progress. So its not finished yet, but it works pretty good. Feel free to beta test 😄
The new streaming server consumes less cpu and is faster than the old one. I did some stress tests with 100 clients streaming at the same time. No difference for the cpu load 👍
The old streaming server consumed 100% cpu at those tests.

Besides that the codec gets choosen by the devices depending on their capabilities.
So, if your device just supports e.g. mp3 and ogg the best format is chosen of them.
And there is a new AAC encoder. With that one in a cable environment i have a latency of 0,7 - 1 second.

[masmu]

Seems as this is not possible currently ...

[MobiusHorizons]

cool, thanks for looking into it.

[sixtyfive]

Hi everybody! I've been thinking about this for a bit and it seems to me as if MobiusHorizons is on to something here. If it was possible for the DLNA renderer (SoundMate, whatever) to communicate through the DLNA server (i.e. pulseaudio-dlna) with the video player, that would permit an automatic adjustment of the player's A/V synchronisation setting - while bypassing any PulseAudio settings completely. After all, it's not a problem of minimising the latency, it's a problem of synchronising audio and video. The offset is just a single number and probably needs far less time to travel through the network than what is required for the perception of synchronicity by the brain. Depends on correctly set clocks of course and whether the renderer informs the server about the time at which the buffer has filled completely and playback has started. Perhaps a first step could be to implement a sort of plugin for a video player (VLC, Totem, mplayer, whatever) to talk to pulseaudio-dlna which could get a command line switch for starters. Just an idea...

[bubbleguuum]

Generally speaking, LPCM (audio/L16) should offer the least latency on the renderer side, and used whenever possible. LPCM is supported by all DLNA renderers since it is mandatory for DLNA compliance.

[masmu]

@bubbleguuum : In theory yes. But not all devices specify the mime type audio/L16 and are not capable of playing LPCM. Besides that wav and l16 are pretty similar. But you are right, i am a fan of old encodings such as wav too.

[bubbleguuum]

LPCM is mandatory for DLNA certified devices. Regular UPnP devices may not support it. In that case, most of them support WAV. So with LPCM and WAV you can cover 99% of devices.

[gartempe]

Hi there, I'm too using Pulseaudio-dlna on Ubuntu 14.04 to stream to BubbleUPnP on Android phone. I also noticed (and got annoyed by) the lag of ~ 15s when streaming to BubbleUPnP.
Thanks to this thread, I know that it's about BubbleUPnP's buffer. So I've tried with the encoder set to "wav", then the buffer fills in 2s, great. But now I'm concerned about my Wifi bandwidth usage.

Here is Wifi bandwidth usage reported from my AP while streaming:
[MP3] RX: 222kbps / TX: 350kbps
[WAV] RX: 1.51Mbps / TX: 1.65Mbps

I'm in a situation where wifi coverage is a bit difficult (long apartment, lots of big wall made of stone, dozens of wifi networks around and lots of wifi pollution: bluetooth and gagdgets), and so wifi bandwidth is precious. As I'm listening to music from laptop to hifi, like 8 or 10 hours/day, I would like to preserve my bandwidth for work, etc...
Do you know any Upnp/dlna player app for Android on which it's possible to set manually the buffer size and reduce it? (I didn't found out for BubbleUPnP).

Thanks.
Pulseaudio-dlna is great for me to get rid of bluetooth (a wifi killer) for sendig music to my hifi set.

[masmu]

To be answer your question: I do not know an Android app where you can set it.
Do you pay for your wifi based on the used traffic?

[gartempe]

No, I don't pay for wifi traffic. But I barely get 4Mbps at some sides of the building (and I can't wire it).
I'm planning to buy costly Ubiquiti Wifi-AC access points in the future to get a decent wifi coverage with plenty of domestic bandwidth. But for the moment I'm trying to not monopolize bandwidth for entertainment, as I'm using this network to work (and not alone).

[masmu]

Ok, was just thinking of this because theoretically you get 600 Mbit/s from wifi n. Sure, this is just in optimal conditions, on the other side 1,5 Mbit/s are less than 1% of it. Most times there should be more than enough bandwidth left ... But you are right. 4 Mbit/s is not that much ...

[masmu]

Just one more thing from a practical point of view. Since I am also using software implementations of DLNA renderers, where I set the buffer to zero, if you do that every network disturbance will kill your renderer. Kill means stopping immediately. That buffer exists for a good reason.
I have one in my kitchen which plays with mp3 and the most times it runs for about 10 minutes. But at a certain point the wifi fails and it stops. I can tell you it is really annoying to make it play again.
You really have to rely on your network to disable the buffer.

In the end I am pretty sure, it is not about searching an Android app where you can disable the buffer.
You took the right way with making your network more reliable.

[gartempe]

Yep, making a reliable and strong network is my priority # 1. Especially as I want to work at home.
I've tested wifi repeaters (and those N 600) with mixed results: coverage is extended but bandwidth is divided, and it is not always stable. So, I'll set up a wifi PtP using Ubiquiti Nanostation or Nanobeam, preferably using wifi-AC standard.

Btw, there is lot of marketing blabla from vendors about wifi. For instance: 600 Mbit/s from wifi N, it is only 300 Mbit/s for 2.4Ghz and 300 Mbit/s for 5Ghz, separate, but not real 600 Mbit/s. And it is a maximum theoretical bandwidth when you're in the best conditions (without any obstacle or interference, in the same room...).
Above 300 Mbit/s becomes real with wifi-AC standard and compatible devices and clients that can work and connect with both frequencies 2.4 & 5Ghz and multiple channels simultaneously.
For announced bandwidth you should also count RX + TX. So in my current case RX: 1.51Mbps / TX: 1.65Mbps = 3.16Mbps out of 4Mbps.
And for regular hardware, the bandwith of an AP is shared between all clients, so they won't all have the announced bandwidth simultaneously.

As Chromecast2 works with Wifi-AC, that's a good candidate for me, since I've seen you added support for Chromecast Audio on Pulseaudio-dlna ;)

---

About buffering and lag, and why you'll get this subject rising from users feedback (either here, or on some Linux users forums like Ubuntu): it's a matter of user experience and usage.

For media streamer, internet radio, dlna render from a music collection: you choose either a radio station, a track/album/playlist from your music collection, launch it and listen. User experience is like selecting and playing a vinyl disc on a jukebox in a bar during the 50/60's... People are used to get a lag, and it is acceptable as it is not real "live" interactions. It's a bit more like "transactional" interactions, to speak as a dev.

For exporting/mirroring the sound from an OS, is a very different user experience: people are used to get an immediate feedback from any action they do with their system and interfaces.
Launching a video on youtube and getting video/audio not synced, getting forward in a track on soundcloud seeing the visual result of the action immediately on the screen but not for the sound, pausing of audacious/Rhythmbox/etc and the sound doesn't stop immediately but after 16s, system sound notification delayed, the sound of clicking in your system or on a website delayed, etc... It's like getting a lag on your mouse or your keyboard. 16s second between any action your do with your mouse or keystroke would lead users to frustration, that is understandable, it's same about sound on an OS or any interface the users interact with.

[masmu]

Closed due to inactivity.

[NicoHood]

I try to stream music from one pc to another via pulseaudio and simple paprefs settings. rhythmbox and spotify stream perfectly(no delay at all), but videos (local vlc/youtube via firefox/chrome) lagg extremely. This is possibly caused because the video and audio needs to be in sync.

Does anyone know how this could be solved? Using this setup, just configured via paprefs gui: https://wiki.archlinux.org/index.php/PulseAudio/Examples#Zeroconf_.28Avahi.29_publishing
Using the latest pulseaudio with archlinux. Streaming from x64 to a raspberry pi 3 (also arch) via 100mb cable.

[sixtyfive]

I've switched to SoundWire for most things now, because of the lag problem. SoundWire in the for-pay version and OPUS as compression codec is good enough for watching movies without people complaining about lipsync or stuttering issues. Shame there's no FLOSS equivalent.

[masmu]

I tried the negative latency thing, but my pulseaudio server complains about negative values. What pulseaudio version are you using? Am 14. Juli 2019 13:28:32 MESZ schrieb Eric Bellot <[email protected]>:

…

A quick but not very clean solution is to modify the pulseaudio_dlna/recorders.py file to use " --latency-msec" option of parec, like this: ```class PulseaudioRecorder(BaseRecorder): def __init__(self, monitor, codec=None): BaseRecorder.__init__(self) self._monitor = monitor self._codec = codec self._command = ['parec', '--format=s16le', '--latency-msec=-1000'] ``` Here i have set a negative latency of 1 second to synchronize Youtube videos with my Triangle AIO 3 with success. After modification, you can see the launched parec command in console messages of pulseaudio-dlna. For me: `07-14 13:09:28 pulseaudio_dlna.streamserver INFO Starting processes "parec --format=s16le --latency-msec=-1000 -d triangleaio32f80_dlna.2.monitor | lame -b 192 -r -"` -- You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub: #15 (comment)

[bill-mcgonigle]

I moved over from Fedora to Debian 10 and my latency went from about 2-3 seconds to 15-50 seconds. The most frustrating part is that when the player stops, even with a 30 second buffer happening, the stream immediately stops. I thought --disable-device-stop might prevent that, but unfortunately it doesn't.

I'm wondering what could be so different between the versions. My encoder looks like:
"parec --format=s16le -d livingroom_chromecast.2.monitor | lame -b 192 -r -"
so perhaps one of those isn't flushing buffers in ~realtime?

[bill-mcgonigle]

OK, -c flac reduces the buffering to about 8 seconds and -c wav to about 2 seconds. Something's up with the output buffering of those, it seems. I didn't see any obvious way to cause lame or flac to short-buffer their output.

I tried using --latency-msec=200 with parec but that didn't seem to make a perceptible difference.

I don't notice the stream being stopped short with a 2-second buffer, so this WFM. There's still something up for folks who might want an mp3/flac output. On my home wifi it doesn't really matter.

[sixtyfive]

Funny, for me (Solus, padlna from GitHub sources) even when I stop the player, the music keeps playing until the buffer is empty. And it can be much longer than 30 seconds sometimes. Enough to be concerned about not being able to take a phone call without physically going to the amplifier and turning down the volume knob.

[bill-mcgonigle]

@sixtyfive - wow, that's confusing. :) Are you able to try it with -c wav ? It looks to me like sox does very minimal buffering.

If anybody here has any pointers to where the buffering can be happening, that would be super useful.

[jeroenst]

I'm also experience this issue...