From 2427cf7d6b8cf4fdcc9952e1e6ef2644272c6514 Mon Sep 17 00:00:00 2001 From: Sanchayan Maity Date: Tue, 1 Apr 2025 17:34:15 +0530 Subject: [PATCH] gstpipewiresrc: Fix re-linking for audio For a pipeline like below, we might want to dynamically switch the audio source. gst-launch-1.0 -e pipewiresrc autoconnect=false ! queue ! audioconvert ! autoaudiosink On switching to a different audio source, any one of driver, quantum or clock rate might change which changes the return `result` value of gst_pipewire_clock_get_internal_time. This can result in the basesrc create function incorrectly waiting in gst_clock_id_wait. We post clock lost message to fix this. In the case of gst-launch, it will set the pipeline to PAUSED and then PLAYING to to force a new clock and a new base_time distribution. Without the clock lost message, the following can be seen before re-linking to a different source 0:00:30.887602864 79499 0x7fffe8000d40 DEBUG GST_CLOCK gstsystemclock.c:1158:gst_system_clock_id_wait_jitter_unlocked: entry 0x7fffd803fad0 time 0:00:17.024565416 now 0:00:17.024109144 diff (time-now) 456272 after re-linking to a different source 0:00:45.790843245 79499 0x7fffe8000d40 DEBUG GST_CLOCK gstsystemclock.c:1158:gst_system_clock_id_wait_jitter_unlocked: entry 0x7fffd803fad0 time 0:00:31.927694059 now 0:00:17.066883864 diff (time-now) 14860810195 With the clock lost message, the following can be seen before re-linking to a different source 0:01:09.336533552 89461 0x7fffe8000d40 DEBUG GST_CLOCK gstsystemclock.c:1158:gst_system_clock_id_wait_jitter_unlocked: entry 0x7fffd803fad0 time 0:00:58.198536772 now 0:00:58.197444926 diff (time-now) 1091846 after re-linking to a different source 0:01:21.659827958 89461 0x7fffe8000d40 DEBUG GST_CLOCK gstsystemclock.c:1158:gst_system_clock_id_wait_jitter_unlocked: entry 0x7fffd803fad0 time 0:28:24.853517646 now 0:28:24.853527204 diff (time-now) -9558 Note the difference in `time` and `now` fields of the above log message. This is easy to reproduce by using a pipewiresink as the audio source with a pipeline like below, as one of the sources during switching. gst-launch-1.0 -e audiotestsrc wave=ticks ! audioconvert ! audio/x-raw,format=F32LE,rate=48000,channels=1 ! pipewiresink stream-properties="props,media.class=Audio/Source,node.description=pwsink" client-name=pwsink Applications need to handle the GST_MESSAGE_CLOCK_LOST message in their bus handlers. --- src/gst/gstpipewiresrc.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/gst/gstpipewiresrc.c b/src/gst/gstpipewiresrc.c index 2a8f366ca..3f6ef340a 100644 --- a/src/gst/gstpipewiresrc.c +++ b/src/gst/gstpipewiresrc.c @@ -737,13 +737,29 @@ on_state_changed (void *data, enum pw_stream_state state, const char *error) { GstPipeWireSrc *pwsrc = data; + GstState current_state = GST_ELEMENT_CAST (pwsrc)->current_state; GST_DEBUG ("got stream state %s", pw_stream_state_as_string (state)); switch (state) { case PW_STREAM_STATE_UNCONNECTED: case PW_STREAM_STATE_CONNECTING: + break; case PW_STREAM_STATE_PAUSED: + /* + * We may see a driver/quantum/clock rate change on switching audio + * sources. The same is not applicable for video. + * + * We post the clock lost message here to take care of a possible + * jump or shift in base_time/clock for the pipeline. Application + * must handle the clock lost message in it's bus handler by pausing + * the pipeline and then setting it back to playing. + */ + if (current_state == GST_STATE_PLAYING && !pwsrc->is_video) + gst_element_post_message (GST_ELEMENT_CAST (pwsrc), + gst_message_new_clock_lost (GST_OBJECT_CAST (pwsrc), + GST_CLOCK_CAST (pwsrc->stream->clock))); + break; case PW_STREAM_STATE_STREAMING: break; case PW_STREAM_STATE_ERROR: