8153 stopping recording with bt as input causes freeze

[IliasBergstromMuse]

Resolves: #8153

I reproduced the issue on MacOS Sonoma 14.7.3 - to occur it requires that both input and output are the same bluetooth device.

AU3Player::stop() went into an infinite loop, waiting for bool AudioIOBase::IsBusy() to return false - but it never does, because the AudioIOBase::mStreamToken flag is never set to 0.

The reason is what appears to be a race-condition: mPortStreamV19 is, by the time stop() is called, already NULL, and so the method returns - failing to also set mStreamToken to NULL. I address that by resetting mStreamToken at the point it returns. I cannot see that there would be any undesired side effects, and it fixes the problem.

For the changes made, I have written additional annotation in-line on the code ("Files changed" tab).

On my fix:

Importantly, in terms of program structure, I don't think setting the flag where I do is particularly good code. But I suppose you agree it's consistent with how the AudioIO class is structured currently, and, seeing as it's part of the legacy AU3 engine, I imagine it is set for deprecation.

If not, I would have argued for refactoring the logic to make it less error-prone, more readable, and with a more clearly defined "state machine".

On unit-test:

For the same reason, I have not unit-tested this change. I don't see any unit-tests for this entire class, where I would normally have made my addition.

Question to reviewers:

I have a preference to make small local "scout" cleanup changes in the files I touch, if I see obvious points, either with formatting, or C++ annotation. I've made a commit with such changes in this PR, to ask you, is that OK for Audacity? Some teams prefer to have such changes in separate PR's, others are fine with them being in the same PR, if the changes are separated by distinct commits, and the PR is still easy to read, as is the case here.

I could have made many more (formatting is very inconsistent, NULL is used instead of nullptr, etc), but this is legacy AU3 code so I won't spend the effort - not to mention it would have made this PR so messy that making a separate one would definitely have been required.

• I signed CLA
• The title of the pull request describes an issue it addresses
• If changes are extensive, then there is a sequence of easily reviewable commits
• Each commit's message describes its purpose and effects
• There are no behavior changes unnecessary for the stated purpose of the PR

Recommended:

• Each commit compiles and runs on my machine without known undesirable changes of behavior