Streaming Latency about chromecast-desktop-audio-streamer

[SamDel]

There are two kinds of lag:

1. Lag between devices when playing the same stream
When streaming to a group the lag between devices in the group is zero. When streaming to individual devices you can have lag.

2. Lag between the desktop and the device
The lag between the desktop and the device (or group) depends on the stream format that's selected on the options tab. The device takes a ~300k buffer before it starts playing.

For me the lag between the desktop and the devices/groups is:

• When streaming in wav format: < 5 seconds
• When streaming in mp3 320 format: < 10 seconds
• When streaming in mp3 128 format: > 20 seconds

[elibroftw]

I recently added live audio support on my music player. To reduce the lag there were a couple of things I needed to do.

1. Specify to the chromecast that the source url is a stream and should not be buffered.
2. Force the chromecast to start playing once it's status says that it is playing even though it isn't
3. Keep track of the time it took between telling the chromecast to play and after you told the chromeast to forcefully play
4. Take this time and in your server code, instead of getting the latest system audio, slowly time.sleep(min(lag, 0.25)) before getting the latest system audio.
5. Make sure that the time between each time.sleep() call is at least 1 second.
   I got my lag from 10s to <1s this way.
   I linked my code that slowly removes the lag, you might have to do some scrolling in the future.
   https://github.com/elibroftw/music-caster/blob/master/music_caster.py#L601
   @starfishpatkhoo if you just want to just play music on the chromecast, check out my music player https://github.com/elibroftw/music-caster/releases.
   BTW I used to use ChromeCast-Desktop-Audio-Streamer myself but I hated the lag so I was inspired to make my own music player.

[SamDel]

Thanks! It is not really possible to synchronize audio and video with this application.

The only thing you can try is:

• Go to the options tab.
• Put the stream format on wav.
• Check 'Show the lag control (experimental)'.
• Then go to the main tab and drag the lag slider to the left side and keep it there for a while.
• When you start hearing drop-outs the buffers are empty, the lag is minimal and audio quality is poor. You can then experiment to get the slider in the best position.

I don't think there's a good way to get minimal lag.

[SamDel]

Thanks @elibroftw,

So the first x (=device playing - command play) seconds you're 'corrupting' the stream by not sending all the audio that's playing to the device. (which causes the buffer on the device to reduce). Do I understand it right?

I tried something similar with the lag control long time ago, but this is a bit smarter. I'll try to implement it later!

[GrahamDLL]

I get good sync by putting Chromcast Audio devices in groups in the Google Home app. I don't know whether this is relevant to syncing video and audio.

[stevorr]

Getting 16 second lag on Windows 10, tested with and without groups.

[jeppenodgaard]

Do you think increasing the sampling rate could decrease the latency?

[SamDel]

Yes, I think so.

When the size of the audio gets bigger (less compacted) the latency decreases (only when streaming in WAV format). I'm not sure how much it can be decreased, but you can try!

So, increasing the sample rate, bits per sample, number of channels , etc., should change the latency.
You can also have a look at the WAV header if you want to play with it.

Let me know!

[Joshndroid]

I have noticed just with initial playing that while watching live sports i can't seem to get the audio to sync. I have played with the device buffer (in seconds) and realistically it makes no discernible difference. I am not sure how the app actually handles audio data but is it possible to just have it run as a continuous audio stream, as in a direct pipe from audio out (irrespective of if there is actually audio coming out or not)? It seems at present it recognizes that there is audio from a stream source, thinks about it, then sends it off to the device (chrome cast audio). My post may be silly, as i said i am unsure how it handles the audio stream, but it just seems like its almost laughable out of sync.. Cracking program in of itself however, for music, its awesome!

[SamDel]

Thanks!

You can't use this tool to play the audio on your Chromecast Audio device in sync with the video on your desktop.

When live sports is playing, the audio is captured by this tool. Then there's a (very small) buffer in the application, the audio is send to the device which also keeps a (bigger) buffer. Meanwhile the video continues to play. You will always have a lag of at least ~2 seconds.

[oucil]

I'm also getting a >15s lag on Windows 10 when set to WAV, and it was closer to 60s on mp3 320. I'm on a 6core/12thread i7 with 32GB ddr4 ram, so it's not the machine. The device buffer in options is set to 0, but I've tried it at 5s as well, no difference it seems. I'm only streaming to a single device (Vizio TV w. Chromecast support). Both are using wired network connections on the same network.

[SamDel]

There's a fix for the lag in 2.7.1. Can you try that one? Can you post the logs if the lag stays the same? (I noticed myself the built-in Chromecasts are not as responsive, compared to the standalone devces.)

[FA-Bubba]

I am using version 2.7.1
I have an external speaker connected to my PC which is usually off, but when I need to have sync'd audio (e.g.: If I am playing a video), I turn it on. Previously, this always worked for me, but recently, I cannot get any audio from the speaker, or even from the PC's built-in speakers.

What can I change to restore audio to my speaker when DAS is streaming to my Google Devices?

Thanks!

[SamDel]

Should work when DAS is streaming, maybe check the drivers for the speakers?

[FA-Bubba]

FIXED! Some process had slid the speaker volume to zero! Not sure how that happened, but I didn't notice since that didn't affect the DAS volume.

[amergin]

Following. The program is wonderful but I'd really like to reduce the streaming latency as well. Over 10s lag (on mp3 320kbps quality) is kinda annoying when you're mainly using the software to cast music, and sporadically choose to flip through catalog of different songs. I don't expect to able to sync video audio, but a lag of 2-5 seconds should be viable? What is Chrome browser's cast feature or Airparrot or Airfoil doing differently, they usually have a relatively short lag?

[SamDel]

The difference with the tools you mention is that they don't play live streams but recorded audio or internet streams. That way the (initial) device buffer (~350k) can be filled right away.

This tool captures the audio live from your desktop. When you use mp3 320kbps (40000 bytes/second) it takes 350k/40k=8.75 seconds before the initial device buffer is filled. So the audio that's captured now is played over (about) 9 seconds on the device. With WAV & mp3 128kbps you can do a similar calculation.

I don't know of a way to reduce the buffersize the device uses.

[oucil]

What about a logarithmic increase in buffering packet sizes until it reaches the target ~400KB, but start playing after the first packet? I haven't examined the course at all, just brainstorming.

[amergin]

The difference with the tools you mention is that they don't play live streams but recorded audio or internet streams. That way the (initial) device buffer (~350k) can be filled right away.

This tool captures the audio live from your desktop. When you use mp3 320kbps (40000 bytes/second) it takes 350k/40k=8.75 seconds before the initial device buffer is filled. So the audio that's captured now is played over (about) 9 seconds on the device. With WAV & mp3 128kbps you can do a similar calculation.

I don't know of a way to reduce the buffersize the device uses.

That is not entirely true for Airparrot. I can capture the desktop audio with that software, and the playback starts with a less than 2 seconds delay. So it's not a predefined Internet stream or prerecorded audio, but an unknown continous stream from desktop.

With Airfoil and Airparrot, I feel as though their audio quality is inferior to this software.

[starfishpatkhoo]

I have used Airfoil, Airparrot, Bubble UPnP and even various frankenstein combos of VLC + batch scripts + Python + NodeJS etc etc - all in order to cast my MP3 library (mostly in MusicBee) to my Google Home devices around my house.

ALL of them have some delay of some kind, because buffering is unavoidable. The way Chromecast works is the cast device will open a stream from the source. In order to ensure there is no drops in playback, some kind of buffering is required. This is more obvious when you need to synchronise video to audio. The "2 second delay" is a 2 second buffer (at least). In Desktop Audio Streamer, you can choose how much of a buffer you want. YMMV the number of devices you have, your network performance, your PC performance, etc etc etc.

Conclusion after my extensive testing of all the other software products, Chromecast Desktop Audio Streamer works the best, and is the most stable. In fact, I sometimes even combine it with Voicemeeter to playback audio in other rooms in my house AND my PC speaker at the same time (although it is not fully synchronised - I need to muck around with Voicemeeter's delay :)

[SamDel]

What about a logarithmic increase in buffering packet sizes until it reaches the target ~400KB, but start playing after the first packet? I haven't examined the course at all, just brainstorming.

It's the buffer on the Chromecast device. I don't think you can change it's behaviour. Odd thing is that it looks like the buffer has the same size (in bytes, not seconds) for all file formats, maybe I'm doing something wrong there.

[SamDel]

That is not entirely true for Airparrot. I can capture the desktop audio with that software, and the playback starts with a less than 2 seconds delay. So it's not a predefined Internet stream or prerecorded audio, but an unknown continous stream from desktop.

With Airfoil and Airparrot, I feel as though their audio quality is inferior to this software.

I forgot to mention that I didn't try Airparrot myself. Is it also possible to capture audio, and stream to a Chromecast device with Airparrot? Their site says it's only for AirPlay-enabled devices.

[starfishpatkhoo]

I forgot to mention that I didn't try Airparrot myself. Is it also possible to capture audio, and stream to a Chromecast device with Airparrot? Their site says it's only for AirPlay-enabled devices.

Yep, Airparrot does support Chromecast devices from Windows.

https://www.airsquirrels.com/airparrot/features/win

[elibroftw]

Not exactly corrupting. I'm just not sending anything for max 0.25 seconds at a time until the delay time I calculated becomes less than 0.25s or something. The Chromecast then stutters a couple of times since the data it's buffering is now 0.25 seconds newer each time I do the time.sleep

[SamDel]

I guess the stuttering isn't a big problem when it's only at startup for a couple of seconds!?
You're only supporting wav isn't it? I remember getting really nasty sounds when doing something similar with mp3.

[elibroftw]

Yes I only support .wav, mostly because I have no idea how to convert wav data to mp3 in Python without using ffmpeg

[hibikijoji]

@SamDel I'd like to contribute to this issue as I seem to be able to replicate it.

When I boot up from Windows and make the first-time connection while no music is playing, DAS seems to negotiate with the speakers. Speakers at this point are connected in a random sequence (important) indicated by their connection sound notification. The most noticable part of the initialisation process is that the 'Buffering...' seems to hang around for a while until it progresses to playing. At this stage, my latency seems to be around 9 seconds, which makes me think that it's connection as mp3 rather than wav.

In reponse to this issue, I re-initialise by cycling between mp3 320 and wav a couple of times until the latency finally drops to 2 seconds, which I find acceptable. Most notable at this stage is: 1) speakers successfully negotiate at the same time , indicated by the sound notification. 2) the intialisation process is relatively quick.

For now, I'm ok with doing this every time I boot. I hope though that this might help resolve the issue that many of us seem to be experiencing.

NB: Thank you @SamDel for developing this software! I currently find no software that comes close - it allows me to equalize all my speaker which makes a whole world of difference (much richer, no irritating frequencies). I would like to donate if there was a facility for that. Please continue with the development 👍 It would be sad if this software lost support 😢

[SamDel]

Thanks @hibikijoji.

I can't really reproduce. I did some tests restarting DAS, Windows and/or the device but only one time (can't reproduce) I had simular behaviour. For you it's every time, right?

When changing the stream format all devices are stopped and started again, and the application buffer is cleared (here and here in code). So doing so can affect the application buffer, it can also be the devices/groups respond faster after a couple of times.

You're streaming to a group, right? (or multiple groups?) How much devices per group? Are you also booting the devices or only Windows?

[hibikijoji]

Thanks for your prompt response @SamDel ! Much appreciated.

I can confirm that I am streaming to a Google Home Group that consists of 4 nest minis and 1 chromecast (hardware HDMI audio split to 3.5 mm then to sizable bluetooth speaker). As per screenshot above, when I boot into windows, DAS starts but does not automatically boot up devices.

I have attached the log of the typical steps it takes for me to setup DAS with a windows session. With my settings set to previous post, I did the following:

1. Click on the play sign of my group (sometimes a couple of times if it's stuck on a grey 'Connected')
2. Test if audio has unacceptable lag (usually 9 seconds).
3. If so (which is almost always), flick to mp3 320 and back to wav; then test until lag becomes acceptable (around 2 seconds, which is typical wav)

Let me know if I can provide more data.

NB: On a side note, the current version doesn't seem to save setting if the minized tray setting is ticked.

EDIT: Forgot to upload the log file
Debugging.txt
🤢

[SamDel]

Have you also tried to stop/start a group multiple times? Does that affect the lag?

NB: On a side note, the current version doesn't seem to save setting if the minized tray setting is ticked.

That will be fixed in the next version, see this issue.

[hibikijoji]

Have you also tried to stop/start a group multiple times? Does that affect the lag?

I have tried to start/stop the group about 10 times. It has not improved the latency.

After the 10 times, I cycled through wav and mp3 twice and it fixed it. I have attached the logs for your reference.

debug - 10x.txt
debug - after 10x cycling 2x.txt

The notable thing about this all is that 1) I didnt hear the Google Home connection chimes to each of my speakers when I start/stopped the group. The chimes only happened when I cycled wav and mp3. The group only showed 'idle' when it stopped. 2) the last connection (the successful one) hardly showed 'buffering' and went to 'playing'.

Let me know if you want further tests done @SamDel

[SamDel]

I think the only difference between stopping/starting and changing the stream format is that the application buffer is not cleared in between (here).

Can you try 3.1.10.zip? I changed the default buffer size from 350000 to 35000 in that version (here).

[hibikijoji]

Can you try 3.1.10.zip? I changed the default buffer size from 350000 to 35000 in that version (here).

I think you're onto something! Tested it out and now consistently getting ~9secs of delay 😂 The main difference i've noted is that it now consistenly says 'Buffering...' for about 9 secs as well (compared to near instant when the delay is normal).

Thanks @SamDel for your hard work. Let me know you'd like me to try another version.

[SamDel]

That doesn't sound as an improvement 😉.
What happens (in 3.1.10) when you change 'Device buffer (in seconds)' to 5, 10 or 15 seconds?

[hibikijoji]

Sorry about leaving you midway through the thread. Went to sleep :X

What happens (in 3.1.10) when you change 'Device buffer (in seconds)' to 5, 10 or 15 seconds?

If there is no 'buffering...' during connection (which leads to 2 sec delays), I get 5, 7 and 10 seconds delay respectively.

If there is 'buffering...' during connection, I get 9 seconds delay irrespective of what buffer I set.

Another thing I noticed with 3.1.10 is that during the first connection after windows bootup (manual), I get 2 seconds delay and no 'buffering...' during connection. This might line up with your application buffer hypothesis.
EDIT: This no longer works lol!

[hibikijoji]

Here's how DAS typically connects now in 3.1.10 https://streamable.com/fdn5r7 Logs attached.
debug - 3.1.10 typical connect.txt

What I find interesting @SamDel is that it now goes from buffering to playing in quick succession; then back to long buffering (usually the same length as the delay - 9 seconds). The first instance is what typically happens when I have 2 second delays.

[SamDel]

That's with 'Wav' as stream format, isn't it?

[hibikijoji]

That with 'Wav' as stream format, isn't it?

That's correct.

[SamDel]

I'm testing with 3.1.11. The 'Device buffer' dropdown is 1,2,3,...,15 in that version. For me the latency is between 2 to 6 seconds (wav) when I change the buffer between 0 and 15. Is there an optimal value for you? ( You have to stop/start the stream after you changed the device buffer value!)

[SamDel]

Another good test is to put the devices next to each other in the same room. To make sure it's not a bad connection of one of the devices that causes the lag.

[hibikijoji]

Another good test is to put the devices next to each other in the same room. To make sure it's not a bad connection of one of the devices that causes the lag.

Great. I'll test soon and get back to you. For the record, my 5 speakers are in the same room that is next to the WIFI 5 router.

[hibikijoji]

Sorry @SamDel! had to tend to a few things.

The odd thing is that every delay from 0 to 9, I get 9 seconds delay without any variance! The typical 'playing...' then 'buffering... for 9 seconds, then 'playing...' again.

When I reach to 10 however, i sometimes get a straight, upfront 'playing...' status. With it, audio plays with about 3250 ms of delay (i use a chrome extension to sync audio with video). Note that I say sometimes - when I reconnect by pressing the play buttons with everything else remaining the same, i end up falling back to 9 seconds with the typical 'buffering...' issue.

Sames happens to 11 with the first connection (no connection chime either interestingly enough)

With 12, the connection connects without buffering! repeatable by rebooting and reconnecting a number of times! It does have a delay of 4250 ms.

13 - Same as 12. 4750 ms. Repeatable

14 - 5000 ms. Repeatable.

15 - 5500ms. Repeatable.

Hope that's insighful @SamDel 😊

[SamDel]

No hurries. Thanks, very helpfull!

I have similar behaviour, but different numbers.
No buffering from 8 onwards (delay ~3 seconds). With 12 the delay is ~4 seconds.

With 12 in version 3.1.11 the application keeps an audio buffer of 12*40k=480k bytes. This buffer is send to the device when you start streaming to make sure it starts playing right away. Before it was 350k.

In reponse to this issue, I re-initialise by cycling between mp3 320 and wav a couple of times until the latency finally drops to 2 seconds, which I find acceptable.

Can you still get the 2 seconds delay (with 12) you had before?

[hibikijoji]

Can you still get the 2 seconds delay (with 12) you had before?

Sadly, I am unable to get the 2 second delay again with either the previous technique or any other for that matter. This might have to be the acceptable compromise as it will provide all users with an acceptable amount of delay (not 9+ seconds lol). Not to mention a consistent amount of delay so that we can set specific software to accomodate for the latency.

I am happy if you release it as it is now. Of course, any improvements are welcomed 😊

[SamDel]

Is it clearer to you when I change the device buffer dropdown from seconds to bytes?

I'm thinking on a way to automatically adjust the buffer to the configuration. Something like: When 'Buffering' messages are received then increase the buffer...

[hibikijoji]

Is it clearer to you when I change the device buffer dropdown from seconds to bytes?

Hmm. I think from a user standpoint, its hard to correlate both kb and seconds with the actual delay we're experiencing (no major changes from 1-11, then suddenly 4 seconds change on 12). If you were to sacrifice more delay options to significant points where the user experiences significant change, that would be good.

I'm thinking on a way to automatically adjust the buffer to the configuration. Something like: When 'Buffering' messages are received then increase the buffer...

That would be great if it can be offered as an option! For me now though, having a consistent delay thats not too long allows me to set my apps to a static delay. I'd prefer that to a shorter but varying delay at bootup.

[SamDel]

In 3.1.12.zip there's a default (minimum) buffer of 350k as in 3.1. From that point on you start to experience significant change. For me the 350k is enough. You probably have to add 3 - 4 seconds in the device buffer dropdown now. Maybe I add the automatically adjust option later.

Good enough for a new release? The only change is (compared to 3.1) that there are more options in the device buffer dropdown.

[hibikijoji]

Good enough for a new release? The only change is (compared to 3.1) that there are more options in the device buffer dropdown.

This is fantastic! Well done. I'm on 1 second device buffer with 3.5 second delay now. Thanks for making the debugging experience enjoyable. I hope more people take this up now that the latency issue has been managed.

[SamDel]

I think we should set the device buffer to 4 seconds for new users for the best overall performance!?

And we have to add a line about it to the homepage and the wiki, how would you describe what we learned here in one or two lines?

[hibikijoji]

Ahh! thanks for waiting @SamDel

I think we should set the device buffer to 4 seconds for new users for the best overall performance!?

Not sure 🤔 If it provides the most stable experience for others, then sure!

And we have to add a line about it to the homepage and the wiki, how would you describe what we learned here in one or two lines?

Not all home setup are stable on the default device buffer settings. Please set it to a setting where your speakers produce the appropriate delay:

- When streaming in wav format: < 5 seconds
- When streaming in mp3 320 format: < 10 seconds
- When streaming in mp3 128 format: > 20 seconds

Post a message in discussions if you still have a problem.

[SamDel]

Thanks, I added the lines to the homepage and the wiki.

Not sure 🤔 If it provides the most stable experience for others, then sure!

Not sure either, but I think it's more stable then zero...

I will make a new release in a couple of days.

[hibikijoji]

I will make a new release in a couple of days.

Thanks @SamDel ! it has been a wonderful experience debugging with you. Keep up with the good work :)

[SamDel]

Version 3.2

i use a chrome extension to sync audio with video

@hibikijoji Which extension? How does it work?

I keep this thread open for feedback...

[hibikijoji]

@hibikijoji Which extension? How does it work?

It's called YouTube Audio/Video Sync, which is for Youtube @SamDel . This suits my needs for videos on browser generally speaking. If there's any additional requirements, I use VLC.

[SamDel]

Version 3.4 has a wav 24bit option: more bandwidth, less latency.

[hibikijoji]

Version 3.4 has a wav 24bit option: more bandwidth, less latency.

thank you, thank you, thank you. Now on 0 Device buffer with 2250 ms latency! :DDDDDDDD