[danieldhaiti]

Bug. Mirror with audio, play a YouTube video (AirPlay HLS), return to mirroring: video comes back, audio stays silent until mirroring is restarted on the phone.

Cause. The AirPlay video connection stops the mirror's audio receiver and timing (raop.c). The phone keeps sending audio and returns with a mirror SETUP only, so nothing restarts them. The relaunch at the video's start also pauses the audio renderer, and only an audio SETUP starts it again; our logs show "start audio connection" (the NULL-renderer branch) at every return.

Fix (your direction). Leave raop_rtp and raop_ntp running. The relaunch at HLS start still pauses the audio renderer; the HLS-end reset (RESET_TYPE_HLS_EOS only, not the NOHOLD fall-through, so a new client still gets a fresh renderer) starts it again with the audio SETUP's codec, and the relaunch loop leaves it alone that once (keep_audio). Packets arriving into a paused renderer are dropped before the base-time check; data_len == 0 compared the pointer.

Tested. Builds on Ubuntu 26.04, no new warnings. Our appliance runs the same shape; the earlier shape (restart at the mirror SETUP) passed three YouTube-to-mirror returns live. A phone run of this exact shape is pending (no phone at hand today), so still a draft.

🤖 Generated with Claude Code

[fduncanh]

Yes I think you are right. Right now we shut down the raop_rtp audio thread and the ntp_thread when switching the video pipeline. A video shutdown was done as a simple way to cleanup the previous video window, but there really is no need to to do that for the NTP threads and the audio thread, maybe just stop the pipeline.

[fduncanh]

the relaunch loop in main() calls audio_renderer_stop() after an HLS session

I think this is done when the HLS starts, not stops

[fduncanh]

I need to understand better what you want to do.

Just give a precise recipe to demonstrate what you think is the issue. as in "do this, then do that, then do this: what I want to happen is...., what actually happens is .... "