New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Settings for shortest sound delay #61
Comments
Thank you very much for your interest in this application :).
These are the settings I use but with ffmpeg. Delay is also in the same range for me. I may refer you to #27 in which @ao-il has been investigating in more details how to reduce delay. Up to now, I, unfortunately, do not have an answer for it. What I can comment is that I have bought a Sonos speaker (#60) and my delay is always below 2 seconds using mkchromecast. In general, there are "so many things" happening behind the casting process when you use mkchromecast. Redirecting computer's audio, running a local web server, encoding/transcoding, pipe that to the webserver, connect chromecast with your computer to finally hear something. That may sum up to 1 second. Then you have the limitations due to the router and wifi card such as congestion of the channel used, or even other tasks done by your computer that may slow priority on some processes, etc. It also can be a problem with the webserver I use (flask). I would love to implement something based on |
Thank you for the response (and the app). I am not sure if this helps at all, but I thought that I'd mention that there is no (<1s) delay when casting over the same network, on the same computer, to the same Chromecast devices when doing so from within Chrome using its built in cast function. Perhaps that can either help isolate the cause of the delay (i.e., it's not the router, the computer, or the wifi connection to the Chromecast) or let us know that there is something proprietary to Google that allows Chrome to reduce the delay (I haven't tried Chromium and don't know if cast is available on it). Oh, and if this helps, the delay increases over time -- even if I am not actively casting any sound. (I should note that my computer is connected via ethernet, but obviously the Chromecast is on wifi). |
:) thanks!.
Casting a file? Or is there now a way to cast the audio from your computer?.
I think it is the way that things are working now with this app. For macOS case, when using the node backend in mkchromecast, it works very well. Delay is below 2 seconds. I am using a package called
I am aware of that one :(.
Which is a very nice setup because using ethernet your connection as "server" will be more reliable. In summary, there are still a couple of things to understand in order to improve this delay. |
I think the delay is caused by the server, from what I have experienced. Maybe an upgrade to python 3 would fix this? I have partially fixed the delay by delaying the audio at the playback app to allow the server to be ready. How does sending headers directly with the stream vs sending separately affect the delay? |
The app works with python3, and it does not improve.
One of the first things that is put ready is the webserver. That may not be the issue.
That sounds as a good idea. But you know what?. Now that I have been using mkchromecast with the sonos I found the following:
There are two calls from Sonos to mkchromecast?. Delay is always 1 second!. |
Some information I found: https://plus.google.com/112885659993091300749/posts/cJVvqsnnkjV |
Thanks for that link. Similar to what I did to delay the audio at the frontend. I am not sure exactly where those calls should be made, but found a parameter 'currentTime:0' which when changed to delay in seconds seeks ahead to the current playback time, thereby removing the delay, but also skipping some audio at the beginning. |
I was playing yesterday with this: https://github.com/balloob/pychromecast/blob/35742b617231a62a34bc5b3e072d79c03a2d25fa/pychromecast/controllers/media.py#L427 using the Do you refer to this |
Not exactly but similar, since I used the one of stream2chromecast. I think it should be the one sent to the device playback app. |
I have now been able to reduce the delay from 4 to 2 seconds. The thing was that we left the cc device to start playing when it wanted, in the load session. A call to play() after load(...) forces the device app to start playing immediately. In my case instead of calling play(), I just escaped some redundant steps by..
|
Forget to mention that currentTime was left at 0. |
Is there any way to get a log after the application is started? I have a weird situation right now where there is zero (0) delay; I hit pause and it pauses like the sound was coming out of my speakers. It is exactly what we want in terms of "delay". The sound quality is a little lacking (it sounds like there are little delays built in to parts of the songs), but it is close. I want you to have the log in case something changed (evolved?) that will help you figure out the delay issue. |
I am not sure.., but these are what could contribute to the delay:
|
I will keep making changes to decrease delay systematically.
- segment-time set to default. - Added -frame_size and -fragment_size equals to chunk_size. This reduced delay. Related to #61.
there are two different variables that are affected by this: 1) frame_size that is used by ffmpeg and avcon. frame_size = 32 * chunk_size. 2) buffer_size that is used by the Flask server. buffer_size = 2 * chunk_size**2 These changes are another attempt to find a solution for #61.
I have changed in |
Is it only on Linux? If other platforms have no delay, then it is probably the transport layer of the app. You may look at tcp tuning on Linux for better network performance. Running Lubuntu on a mini samsung laptop with Intel atom 1 G RAM, the delay is 1 s, streaming wav 24/96. My biggest problem now is sound quality. It doesn't sound hifi. I have been playing with the buffer size, and with 32768, it is close. I have also switched to sox which I find lighter than ffmpeg. |
For me, the delay is down to that both on macOS and Linux. I think 1 seconds is just fine. I was researching and even broadcasted TV has such delay. I can live with that.
Stupid question, but are the things you are playing high audio quality?. And are you reporting your findings with mkchromecast? I know that the answer must be What do you mean with buffer size? Is it this for you https://github.com/muammar/mkchromecast/blob/devel/mkchromecast/audio.py#L47? or something else?. If it is L47, I don't think buffer size sent to streaming devices would affect the quality of sound. I don't agree on that. The buffer size is just the chunk size that is sent by Flask server to the streaming device. Therefore, it already contains whatever the quality of the stream that is coming from ffmpeg is! (isn't it?). I am glad that you found a buffer size that is working for you though. |
I'm going to try it again @muammar using |
I'm facing the same issues with this
Please let me know if you want me to put all this in a new thread. |
That is just a problem in the case of Ubuntu because 16.04 is too old and at that moment there were no pychromecast debian packages nor its dependencies. ElementaryOS I have no idea, but I read is based on Ubuntu. Pychromecast, according to https://packages.ubuntu.com/search?keywords=python-pychromecast, is available from 16.10 (whatever the name it has that Ubuntu release).
That is because the setup is only for the macOS bundle.
From your log, everything was installed except |
I am a bit confused but not mad :), isn't 24 bit / 96kHz high quality? As far as I know, that's studio quality. So, yes, as you rightly guessed. Unfortunately, I can't get mkchromecast to run on my machine for some unknown reason. It starts but no sound. Since I use a mini laptop, I prefer to use lighter options because of low specs to optimize performance. For that reason, I stuck with stream2chromecast which is very lightweight, takes approximately 1 s to start, compared to mkchromecast that takes up to 15 sec for playback to start (when it was working). Sorry, if I confuse you by reporting findings from the former. As regards sound quality, buffer size does matter, as it affects both quality and latency. I have discovered that setting the buffer too low, the quality is low, and likewise when set too high. This is related to ALSA's buffer/period, encoder buffer and the chunked transfer sizes. In my asoundrc, I use 2048/4096 period/buffer, then use 16384/32768 for sox input/output. The sound is very close with these settings, but still not there. You could also ping the device to see how packets are arriving (ping -s pkt-sz -c cnt dev-ip) or tcpdump. I am going to try and get mkchromecast working again and see if it beats the current quality. |
Thanks @muammar. I installed
It does appear to start (at least in |
Please note: The post directly above was using |
This is on Unity.
Also note that on reboot, the images are back, but I had to manually |
Just a little input on delay. Don't you think the delay is doubled by using a loopback device, as ALSA would have to serve two "masters" at the same time by duplicating the audio? The delay seems to reduce by half if I use the onboard card directly. Can anyone confirm this? |
@xmbwd I think I have fixed that in bc99d50.
@ao-il I would say that probably yes, but I am using pulseaudio myself. Sorry that I didn't have the time this weekend to check the problem you reported. I hope to do something soon. |
Hi @muammar. Just checking back on this. I installed the latest version 0.3.7.1 today, but the sound delay is still an issue. I used the settings in your June 2 post to no avail. Any fixes to this increasing sound delay over time issue? |
So to summarize for clarity: The current issue is the increasing sound delay over time, right? |
On Sun, Nov 19, 2017 at 5:55 AM, Sam Bokai ***@***.***> wrote:
So to summarize for clarity: The current issue is the increasing sound
delay over time, right?
Yes, that is correct. It is difficult to make the delay not to increase
over time. It is something common when doing live streaming. Maximum delay
I have gotten has been 2 seconds when casting to Sonos speakers. But as
seen in this report, YMMV.
|
I am starting to believe that all these delays depend a lot on very specific things such as operating system, FFmpeg version, wifi router, etc. That is because what we are doing with this app is live streaming. In fact, when you google about live streaming it is mentioned that there is a delay associate it with it. When I stream at home I don't get more than 5 seconds delay for long periods of times casting. My assumptions would be wrong, and one way to confirm it would be to understand how Google Chrome does it. For the time being, I don't think there is an easy solution to this problem. |
Maybe someone should look into using WMM (https://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions) if it isn't already being used. |
With Chromium I get about a 2 second delay, with mkchromecast now 35 seconds... Pretty unusable and something is really wrong. |
Well, just think about it. If Google would not make delay that short being the hardware manufacturer that would suck. And still, it is 2 seconds. |
According to home-assistant/core#16319 this commit should help with delay. It helped me to go from 17 seconds to 3 seconds delay when using chromecast. Related to #221, #61 and probably #104.
If some of you are interested, please check out this b6d0b3b. |
Actually, Chromium has a delay of below a second after measuring it. With b6d0b3b I'm getting a delay of 27 seconds used in combination with |
Thanks for trying this out. The problem seems to be the I am sorry about this but unless this is fixed in pychromecast, chromium is a better option for you than mkchromecast. |
hmm, is there a pychromecast issue for this already? |
|
If the issue is in |
If I recall correctly, home-assistant's upstream is the same pychromecast's upstream. All that it is discussed in the thread above has to do with setting the right buffer (unsuccessfully) in |
First, thanks so much to muammar for his hard work in creating mkchromecast. Regarding the delays / lags: I was seeing >30s delays with the "parec" encoder and the "mp3" codec at 128 bitrate, when using either mkchromecast v0.3.8.1 (configured for pulseaudio) or pulseaudio-dlna v0.5.3 to cast to my Chromecast Audio from Linux Mint 19.1 (Cinnamon). Other settings gave me delays of >90s. The same delay applied to start, stop, pause, and volume changes. Switching to the even more-compressed ogg didn't help, even at the lowest bitrate. After much testing I was able to reduce the delay in mkchromecast to 3s, using the "parec" encoder and the "wav" codec. This was counterintuitive, since wav is much less compressed than mp3 or ogg. I still haven't been able to achieve the near-instantaneous response that I get when casting audio from VLC, or when casting audio from Google Chrome -- using the same Linux Mint 19.1 laptop, network, and Chromecast Audio device. So something must not be quite optimized in mkchromecast and pulseaudio-dlna. My (naive) hypotheses is that mkchromecast is just filling the Chromecast buffer with audio and commands in a serial manner, and the Chromecast is just reading that buffer in a serial manner and also somehow requiring the buffer to be completely filled (in terms of bits, rather than seconds). A less efficient codec like wav fills up the buffer with bits much faster than mp3, so we don't have to wait as long for the audio to start pouring out of the Chromecast. Is this what's going on? Again very naively (I know zero about the internals of Chromecast, DLNA, etc., and haven't looked at the code) -- if the above is somewhat correct, then somehow VLC and Chrome are doing something differently/smarter. Somehow they're allowing the Chromecast to start playing even before the buffer is full, and to register changes (pause, song change, volume change) immediately as if those commands were being passed straight through to the device, instead of being stacked onto the end of the long buffer and then seen only after a buffer delay. Is any of that plausible? If so, then maybe a solution to the delays in both mkchromecast and pulseaudio-dlna could be found by reaching out to the VLC folks, who seem to have eliminated the delay problem. (They have a different problem, which is that VLC doesn't yet pass volume changes through to the Chromecast.) |
It seems you might be using VLC's AirPlay 2 support. |
Trying to unify. See: #292 |
mkchromecast
is terrific. I note that in theKnown Issues
section you mention that the delay can be up to 8 seconds usingmp3
. I wanted to ask if there was some combination of settings (i.e.,backend
,format
, andsample rate
), that would reduce the delay to the shortest amount of time possible?My delay right now is about 3 seconds using
avconf
,wav
, and192000
. But I thought it might be helpful, to me and other users, to know what settings serve to reduce the delay. Thanks.The text was updated successfully, but these errors were encountered: