21 second delay with both node and ffmpeg (Mojave 10.14.6)

[MSteggles]

Hi, I've just installed mkchromecast. I can get output working with both node and ffmeg, both of which have 21s delay. Having a look it appears this is a problem others have had, but couldn't piece together if there is a definite fix? I've tried switching around sample rates, output formats, backends but it's always 21s. Cheers

[muammar]

You are right. I confirm this is happening for me too. But it is just with Chromecast. When I use my sonos system this delay is below 4 seconds. I honestly do not know how to fix this.

[fornellas]

Same for Linux + Chromecast Audio: 21s delay.

At first I thought this was related to Pulseaudio + ffmpeg generating delays. I did some simple test with:

parec --format=s16le | ffmpeg -loglevel panic -ac 2 -f s16le -ar 44100 -i - -ac 2 -f s16le -ar 44100 -

And the output delay when audio starts / stops is < 1s.

I also tried this:

mkfifo i.aac
parec --format=s16le | ffmpeg -loglevel panic -ac 2 -f s16le -ar 44100 -i - -ac 2 -f s16le -ar 44100 > i.aac
mkchromecast -i i.aac

with same 20s+ delay.

I did some testing with https://github.com/home-assistant-libs/pychromecast/blob/master/examples/media_example.py:

• The cast URL starts playing in ~1s (not 20s+).
• If I change it to mkchromecast's flask http://192.168.0.24:5000/stream, I see log the URL is reached in ~1s, but it still takes 20s+ to start audio.
• I tested http://192.168.0.24:5000/stream with curl, it seems to start streaming data instantly.

The only difference I see, is that the example plays the URL which serves MPEG-DASH, while http://192.168.0.24:5000/stream is serving the file directly.

@muammar I'm thinking that the solution here is to stream data with MPEG-DASH. Do you have any experience with different formats to say if this is a good route?

Edit: I've been playing with pychromecast examples: it seems that data is being streamed to Chromecast within ~1s, BUT, Chromecast stays with status BUFFERING for ~20s, and only then, it switches to PLAYING. I fiddled with pychromecast, setting stream type to NONE or LIVE (which defaults to BUFFERED) won't cut it.

[muammar]

@muammar I'm thinking that the solution here is to stream data with MPEG-DASH. Do you have any experience with different formats to say if this is a good route?

Good finding. I have no idea! I did this that decreased lag but is just a hack :(

https://github.com/muammar/mkchromecast/commit/30f4e85bf1220ea5534748adf65f77b35c1b255e

It went down from > 30 seconds to < 6 seconds on my MacBook pro.

[cmcinroy]

Looks like the related issues have been consolidated here. In that vein, just another point of reference: Mkchromecast v0.3.9, Fedora 33, kernel 5.10.7, GNOME 3.38.3 here. I was experiencing a delay of 10-20s casting to Chromecast audio. Setting preferences to ffmpeg/wav/44100 reduced the delay to the 3s range.

[ojdo]

Setting preferences to ffmpeg/wav/44100 reduced the delay to the 3s range.

This is the way. Also, this saves needless re-encoding of the data. Every stable wifi should be able to handle the ~1 Mbit/s stream, which is much for audio but still small compared to any video stream you might pipe through your local setup without issues.

---

Full reference: got my mkchromecast on Arch via yay mkchromecast (thanks AUR packagers!) and then launched mkchromecast -s --encoder-backend ffmpeg -c wav, selecting my "everywhere" speaker group. Switched to "mkchromecast" in KDE's audio output device settings. 3s delay on all speakers, without any fiddling. Nice!