Question about the initial handshake ... tooks some seconds?

[Hofyyy]

Hello,

I have round about a delay from 10 secondsduring play and it does not matter really what is configured via latency (500:0).

I found in the logfile (loglevel Debug):

• The airplay stuff is more or less done immediately in 11:42:53
• 11:42:53.087415 - I see a flush which will be skipped.
• 11:42:53.167711 - I see queued commands ... -> CastSimple:211 [0x84ad0]: Queuing PLAY ... Then I see "buffer_put_packets every 4 Seconds, which looks good. (11:42:53, 11:42:57, 11:43:01)

But the first _buffer_get_frame starts at 11:43:01, which is 8 seconds later, and direct with an error message. [11:43:01.843320] _buffer_get_frame:918 [0x6ed056b0]: Buffer overrun 1093

After this it seems to be ok more or less.

Could somebody check the attached log? Maybe Airplay changed a little bit or the chromcast implementation from my "Raumfeld" systems?

Best regards Sebastian slow_start.txt

[philippe44]

The culprit seems to be with the speaker itself when it launches the receiver. In CC, you need to load & launch the application that will be in charge of processing audio/video. Each vendor can have their own, and Google signs them, this is the way to have (e.g.) Netflix protect their content without telling Google how. There is also a default receiver that can do audio/video and is provided by Google. This is the one I'm using. It seems that your speaker is taking a huge (6s) amount of time to load/launch it and meanwhile, AirPlay is sending audio so you have a buffer overflow, before the speakers (finally!) do an HTTP request to grab the audio.

[Hofyyy]

Hello Phillippe44,

Thank you for the quick reply. I will test some direct stuff with google chromecast and the Raumfeld System, to see how fast it is. In parallel i would like to check if their might be a problem with the WakeableSleep(0) in function CastSocketThread(). I did not completely understand how the handshake did work, but maybe its not 100% save and one wakeup gots lost. So i would try (as a hack to change it to WakeableSleep(250), if the value is the timeout.

But I am not able to compile the toolchain on Macos and not on the Rasberry arm system. I got errors for memcheck.c ixml.h. I will check if I will find some help for the needed toolchain on your side. Otherwise, maybe you can give me a hint.

Thanks in advance from germany.

[philippe44]

If you want, send me a PM where I can put a zip of my source tree (all the rest except AirConnect itself).

[philippe44]

Re WakeableSleep, normally it waits on a pthread_cond and I use broadcast, no signal, so all waiting threads should be woken up, not just one

[Hofyyy]

Hello,

thanks for the offer, that would be great. I am new on Github sorry for that I do not find a PM feature. Could you post a dropbox link or something like that which you could disable after 1 day?

First direct test with my "Raumfeld" system worked in less then one second. I think they "could be to fast". I agree how that worked. I need to lock all wakeups and all sleeps.

Think about the wakeup will come very short before the sleep. Then he will sleep forever, because it is not a semapore which will count. So it might be that the answer is already there .. Or other stuff. If I am able to compile it i will debug a little bit.

Best regards

[Hofyyy]

Or do you have a https://temp-mail.org/de/ or something like that I can send you my contact data to?

[philippe44]

I think that one libahe7366@retqio.com can work if I understand well this system