Created attachment 239930 [details]
Trace

While using alsasink element in a bin in a dynamic pipeline, I faced an issue when this bin selecting alsasink is already in PLAYING state. In such a case, alsasink might block in GST_BASE_SINK_PREROLL_WAIT() in gst_base_sink_wait_preroll().
Indeed, if the bin is already in PLAYING state and alsasink's state is synchronized on its parent, the pending state will be playing. Then, if gst_base_sink_do_preroll() is called before ASYNC set states have been performed, it will commit the state to PLAYING. Doing this, will prevent from calling gst_audio_base_sink_change_state() where important things are performed. Indeed, in the transition from pause to playing, gst_audio_ring_buffer_may_start() is called and set to true, and because it does not pass through this step in the conditions described above, it will block in preroll_wait.
Indeed, in gst_base_sink_chain_unlocked(), after committing to PLAYING state, render function of gstaudiobasesink is called and there it tries to render the buffer and write it in the ringbuffer which has not been started (gst_audio_base_sink_change_state() not called), the condition written==samples is not satisfied, gst_base_sink_wait_preroll() is called and it is stuck there.

In the patch in attachment, I added the call to gst_element_change_state() in gst_base_sink_commit_state() when committing to PLAYING state. It is not necessary to call it when committing to PAUSE state as the method is called before returning GST_STATE_CHANGE_ASYNC from the function setting the state.
I am not sure so far if this is a correct solution and comments would be greatly appreciated :)