discussion: improve state management & corking
This ticket is meant for discussion about a design issue that I am seeing, related application state policy management and corking.
Currently a gstreamer client (which uses
pw_stream) creates a node in pipewire when it reaches the PAUSED state, since the
pw_stream is created during the READY->PAUSED transition. The node is then picked up by the session manager and linked. First problem: the client may still be PAUSED at this point, the session manager doesn't know that!
Assuming now that the client is PLAYING and the user wants to pause, taking the pipeline back to PAUSED state. This does not change in any way the state of the
pw_stream and therefore the policy management code does not trigger... Second problem: there is no way to know when a client is paused by the user!
Now assume that the client is PLAYING again and there is another client with higher priority (according to the policy) that needs to play exclusively, corking everything else on the system. Currently this is implemented by unlinking the first client's node. This effectively takes the
pw_stream to PAUSED state and (in gstpwaudiosink) this transition is used as a signal to send the
GST_MESSAGE_REQUEST_STATE to the gstreamer pipeline, taking it to PAUSED state as well. There are several problems here:
- If the user tries to set the pipeline to PLAYING again, the pipeline is set to PLAYING, but there is no signal to the session manager. So, despite of whether changing this app's state is allowed or not by the policy, the policy manager will never know that this happened.
- When corking happens, we always assume that the app should go to PAUSED state. However, depending on the context this is not always the case:
- Suppose a scenario where there is a music player currently playing and a voice assistant application running in the background. We ask the voice assistant for some information, such as "What time is it?" and the assistant replies with a short voice message telling us the time. In this case the music player needs to be PAUSED for a short time and then continue playback. This currently works.
- Suppose the same scenario, but this time we ask the voice assistant to "Play music" from some online account playlist... In this case, the voice assistant app starts playing music (which can go on for hours). The other music player now is PAUSED and it will actually resume when the other music stops (hours later). This is weird and shouldn't happen. We should have the ability to give context to the corking and let the music player know that something else is playing music now so that it stops.
A potential solutions to all these problems would be to develop an extension API that signals state changes in both directions. Ideally:
- the app should be able to signal to the session manager the exact state that it is in when this changes
- the session manager should be able to cork the app with some context information attached, including a suggested target state (STOPPED, PAUSED)