pulseaudio-dlna
pulseaudio-dlna copied to clipboard
masmu
Long sound delay and stuttering during volume changes
I know that these are both listed in the known issues, but I think what I am experiencing is worse than usual as it makes pulseaudio-dlna essentially unusable.
Long Sound Delay
My sound delay from computer (Ubuntu 16.04) to speaker start starts at about 2-4 seconds, but grows to around 15 to 18 seconds after about 1 minute of play. I am using this command to start pulseaudio-dlna:
pulseaudio-dlna --codec=wav --encoder-backend=avconv
The delay makes it difficult to use because I need to be able to pause the sound to take phone calls (or just if someone live is talking to me). And by the time the sound stops the caller is gone.
I recognize the statement in the known issues that
Since there is HTTP streaming used for the audio data to transport, there is always a buffer involved. This device buffer ensures that even if you suffer from a slow network (e.g. weak wifi) small interruptions won't affect your playback.
But I wanted to point out that there is a maximum of 2 second delay on either (A) the same computer running google-chrome browser with the ChromeCast plugin and (B) an android phone running Chromecast or AirAudio. In other words, I was hoping that there might be a way to accomplish the same delay in these two approaches.
Stuttering on Sound Step Changes
This is mentioned somewhere as an issue, but I don't recall where. For me, the problem is that if I increase/decrease the volume while using pulseaudio-dlna and the chromecast as an audio sink, there is a considerable stutter that, again, makes its use difficult.
Thanks for any guidance. I'm happy to test any proposed solutions.
My sound delay from computer (Ubuntu 16.04) to speaker start starts at about 2-4 seconds, but grows to around 15 to 18 seconds after about 1 minute of play. I am using this command to start pulseaudio-dlna:
So, if the delay increases by that amount the actually played audio stream must be stretched, like being played much slower, right? I remember a bug regarding wav encoder settings some time ago. Does the delay also increase when selecting other encoders?
The delay makes it difficult to use because I need to be able to pause the sound to take phone calls (or just if someone live is talking to me). And by the time the sound stops the caller is gone.
I know this is just a workaround ... but what's about just switching music streams to the chromecast? And play all other sounds via the default soundcard?
Stuttering on Sound Step Changes This is mentioned somewhere as an issue, but I don't recall where. For me, the problem is that if I increase/decrease the volume while using pulseaudio-dlna and the chromecast as an audio sink, there is a considerable stutter that, again, makes its use difficult.
Well, I can reproduce that behavior to certain point but I not quite sure we are talking about the same problem. When I increase/decrease the volume in pavucontrol you hear some short cracks (about 0.5s) and the sound is back to normal. But since there a lot of people complaining about this I start to feel that there might be other symptoms than those I am experiencing. I am not 100% sure where this comes from, but my best guess is that some encoders are not made for handling drastic volume changes. Encoders normally work within a specific range while encoding the sounds amplitude. When you increase the volume the amplitude also gets increased as well and might break the encoders bounds so that the encoder has to adjust. Maybe the encoder also stops for a brief moment while adjusting. I am just recording the data pulseaudio is delivering, piping it through an encoder and sending the data via HTTP to your device. So, it feels like my hands are tied, because the basic principle is really simple and there is no black magic involved like e.g. sound post-processing. When comparing the situation to common streaming... the real problem is that you are able to change the volume by using the system's volume controls. Think about HTTP mp3 radio streams where the music is played at a predetermined volume level and the user can set a comfy volume level by its own soundcard. Or think of DLNA: When you are streaming a song it is always transmitted like that song was recorded. When you change the volume it does not change the songs amplitude, instead it controls the device volume settings. So, the best would be to always stream with the volume set to 100%, never touching that setting, and adjust volume within the device's volume controls. It would be great if I could fake pulseaudio's volume sliders to actually control the devices volume settings and not to directly change the real volume. But that is not possible.
One thing I could try is to use pulseaudio's internal encoders. They might adjust better to volume changes than externals do. I tried that a year ago with pulseaudio 6.0 but I discarded that idea because it was not working that well. But maybe this has changed with pulseaudio 8.0.
Thanks for the detailed information Masmu.
On the Sound Delay issue:
So, if the delay increases by that amount the actually played audio stream must be stretched, like being played much slower, right? I remember a bug regarding wav encoder settings some time ago. Does the delay also increase when selecting other encoders?
Actually, no, the audio stream does not play any slower or get stretched out in time. At least not that I can notice. It does take about 5 seconds to get started on the Chromecast, but I can't explain the additional time lag other than that it is in small enough increments that it's not noticeable during playback and adds up over the course of a few hours of play (The delay actually expanded to over a minute last night when I listened for several hours in a row). I have used other encoders and had the same problem.
I know this is just a workaround ... but what's about just switching music streams to the chromecast? And play all other sounds via the default soundcard?
I think my post wasn't clear -- the phone isn't on the computer. I just need to have the music on the chromecast to pause in time to take a regular call. When it is delayed by 10 or more seconds, when I hit the pause button the music continues to stream long enough that I miss the call.
As I was testing out another codec this morning, I noticed that it looks like pulseaudio-dlna is creating a new stream for each new song (I'm using Pithos to play the music). Here is what it looks like across two songs: [song 1]
12-27 09:21:35 pulseaudio_dlna.pulseaudio INFO The device "Dining Room (Chromecast)" is playing.
12-27 09:21:35 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink59 finished!
12-27 09:25:38 pulseaudio_dlna.pulseaudio INFO on_playback_stream_removed "/org/pulseaudio/core1/playback_stream639"
12-27 09:25:38 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream640"
12-27 09:25:38 pulseaudio_dlna.pulseaudio INFO on_playback_stream_removed "/org/pulseaudio/core1/playback_stream640"
12-27 09:25:38 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream641"
12-27 09:25:39 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink59
12-27 09:25:39 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink59 finished!
[song 2]
12-27 09:31:42 pulseaudio_dlna.pulseaudio INFO on_playback_stream_removed "/org/pulseaudio/core1/playback_stream641"
12-27 09:31:42 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream642"
12-27 09:31:42 pulseaudio_dlna.pulseaudio INFO on_playback_stream_removed "/org/pulseaudio/core1/playback_stream642"
12-27 09:31:42 pulseaudio_dlna.pulseaudio INFO on_new_playback_stream "/org/pulseaudio/core1/playback_stream643"
12-27 09:31:43 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink59
12-27 09:31:43 pulseaudio_dlna.pulseaudio INFO _async_handle_sink_update /org/pulseaudio/core1/sink59 finished!
Note that those were the second and third songs played that session, and the real time delay grew to 18 seconds (i.e., the actual sound output didn't change tot he new song until 12-27 09:32:01). I kept the player going, and by 30 minutes later the delay had grown to over 35 seconds.
On the Stuttering on Volume Change issue: What you wrote makes a lot of sense. Does it help at all to know that inside google-chrome, I can change the volume without the stuttering (same goes for the Android)? I'm guessing not, but just in case I thought I'd mention it.
This is probably expected behavior, but I wanted to note that while casting using pulseaudio-dlna from my Ubuntu 16.04 computer, the "Home" Android app immediately pauses the audio stream and adjusts the volume without any distortion. However, this appears to be only at the actual Chromecast device (which is probably why it works without delay or stuttering) -- the music player itself does not pause. The Home app also: displays the pulseaudio-dlna icon, states that it is casting from the music app, and provides the computer name.
I wanted to report back a new, perhaps critical, discovery regarding the Sound Delay Issue. It appears that the extended delay only occurs in standalone streaming players such as Pithos and Spotify. It does not occur in the Pithos/Spotify web players for either Firefox or Chrome. It also does not occur in a standalone local media player such as Rythmbox.
I don't know what this means for determine which application is causing the issue or how to fix it, as neither Pithos nor Spotify have any delay at all when playing over the local speakers or over Bluetooth. So it seems to be some combination of pulseaudio-dlna and the standalone streaming player.
Also, I should note that the Stuttering on Volume Change occurs regardless of the platform used.
I hope this new information is useful.
I also experience "Stuttering on Volume Change" on Ubuntu 16.10, streaming to a Kodi media player. Also, playback starts with a lag of 2-4 seconds.
@varac If you are referencing to this topic in general: It is not possible without any delay. But in case of Kodi there would be at least the possibility to patch Kodi for reducing the buffer.
@xmbwd Thanks for all the detailed information. I would please you to create two pactl.logs (pactl list > pactl.log).
- One while using an audio player which creates an increasing delay
- One while using an audio player which does not
The whole thing might be a sample specification problem.
Same here: While changing the volume on the computer, the volume change sound that comes up sounds very distorted, along with the music played. After volume change complete, the sound is clean again.
This on ArchLinux and pulseaudio-dlna git master and Libratone Zipp or Google Chromecast with all decoders.
I can confirm both issues, running 22bb91b801d on ArchLinux with Google Chromecast audio. Delay is about 3-5 seconds for play/pause, with additional delays when changing volume.
@stes : Which player software are you using? I am not experiencing this at all. And @xmbwd reported that this is just occurring when using certain players. I could really need two pactl logs, one where the delay increases and another one where it is working fine.
Apologies for not posting back sooner. Attached are two logs. One named Pithos and one named Firefox. Both use the Pandora service -- one using Pithos (which has the increasing delay) and one using the Pandora website in Firefox (which does not have the delay).
No worries and thanks for the logs.
The firefox stream is using:
Sink Input #181
Driver: protocol-native.c
Owner Module: 11
Client: 62
Sink: 3
Sample Specification: float32le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"float32le\"" format.rate = "44100" format.channels = "2" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 64198 / 98% / -0.54 dB, front-right: 64198 / 98% / -0.54 dB
balance 0.00
Buffer Latency: 74988 usec
Sink Latency: 16457 usec
Resample method: copy
Properties:
media.name = "AudioStream"
application.name = "Firefox"
The pithos one uses:
Sink Input #166
Driver: protocol-native.c
Owner Module: 11
Client: 58
Sink: 3
Sample Specification: s16le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"s16le\"" format.channels = "2" format.rate = "44100" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65535 / 100% / -0.00 dB, front-right: 65535 / 100% / -0.00 dB
balance 0.00
Buffer Latency: 104489 usec
Sink Latency: 98418 usec
Resample method: n/a
Properties:
media.name = "Playback Stream"
application.name = "Pithos"
There is a noticeable difference in the sample format. (Firefox float32le 2ch 44100Hz, Pithos s16le 2ch 44100Hz) I will try to recreate that situation here and hopefully get the same problems you are running into.
Regarding the Stuttering on Volume Change issue:
I added pulseaudio as a new encoder backend. When you start pulseaudio-dlna like:
pulseaudio-dlna --encoder-backend=pulseaudio --codec=flac
pulseaudio-dlna --encoder-backend=pulseaudio --codec=ogg
pulseaudio-dlna --encoder-backend=pulseaudio --codec=wav
there is no other encoder involved than the ones which are shipped with pulseaudio.
I added that feature some time ago, but it worked just for flac... For some reason it does not work for wav and ogg. I assume there is an error in pulseaudio. I searched for some explanations and there were bugs which could fit to this some years ago. But perhaps those patches were never included in Ubuntu, but perhaps in other distributions...
Testings for that branch are welcome!
@xmbwd Also tried to install and use Pithos but was then I had to realize that I cannot use it because I am from Germany. I would need to get an US VPN provider for that. :disappointed:
Could you perhaps search for another application which is using float32le 2ch 44100Hz as sample specification?
One thing, you can choose the music quality when starting Pithos, could you try to use a lower quality and check if this has an influence on the sample specs?
I changed the preferences in Pithos to "Low Quality." As a result, the new Pithos pactl.log is similar to Firefox: it uses the float32le 2ch 44100Hz sample specification:
Sink Input #325
Driver: protocol-native.c
Owner Module: 11
Client: 54
Sink: 4
Sample Specification: float32le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"float32le\"" format.channels = "2" format.rate = "44100" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65535 / 100% / -0.00 dB, front-right: 65535 / 100% / -0.00 dB
balance 0.00
Buffer Latency: 114353 usec
Sink Latency: 1024 usec
Resample method: copy
Properties:
media.name = "Playback Stream"
application.name = "Pithos"
While in "Low Quality" audio in Pithos, I do not experience the extensive sound delays. Rather the delay is decreased to 2-3 seconds and does not seem to grow over time.
This suggests the issue is with the s16le sample specification.
So............unfortunately, the prior post is not correct. It did work for a while (long enough for me to believe it was fixed). But after reboot and about 2 hours of use, Pithos is streaming a 10 to 15 second time delayed and volume stuttering stream, despite using float32le 2ch 44100Hz
Here is the log:
Sink Input #59
Driver: protocol-native.c
Owner Module: 11
Client: 49
Sink: 3
Sample Specification: float32le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"float32le\"" format.channels = "2" format.rate = "44100" format.channel_map = "\"front-left,front-right\""
Corked: yes
Mute: no
Volume: front-left: 65535 / 100% / -0.00 dB, front-right: 65535 / 100% / -0.00 dB
balance 0.00
Buffer Latency: 157551 usec
Sink Latency: 70886 usec
Resample method: copy
Properties:
media.name = "Playback Stream"
application.name = "Pithos"
@xmbwd Well, I don't know what to think of this. My Sinks are using a sample specification of s16le 2ch 44100Hz as yours do. And all my sink inputs are using that also. At first I was pretty happy to finally get a clue what could going on there. But I would have assumed that your sink inputs which are using float32le 2ch 44100Hz are the problematic ones.
But as you stated out, they are the ones which worked. So, that did not make any sense to me.
Now, that you realized that this had no effect (?) on the issue, we have to start all over again.
My problem is, that I cannot reproduce that problem at all. And therefore I am kind of relying on your peoples help. Because I can just fix problems which I can reproduce. So, I would highly appreciate when someone could take a deeper look at this, so that we might solve that issue all together.
Correcting the following because the culprit appears to be Gstreamer not Pithos:
I'm starting to think it is more to do with Gstreamer than pulseaudio-dlna. I just started using Tomahawk, and it has the shortest delay of all the players I've tried (e.g., Spotify, Pithos, web based) despite the fact that it uses s16le 2ch 44100Hz.
Here is the pactl log:
Sink Input #413
Driver: protocol-native.c
Owner Module: 11
Client: 263
Sink: 4
Sample Specification: s16le 2ch 44100Hz
Channel Map: front-left,front-right
Format: pcm, format.sample_format = "\"s16le\"" format.rate = "44100" format.channels = "2" format.channel_map = "\"front-left,front-right\""
Corked: no
Mute: no
Volume: front-left: 65536 / 100% / 0.00 dB, front-right: 65536 / 100% / 0.00 dB
balance 0.00
Buffer Latency: 1160000 usec
Sink Latency: 11328 usec
Resample method: n/a
Properties:
media.role = "video"
media.name = "audio stream"
application.name = "Tomahawk"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "30"
application.id = "org.kde.phonon.Tomahawk"
application.version = "0.8.4"
application.icon_name = "tomahawk"
application.language = "en_US.UTF-8"
Pithos contributor here... We don't do anything special in Pithos with the audio stream. All we do is hand the audio url provided by Pandora(which is just a plain old url pointing to a MP3 or MP4) to Gstreamer. What happens after that is between Gstreamer and PulseAudio. Are there any PulseAudio props we need to set to make it work better/properly?
Would this be useful at all? https://github.com/pithos/pithos/commit/f19b842a06e66a263862301373169aae6939dec8 That would give you something like:
Client #41
Driver: protocol-native.c
Owner Module: 10
Properties:
application.name = "Pithos"
native-protocol.peer = "UNIX socket client"
native-protocol.version = "31"
application.version = "1.2.1"
application.icon_name = "io.github.Pithos"
media.role = "music"
media.title = "Girls, Girls, Girls"
media.artist = "Motley Crue"
media.name = "Motley Crue: Girls, Girls, Girls"
media.filename = "http://t1-1.p-cdn.com/access/380173102242434467.mp3?version=5&lid=268249233&token=BsrzzCuGcXrFIC5eIXgq%2FOw7tVzf3qEQ6TObRJjg10J1%2BEMnLn%2BQROfnfzE8TVSH0EPxpSa6e4DsC2oTe5ZHVOp0OXGhtiP72%2BuBWBwYlpRddk%2BESHvlTaqpd4UrCAA0ZPQ0jvV2KHaI1EXA5D49e9kHzm%2FUGyqD9BtaUPm8t08NXzZZtnqE6Xkc%2FDJaHFzOUg%2BchOr3lDHK1R9EmZBezqu8Psq2N8p3gavXitotJ7hwpQrDWMmqCox0KVeqzZb2%2FDak67YKq4mQyo9fsxLmCEQDL2W4gbSSnHZxM2KKlLeiIF1lcZqD5BDrvdAD2EiwdfsPy7X%2F%2FbspFCF3fqIRdg%3D%3D"
application.process.id = "4377"
application.process.user = "jason"
application.process.host = "Inspiron-One-2020"
application.process.binary = "python3.5"
application.language = "en_US.UTF-8"
window.x11.display = ":0"
application.process.machine_id = "38fb648d82ca4d04a576db08b212d413"
application.process.session_id = "2"
from pactl list
In the above case you wouldn't actually need to use the audio from PulseAudio since media.filename is the actual url that Pithos plays anyway you could just stream that directly.
Note: The above audiourl is only good for 1 hour.
May I all please you to test this branch? It made quite some changes to the streaming server and maybe this helps.
I also experience the sound cracking issue on Ubuntu 16.04.2 with pulseaudio-dlna 0.5.2 when I change the volume or balance. I see there a specific issue just for that, #198. Any chance to reopen it?
I tried the branch, but after make install completed with no errors, pulseaudio-dlna resulted in this error:
Traceback (most recent call last):
File "/usr/local/bin/pulseaudio-dlna", line 5, in <module>
from pkg_resources import load_entry_point
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2927, in <module>
@_call_aside
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2913, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 2940, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 635, in _build_master
ws.require(__requires__)
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 943, in require
needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 829, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'enum-compat' distribution was not found and is required by zeroconf
I confirmed that I had all of the depends installled.
@xmbwd : Sorry for my late response. Thanks for mentioning that issue again. There was a bug in the Makefile which prevented setuptools to check for dependencies.
You can install the missing dependency via sudo pip install enum-compat or you pull latest master and run make install again.
I have a similar problem with a hk citation 1. I have about 20 seconds delay right from the beginning with mp3, flac or ogg as codec. Its much better when using wav, then the delay is "only" about 5 seconds. I'm tempted to think the problem is on the receivers side or with my trashy router... But thats only a vague feeling. Seems to be independent from all other options... (Using master)
Tried again today and it was more than 90 seconds (one and a half minutes) before playback started. Wow. I realize that's not due to a volume change, but those are easily in the multi-second range as well. Worst for me is time-to-playback-stop when somebody starts talking to you and you want to stop the stream to be able to have the conversation. It's a complete showstopper. Sad.
