Pipewire: Long timeout stalls user application

[daschuer]

Describe the bug In case the audio callback stops because of an other error condition, the WaitCondition() will never happen and the long timeout of 10 min takes place. This is so long that the user will likely kill the application before, loosing his unsaved data.

To Reproduce

• Start Mixxx Pipwire API
• Simulate an issue with pipwire by systemctl --user restart pipewire.service
• The sound stops. (Automatic continue would be nice, but OK)
• Close Mixxx.

It happens here: https://github.com/PortAudio/portaudio/blob/2fe67f3568295accc0b4cc47cefd5e0d6a7f6e43/src/hostapi/jack/pa_jack.c#L1724

Expected behavior

• Mixxx should end normally

Actual behavior

• It crashes after 10 minutes, because assertions are enabled in the Debian package. .

Desktop (please complete the following information):

• OS: Ubuntu Focal
• OS Version 20.4
• PortAudio version: 19.6.0
• If Windows or Linux, which Host API (e.g. WASAPI): ALSA

Additional context The original bug is here: https://github.com/mixxxdj/mixxx/issues/11587

Is it possible to lower the timeout to a reasonable short time? Can we detect the error condition before start waiting?

[RossBencina]

Is this possibly related to #795

[RossBencina]

Some of my personal thoughts:

• 10 mins is too long for anything in PortAudio I think
• Stick to thinking about JACK and pipewire, not PortAudio in general. Probably for JACK the timeouts can be very short due to JACK low latency requirements
• WaitCondition is called in multiple places. Not sure the timeout should be the same in all cases.
• In AbortStream the timeout should be 0 or very short
• In StopStream an appropriate timeout might be 2x the max(total input stream latency, total output stream latency) [open for discussion] (need to have enough time to (1) drain buffers, and (2) account for the time it takes for a callback to be invoked and respond)

Phil and I agree that 10mins is too long. The question is what is the best value. Ultimately it's up to interested parties to develop a patch.

[philburk]

It may take a while to decide on the optimal timeout. So we could just change the 10 minutes to 3 seconds as a quick fix. It may not be short enough for some cases. For example stopping a stream requires waiting for all the audio to drain out. That might be more than 3 seconds. But I think we can agree 3 seconds is better than 10 minutes.

[RossBencina]

Having looked at the pa_jack.c code in more detail, i think all of the calls to WaitCondition need to be reviewed as it doesn't seem like pthread_cond_timedwait is being used correctly (i.e. a condition is not always checked).