RossBencina
commented
3 months ago Phil and I are slightly ambivalent on merging this because it is a behavior change that could break user expectations in the case where the reopened streams are unreleated and should not be reconnected. Our assessment is:
- Simple applications will not change behavior after this PR
- Applications with only one mode of stream use will benefit from this PR
- The above two cases probably cover most applications
- The remaining class of applications with more complex stream usage will have behavior changed from not being re-connected by connection managers to being potentially incorrectly reconnected. It is not clear whether this is actually a worse outcome than the current behavior, nor is it clear whether there exist applications that would be impacted.
My position is that for serious use there should be a way for the application to set the stream names as discussed in #366.
JACK connection managers save/load the connection graph so users don't need to create connections manually every time. This depends on stable port names but PortAudio currently generates incrementing port names throughout the lifetime of a running process.
Reset the port name counters when all streams are closed so that the same port names are generated when the streams are opened again.
This is not a perfect solution because applications that open streams in different orders each time or never close all open streams before restarting audio processing will not reset the port counters. However, typical applications should work with this simple approach and it's an improvement over current behavior.
Tested with Audacity 3.3.3 on Fedora 39.