Settings for shortest sound delay

[muammar]

Settings for shortest sound delay

[xmbwd]

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).

[muammar]

mkchromecast is terrific. I note that in the Known Issues section you mention that the delay can be up to 8 seconds using mp3. I wanted to ask if there was some combination of settings (i.e., backend, format, and sample rate), that would reduce the delay to the shortest amount of time possible?

Thank you very much for your interest in this application :).

My delay right now is about 3 seconds using avconf, wav, and 192000. But I thought it might be helpful, to me and other users, to know what settings serve to reduce the delay. Thanks.

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 nodejs, but I am not very skilled on node. I know about the existence of this https://github.com/fluent-ffmpeg/node-fluent-ffmpeg that should reduce delay a lot.

[muammar]

Thank you for the response (and the app).

:) thanks!.

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.

Casting a file? Or is there now a way to cast the audio from your computer?.

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).

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 node-webcast-osx-audio.

Oh, and if this helps, the delay increases over time -- even if I am not actively casting any sound.

I am aware of that one :(.

(I should note that my computer is connected via ethernet, but obviously the Chromecast is on wifi).

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.

[ao-il]

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?

[muammar]

I think the delay is caused by the server, from what I have experienced. Maybe an upgrade to python 3 would fix this?

The app works with python3, and it does not improve.

I have partially fixed the delay by delaying the audio at the playback app to allow the server to be ready.

One of the first things that is put ready is the webserver. That may not be the issue.

How does sending headers directly with the stream vs sending separately affect the delay?

That sounds as a good idea. But you know what?. Now that I have been using mkchromecast with the sonos I found the following:

192.168.1.182 - - [23/Apr/2017 16:59:04] "GET /stream HTTP/1.1" 200 -
pcastready ? _play_cast_ success
192.168.1.182 - - [23/Apr/2017 16:59:04] "GET /stream HTTP/1.1" 200 -

There are two calls from Sonos to mkchromecast?. Delay is always 1 second!.

[muammar]

Some information I found: https://plus.google.com/112885659993091300749/posts/cJVvqsnnkjV

[ao-il]

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.

[muammar]

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 stream_type = 'LIVE' but that changed nothing.

Do you refer to this currentTime parameter https://github.com/balloob/pychromecast/blob/35742b617231a62a34bc5b3e072d79c03a2d25fa/pychromecast/controllers/media.py#L214?.

[ao-il]

Not exactly but similar, since I used the one of stream2chromecast. I think it should be the one sent to the device playback app.

See def load(...)

[ao-il]

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..

""" Force playback immediately """
self.get_media_status()
if self.media_status is not None:
    media_session_id = self.media_status['mediaSessionId']
    resp = self.send_msg_with_response(namespace, {"type":"PLAY", 
    "mediaSessionId":media_session_id})

[ao-il]

Forget to mention that currentTime was left at 0.

[xmbwd]

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.

[ao-il]

I am not sure.., but these are what could contribute to the delay:

• Throughput/unstable wifi. Check with speedtest-cli. You need to have good upload and download speed.
• Execution delay. First, the sever needs to be up and running, and then we need to (launch, if not running already and) tell the cc device app to request and play the media. All these should happen in less than 1 second?
• Transcoding on the fly.

[muammar]

I have changed in devel the code a bit. And the delay, using mp3 that did it very badly, is < 2 seconds. I hope I am not dreaming.

[muammar]

The configuration shown below in Linux using ffmpeg has a very short delay.

[ao-il]

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.

[muammar]

Is it only on Linux? If other platforms have no delay, then it is probably the transport layer of the app.

ffmpeg on macOS was also somewhat affected by this. But the recent change made has alleviated the delay with that backend. I have < 1 seconds.

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.

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.

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.

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 yes for the first one and maybe for the second one, but just to be on the same page. Don't get mad at me :).

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.

[xmbwd]

I'm going to try it again @muammar using devel. Will let you know how it goes once there is some play time logged.

[xmbwd]

I'm facing the same issues with this devel as prior ones: dependency hell. Here are my steps, so you know what doesn't work on ElementaryOS Loki and Ubuntu 16.04:

1. I tried python setup.py and got these errors:

warning: no directories found matching 'doc/_static'
warning: no directories found matching 'doc/_templates'
warning: no previously-included files matching '.DS_Store' found anywhere in distribution
warning: no previously-included files matching '*.pyc' found anywhere in distribution
warning: no previously-included files matching '*.pyo' found anywhere in distribution
warning: no previously-included files matching '*.so' found anywhere in distribution
warning: no previously-included files matching '*.dSYM' found anywhere in distribution
warning: no previously-included files matching '*.dSYM/*' found anywhere in distribution
warning: no previously-included files matching '*__pycache__*' found anywhere in distribution
no previously-included directories found matching 'examples/*/build'
no previously-included directories found matching 'examples/*/dist'
no previously-included directories found matching 'examples/*/*/build'
no previously-included directories found matching 'examples/*/*/dist'
no previously-included directories found matching 'examples/*/*/*/build'
no previously-included directories found matching 'examples/*/*/*/dist'
Traceback (most recent call last):
  File "setup.py", line 73, in <module>
    setup_requires=['py2app'],
  File "/usr/lib/python2.7/distutils/core.py", line 111, in setup
    _setup_distribution = dist = klass(attrs)
  File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 269, in __init__
    self.fetch_build_eggs(attrs['setup_requires'])
  File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 313, in fetch_build_eggs
    replace_conflicting=True,
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 826, in resolve
    dist = best[req.key] = env.best_match(req, ws, installer)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1092, in best_match
    return self.obtain(req, installer)
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1104, in obtain
    return installer(requirement)
  File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 380, in fetch_build_egg
    return cmd.easy_install(req)
  File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 663, in easy_install
    return self.install_item(spec, dist.location, tmpdir, deps)
  File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 693, in install_item
    dists = self.install_eggs(spec, download, tmpdir)
  File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 873, in install_eggs
    return self.build_and_install(setup_script, setup_base)
  File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 1101, in build_and_install
    self.run_setup(setup_script, setup_base, args)
  File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 1089, in run_setup
    raise DistutilsError("Setup script exited with %s" % (v.args[0],))
**distutils.errors.DistutilsError: Setup script exited with error: This distribution is only supported on MacOSX**

2. I tried to install the requirements using pip install -r requirements.txt:

Collecting Flask==0.12.1 (from -r requirements.txt (line 1))
  Using cached Flask-0.12.1-py2.py3-none-any.whl
Requirement already satisfied: netifaces==0.10.4 in /usr/lib/python2.7/dist-packages (from -r requirements.txt (line 2))
Collecting psutil==5.2.2 (from -r requirements.txt (line 3))
  Using cached psutil-5.2.2.tar.gz
Collecting requests==2.13.0 (from -r requirements.txt (line 4))
  Using cached requests-2.13.0-py2.py3-none-any.whl
Collecting mutagen==1.37 (from -r requirements.txt (line 5))
  Using cached mutagen-1.37.tar.gz
Collecting PyChromecast==0.8.1 (from -r requirements.txt (line 6))
  Using cached PyChromecast-0.8.1-py2.py3-none-any.whl
Collecting setuptools==35.0.2 (from -r requirements.txt (line 7))
  Using cached setuptools-35.0.2-py2.py3-none-any.whl
Collecting PyQt5==5.8.2 (from -r requirements.txt (line 8))
  **Could not find a version that satisfies the requirement PyQt5==5.8.2 (from -r requirements.txt (line 8)) (from versions: )
No matching distribution found for PyQt5==5.8.2 (from -r requirements.txt (line 8))**

3. I tried installing your list of requirements manually (sudo apt-get install python2.7 python-pip python-pychromecast python-flask python-psutil python-setuptools python-mutagen python-gi vorbis-tools sox lame flac faac opus-tools) and got:
   E: Unable to locate package python-pychromecast

4. I tried installing python-chromecast from here and got a dependence error for python-protobuf. I've been down that road before, and it leads to bad places.

Please let me know if you want me to put all this in a new thread.

[muammar]

I'm facing the same issues with this devel as prior ones: dependency hell. Here are my steps, so you know what doesn't work on ElementaryOS Loki and Ubuntu 16.04:

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).

I tried python setup.py and got these errors:

That is because the setup is only for the macOS bundle.

I tried to install the requirements using pip install -r requirements.txt:

From your log, everything was installed except PyQt5. Therefore, you would only need to install it by: apt-get install python-pyqt5.

[ao-il]

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.

[xmbwd]

Thanks @muammar. I installed python-pyqt5 manually. I was just able to install pychromecast on 16.04 using the link here. But I get an error trying to run it:

Mkchromecast v0.3.8
Creating Pulseaudio Sink...
Open Pavucontrol and Select the Mkchromecast Sink.
Starting Local Streaming Server
[Done]
Traceback (most recent call last):
  File "mkchromecast.py", line 270, in <module>
    mk()
  File "mkchromecast.py", line 51, in __init__
    self.audio_linux()
  File "mkchromecast.py", line 68, in audio_linux
    self.start_backend(self.encoder_backend)
  File "mkchromecast.py", line 152, in start_backend
    import mkchromecast.audio
  File "/home/user/Downloads/mkchromecast-devel/mkchromecast/audio.py", line 21, in <module>
    from flask import Flask, Response, request
ImportError: No module named flask

It does appear to start (at least in PulseAudioVolumeControl), but I'm getting the same nulloutput problem as in another thread -- so I don't know which Chromecast it is connecting to. I tried using -h ipaddress, but that didn't seem to do it either.

[xmbwd]

Please note: The post directly above was using ElementaryOS. I was able to get the app working in Ubuntu 16.04. But only for a short while and the audio sounded like the chipmunks. And when I changed sinks, it went silent -- though pulseaudiocontrol shows it playing through mkchromecast. Aaargghh. Will log out and try again.

[xmbwd]

So the problem was with aac (will check on this later). I set the Audio Coding Format to mp3 and all is audible. Will let it run for a while to see if the delay increases and report back -- hopefully to close this topic.

[xmbwd]

I had an initial 2 second delay increase to 5 seconds after 1 hour of play. Not terrible, but would be great if the delay didn't extend. Here are my settings:

Backend:  ffmpeg
Audio Coding Format:  wav
Bitrate: none
Sample Rate:  44100

I'd like to try the aac in your settings but it results in silence. Let me know if there is another dependency I need to install for that?

Also, and this may because you never merged the commits, but the nulloutput issue remains in the devel branch. There is only one of them, but it shows as nulloutput in PulseAudioVolumeControl.

[xmbwd]

So I've confirmed that the delay continues to expand over time. I'm up to 7 seconds after about 7 hours of continuous play. This particular stream started with 0 seconds delay (which was pretty cool). Let me know if you'd like me to close this or leave it open.

[ao-il]

Just a hint about why this is happening. The use of segment time is not a good idea, as the delay with just accumulate and become larger over time.

[muammar]

So I've confirmed that the delay continues to expand over time. I'm up to 7 seconds after about 7 hours of continuous play. This particular stream started with 0 seconds delay (which was pretty cool). Let me know if you'd like me to close this or leave it open.

@xmbwd Thank you for this information, it is indeed very valuable. It means that there is a 2.77778 x 10⁻⁴ sec cumulative latency for each second your PC is streaming. That does not happen with my Sonos Speakers though, my ~0 seconds latency stays very stable during 3 hours of constant play (even pausing). It can go up to ~1 seconds at most.

I recently found this: https://www.boxcast.com/blog/this-is-why-your-live-stream-lags

I think I better understand now the problem. While it is true what @ao-il mentions about encoding and even segment time add latency (I have realized that is broken right now in mkchromecast and it has a default of 2 seconds in ffmpeg and can only be set to integers), the problem seems to also be related to the HTTP protocol for doing real-time streaming. Of course, there are other factors increasing the delay as mentioned in the link above.

I believe it is your call to close this report. The ideal thing would be to use another protocol to stream, but chromecast does not support RTP. I will once for all implement just what @ao-il said before of just copying the stream from pulseaudio or ALSA and pass it to the flask server when using ffmpeg/avconv. In that way instead of having 7 seconds in 7 hours we could decrease that to let's say 5 seconds.

I also found very interesting the words about bitrate. ABR may be also interest to implement, because right know is fixed bitrate.

[xmbwd]

Thanks @muammar. I'll keep open just until you implement @ao-il's suggestion. Just let me know which branch it is in, and I'll both test (if you want) and close this. I appreciate you sticking with this!

[xmbwd]

I also meant to ask about this error that I get when starting mkchromecast via pythonmkchromecast.py -t:

Could not save icon as '/run/user/1000/qt-tray-iconcache-qM9e5H/hicolor/16x16/apps/8589934592.png'
Could not save icon as '/run/user/1000/qt-tray-iconcache-qM9e5H/hicolor/22x22/apps/8589934592.png'
Could not save icon as '/run/user/1000/qt-tray-iconcache-qM9e5H/hicolor/32x32/apps/8589934592.png'
Could not save icon as '/run/user/1000/qt-tray-iconcache-qM9e5H/hicolor/48x48/apps/8589934592.png'

The visual result is that the tray icons is missing.

I didn't want to post a separate thread, because I thought it may just be in devel. If not, please let me know, and I'll start a new thread.

[muammar]

@xmbwd This is related to this #29 I think!. Thanks for posting this log, I haven't been able to fix this problem yet. Is this KDE?.

[muammar]

By the way, does it work if you use sudo?.

[xmbwd]

This is on Unity. mkchromecast doesn't fully start using sudo and the devel branch - at least not from my /home/user directory. It gets this far:

Mkchromecast v0.3.8
Selected backend: /usr/bin/parec
Selected audio codec: mp3
Default bitrate used: 192k
Default sample rate used: 44100Hz

Also note that on reboot, the images are back, but I had to manually sudo rm /tmp/mkchromecast.pid.

[ao-il]

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?

[muammar]

Also note that on reboot, the images are back, but I had to manually sudo rm /tmp/mkchromecast.pid.

@xmbwd I think I have fixed that in bc99d50.

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?

@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.

[xmbwd]

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?

[sambokai]

So to summarize for clarity: The current issue is the increasing sound delay over time, right?

[muammar]

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.

[louwers]

The configuration shown below in Linux using ffmpeg has a very short delay.

I'm having a delay of more than 10 seconds with this streaming to Chromecast Audio.

[ChristiaanDev]

The configuration shown below in Linux using ffmpeg has a very short delay.

I'm having a delay of more than 10 seconds with this streaming to Chromecast Audio.

Same, sometimes I feel like the delay is more around 20 seconds. Using the exact same settings, also using a Chromecast Audio.

[muammar]

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.

[qwertychouskie]

Maybe someone should look into using WMM (https://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions) if it isn't already being used.

[louwers]

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.

With Chromium I get about a 2 second delay, with mkchromecast now 35 seconds... Pretty unusable and something is really wrong.

[muammar]

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.

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.

[muammar]

If some of you are interested, please check out this b6d0b3b.

[louwers]

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 mkchromecast -c aac --encoder-backend ffmpeg. I appreciate your efforts.

[muammar]

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 mkchromecast -c aac --encoder-backend ffmpeg. I appreciate your efforts.

Thanks for trying this out. The problem seems to be the stream_type not being set correctly by pychromecast. This makes sense to me because when I stream to my Sonos I don't get this problem. However, yesterday doing tests with my Google Home Hub delay was about 20 seconds.

I am sorry about this but unless this is fixed in pychromecast, chromium is a better option for you than mkchromecast.

[pasikarkkainen]

hmm, is there a pychromecast issue for this already?

[muammar]

hmm, is there a pychromecast issue for this already?

home-assistant/core#16319

[qwertychouskie]

If the issue is in pychromecast itself, shouldn't it be reported at https://github.com/balloob/pychromecast?

[muammar]

If the issue is in pychromecast itself, shouldn't it be reported at https://github.com/balloob/pychromecast?

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 pychromecast.media_controller.play_media. I agree that they should raise that issue in pychromecast because that seems to be the source of the delay.

[AndrewWittenberg]

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.)

[polyzen]

It seems you might be using VLC's AirPlay 2 support.

https://support.sonos.com/s/article/1230?language=en_US

[muammar]

Trying to unify. See: #292