Race condition causing pw_stream to not deactivate
Version, Distribution, Desktop Environment:
0.3.33, Debian, KDE
Description of Problem:
pw_stream_active(stream, false); is called to pause/deactivate the stream immediately after starting/activating, the stream fails to properly switch to a
PW_STREAM_STATE_PAUSED state. If an app tries to wait for the stream to become paused, it will soft-lock and never get a signal that it stopped streaming. When some time is allowed to elapse after starting and before trying to pause, then the stream will successfully become paused.
My limited tracing shows that the
state_changed callback is invoked when the stream changes from
PW_STREAM_STATE_CONNECTING and then from
PW_STREAM_STATE_PAUSED when it's created, then from
PW_STREAM_STATE_STREAMING when it's activated. However, when deactivated, the callback is never called. The
process callback also stops getting called, so the stream is apparently getting stopped on some level, it's just not getting signaled back to the app.
Almost always. I think I had one instance of the stream becoming paused without waiting in between activating and deactivating, though if it is indeed some kind of race condition, any number of reasons could've caused the fluke. If a 250ms or larger delay is purposefully added before deactivating the stream, it always becomes paused correctly (smaller delays may also work, I didn't test to see how small I could make it before it starts locking up).
Steps to Reproduce:
- Compile the attached test program
- Run the compiled test program
The program locks up when stopping the stream.
The program closes without error.
gcc -O2 -g -D_DEBUG -o test test.c `pkg-config --cflags --libs libpipewire-0.3`
-O1 -g3 can also be used for better debugging if needed, it still locks up for me with that.