On macOS, Pa_AbortStream() takes too long to abort the stream.

[kakyoism]

(Please use the mailing list for support requests and general discussion. This is only for actual bugs.)

Describe the bug

on macOS, I found that Pa_AbortStream() could take as long as a few seconds to abort the stream, which behaves similarly to Pa_StopStream(). This is counter-intuitive against what the doc says about this API function:

/** Terminates audio processing immediately without waiting for pending
 buffers to complete.
*

To Reproduce

In my case, it's a pretty straightforward output stream implementation in its own thread.

• sample rate: 48kHz
• buffer size: 2048

The callback consumes the buffer in any way or even does nothing.
Call Pa_AbortStream() in my main thread, the render callback ends normally,
but Pa_AbortStream() could block for a few seconds (up to 10+ secs) for unknown reasons,
which behaves almost the same way as Pa_StopStream(), i.e., no perceivable improvement on the blocking wait.

Expected behavior

Users shouldn't perceive any delay while trying to abort the stream. It should be literally "immediately".
For instance, if a user hits Ctrl-C on a running command-line program, which has a signal handler that tries to perform a special exit procedure in an orderly fashion, then the user shouldn't have to wait 10 seconds before the program quits due to aborting the stream.

Actual behavior

The blocking wait on the scale of a few seconds seems inevitable before the stream is aborted.

Desktop (please complete the following information):

• OS: macOS
• OS Version: 10.15.7
• PortAudio version: stable

Additional context

• Xcode 12.3
• The release build is slightly faster than the debug build for the said problem.

[RossBencina]

I agree that AbortStream should usually exit faster than StopStream, and it would be nice to improve this if we can. But I don't think you should expect or rely on it. It could be that the underlying native host API does not provide any way to abort. In that case it would not be a bug for StopStream to just call AbortStream.

Based on my knowledge of the backlog, this issue is unlikely to be improved unless

1. Someone demonstrates that there is a faster way to terminate CoreAudio streams
2. Someone submits a patch

[philburk]

I agree with Ross that we cannot guarantee AbortStream will be faster than StopStream.
But it should not take 10 seconds to stop or abort a stream.

I modified paex_write_sine to use 48000 Hz and a 2048 frame buffer.
Pa_StopStream() took about 1/4 of a second.

Under what circumstances are seeing 10 second stops?
Are you allocating a very large buffer capacity?

[RossBencina]

@kakyoism more information required. Please see philburk's questions.

[kakyoism]

Interesting. My app involves using SoundFlower to redirect system audio. I noticed that the longer I leave the app on, the longer it takes to abort the stream. But on my app layer, there is no explicit buffer accumulation. I've disabled all custom code in my render callback. When I get a chance, I'll see if I could give a minimum repro case.

…

On Sat, Dec 19, 2020 at 2:58 AM Phil Burk ***@***.***> wrote: I agree with Ross that we cannot guarantee AbortStream will be faster than StopStream. But it should not take 10 seconds to stop or abort a stream. I modified paex_write_sine to use 48000 Hz and a 2048 frame buffer. Pa_StopStream() took about 1/4 of a second. Under what circumstances are seeing 10 second stops? Are you allocating a very large buffer capacity? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#367 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADWNO5XPDC3HRUXFQX6XODSVOQ5VANCNFSM4U67QSZA> .

[RossBencina]

Not that it resolves this issue, but we probably should update the docs to:

/** Terminates audio processing without necessarily waiting for pending
buffers to complete.
*

It's a QOI issue whether Pa_AbortStream calls Pa_StopStream or not.

[RossBencina]

created #728 to address the docs issue.

[philburk]

SoundFlower is currently supported on this GitHub project.
https://github.com/mattingalls/Soundflower

@kakyoism - Are you still seeing this issue?

[RossBencina]

To be clear, I think it is potentially an issue that Pa_AbortStream is not implemented to exit as fast as possible. If it can be sped up that would be a desirable enhancement and we'd happily accept a PR.