pulseaudio-dlna
pulseaudio-dlna copied to clipboard
masmu
Playback is delayed (Reopening #338)
Having more information now, I would like to reopen issue #338. In contrast to the referenced issue this issue is not restricted to the Sonos PLAY:5 anymore. I investigated some testing, that showed the same issue with another setup.
The playback is delayed by 5 to 8 seconds. There are a few reasons that let me think it has to be pulseaudio-dlna which causes the delay, but also one which makes me doubt.
Arguments for pulseaudio-dlna beeing the reason of the delay:
- Using BubbleUPnP (as DLNA Server) there is almost no delay (about 1 second) .
- Using BubbleUPnP as DLNA Renderer and pulseaudio-dlna as server there is also the 5 to 8 seconds delay.
- Using a wired connection instead of Wifi shows also the long delay.
Argument against pulseaudio-dlna beeing the reason of the delay:
- I tried to sniff the pulseaudio-dlna stream with wireshark because I have been pretty sure that I will be able to see the same time shift in the stream. But instead it also looks like the data gets transmitted around 0.5 - 1 seconds after I start the streaming.
Currently I have no other ideas to debug. If somebody has, please let me know. I would really like to fix this.
Everything I try to send sounds to via pulseaudio-dlna is lagged by about 5-8 seconds. I've tested a Google Home, a couple Chromecasts (v1 and v2), and a Google Speaker. I'm thinking it's just their internal buffer, might be the same on the sonos too? Makes it very difficult to use it as a remote speak though as things are extremely desynched... ^.^;
@OvermindDL1 That was also my first assumption. But I'm pretty sure it is not the buffering (or there has to be a way to prevent that) because BubbleUPnP (a DLNA server and renderer for Android) delays the playback by only 1 second.
just installed pulseaudio-dlna 0.5.2.1 on ubuntu 16.04 so I can play music on my Samsung UE32J5550SU and I'm experiencing an even bigger delay, about 15 to 20 seconds
A question, when anyone streams to a DLNA device without using this project, do they still get the same delays? I'm pretty sure this is buffering on the hardware side, but testing other ways would verify that for sure.
@OvermindDL1 Using the official SONOS app, I never have any latency, delays or buffering. Only with this project to I experience that behavior.
@netllama When using the official SONOS app is there any delay with dynamic audio, not an audio file (as that could be sent en-bulk and hide any latency, where an audio system is dynamic/streaming audio). Easiest way would be to stream your mic over it using the SONOS app, is there any delay doing that?
@OvermindDL1 like I said in my initial post using BubbleUPnP the delay is a lot shorter. So I am pretty sure it is not the devices buffering.
If someone can provide easy instructions on how to test DLNA streaming without this project, I'd be happy to try it out
Not sure if I should add here or create a new issue. But sound delay is a major issue on my pulseaudio-dlna install. Listening to any audio and casting to any chromecast audio leads to an initial delay of about 5 seconds.
But the primary problem is that this delay grows over time. Over a few hours of listening, the delay grows to minutes.
Is this the same issue???
Hello! I just wanna report that i'm having the same issue as @TheRoarkster . I'm running on Ubuntu 17.10 and streaming to a Panasonic DT-50. So far i've been having a delay up to 32 seconds.
Thanks :)
(P.S. i really appreciate this project btw, i've been looking for this exact solution for a while now and yours is the best i've tried so far!)
just installed pulseaudio-dlna 0.5.2.1 on ubuntu 16.04 so I can play music on my Samsung UE32J5550SU and I'm experiencing an even bigger delay, about 15 to 20 seconds
I still have the same problem with an updated Ubuntu 18.04.1 LTS and pulseaudio-dlna 0.5.3 (same TV), where the delay is about 26 seconds. Also, the sound volume gets lower and then back to normal sometimes for no apparent reason.
Another reason against it being pulseaudio-dlna: Stream What You Hear under Windows in conjunction with BubbleUPnP as the renderer causes delays of similar length. Whoever the culprit (if it is any single one) there must be a way to debug this?
Another reason against it being pulseaudio-dlna: Stream What You Hear under Windows in conjunction with BubbleUPnP as the renderer causes delays of similar length. Whoever the culprit (if it is any single one) there must be a way to debug this?
Your argument with 'stream as you hear' is not completely valid: it only shows that the same problems can be caused by other setups, too. I have the same problems as the original poster (I use LMDE3): when using uncompressed wav, the delay is ~10 secs. With compresssion (tested with mp3), the delay doubles to ~20 secs. So, very likely, the problem is not caused by network throughput. Maybe the transcoding algorithms use some buffering and are causing this delay? With VLC (that also has the DLNA feature), the delay is minimal (1-2 secs). However, VLC is not optimal for Audio Playback as it lacks many features.
I have the delay at around 2-3 seconds here using Ubuntu 20.04 and this command: ./pulseaudio-dlna --encoder wav --chunk-size=512
Despite the repository appearing dead, I'm curious whether people figured out a way to work around the latency? While the software works well generally, this is the only thing that keeps me from me being fully content with it.
Funnily enough, in my case the choice between uncompressed (wav) or compressed (e.g. mp3) stream doesn't affect the delay at all, which would have been expected from reading the instructions. With me, the latency is on the order of 10s.
If someone knows of any tricks, or of some alternative solution to the problem, please do share!
Since no-one has yet responded: personally I lost interest when it became clear that most distros are moving away from pulseaudio and many towards PipeWire. I've now put all my low-latency-multiroom-audio projects on hold until I have time to get into https://github.com/badaix/snapcast, which has a wider scope / different goalset from pulseaudio-dlna, but works well with PortAudio. Perhaps interesting to others as well...
Thanks for chipping in @sixtyfive!
I'm actually using snapcast as part of my media playback stack. It integrates really easily with Mopidy/MPD, and allows for synchronous multi-room playback of anything Mopidy is playing. The cool thing with pulseaudio-dlna is, that I'm able to route audio from my laptop to Mopidy, which then distributes the stream to all snapcast clients seamlessly. The only problem in the stack is the latency generated by pulseaudio-dlna, which leads to my earlier question.
I had not heard of PipeWire, it seems to be an interesting project! It seems to be "competing" with pulseaudio itself, though, and thus would require a more radical shift in how the stack is constructed. It might be possible though, especially if the bigger players are moving towards it.
Yeah, PipeWire is like JACK / PulseAudio / etc. I don't know the technical reasons behind it, but even Debian has adopted it as the default now.
With my own multiroom setup, the idea is to do it all via Snapcast. Nothing else. Because it's so lightweight, people have been experimenting with making it work on a measly ESP32. I'm sort of waiting for one single solution to emerge from that and stabilise. See https://github.com/badaix/snapcast/discussions/520 for lots of links to lots of things :)