Improve delay

[lars18th]

Hi,

With the current implementation, using it in native mode in Debian 7 x64 (compile and running it manually, like described in http://www.reddit.com/r/Chromecast/comments/54wz7x/aircast_airplay_to_chromecast_audio_bridge/dara938/ ), in this scenario the delay is...

Around 10 seconds between actions in one iPod Touch and the audio played in one Chromecast Audio.

It's possible to improve this delay? My objective is achive around 4-5 seconds (similar to an AirportExpress).

Ideas?

[lars18th]

Hi,

In order to improve the latency I suggest to add the function to use the WAV/PCM format (optionally) instead of FLAC. So, add the parameter "-wav" (or "-flac").

I already checked that the FLAC compression level in the encoder doesn't increases the delay.

[eugenet8k]

Hi @lars18th, I was able to install aircast on Raspberry Pi and to stream audio from iOS device to Google Home speaker through AirPlay. There is a little delay for volume up/down for about 2 sec, not 10 seconds. So I would say the audio part works great, but my problem is video...

I would like to watch video on my iPad and stream audio to Google Home. With the default aircast setup I have that 2 sec delay between video and audio. I assume that's per AirPlay spec, but I wonder if there is a way to sync video and audio in aircast?

[lars18th]

Hi Eugene!

I can't help you with video, as my target is only the audio capabilities.

However, after more tests I mesured these values:

• AirPlay: ~1sec. delay between the client and the Aircast (Shairport) server.
• FLAC: ~0.5sec. delay for reading from the stdout (Shairport) and execute the stream compression.
• Chromecast: ~5.0-8.0sec. delay for HTTP Live streaming of the FLAC file.

So, the biggest part is the delay of the Chromecast... bad news! As the "global input" delay is around 2sec.

In any case, this latency is only for the AUDIO. The INTERACTION is more fast, as the reading buffer of the Chromecast isn't part of the chain... For commands, like STOP, PAUSE, VOLUME the delay is only de global input (Airplay+Shairport process). The, I suggest to the developer to try to process ASYNC the commands. Then a simple PAUSE, PLAY or VOLUME change will be more user friendly (initial play and seeking will continue to be slow).

And FYI, I do all tests with:

• Aircast in a Linux x64 server.
• Chromecast Audio.
• iTunes in a Windows x64 machine.

I commet this to clarify that servers and clients have sufficient performance. Regards!