make ofSoundStream systemSoundStream able to lazy initialize

[2bbb]

related to #7298

[dimitre]

Thank you @2bbb
I personally think it is great and we should merge it.

[artificiel]

that's perfect for the hidden/builtin systemSoundStream.

but how to we "orient" the usage? is it logical to have a strategy using a builtin ofSoundStream singleton configured with global ofSoundStream* calls (which is probably good considering the hardware mapping), but at the same time a strategy using self-allocated instances? in other words, for what reason would someone declare an ofSoundStream in .h?

[ofTheo]

in other words, for what reason would someone declare an ofSoundStream in .h?

@artificiel I think maybe if they want to use multiple streaming apis ( via setSoundStream ) or if they want to dynamically open and close input devices separately from output devices?

I agree though the whole pattern is not very OF. 🙂

I am not opposed to this PR though as it gets rid of an extra unneeded initialization.
Happy to merge unless there is a strong reason not to.

[artificiel]

if the decision is to maintain the "global" systemSoundStream, yes merging this is definitely a gain! (although I still wonder if the design of this automatic instance is wanted, vs declaring an explicit ofSoundStream yourself in ofApp.h?)

I'm in support of removing lines of user code (which the global does) but then, for the global approach to make sense, the examples should :

• focus the ofSoundStream usage on that "global" systemSoundStream with the ofSoundStream*() calls (could add an ofSoundStreamGetSystem() that returns a reference to the instance for eventual finer-grain tweaking);

• not provide precedent of declaring additional ofSoundStreams in ofApp.h -- such advanced use has a lot of moving parts and should be left to the discretion of the users that need to "go there";

• not mix ofSoundPlayer and ofSoundStream (in order to circumvent iOS example audioInputExample: issue with audioIn / ofSoundPlayer order #7291) -- and/or insert warnings about the ordering of calls, but it seems complicated to provide straightforward recommendations (or there are incompatibilities within the 2 classes, causing inconstant routing behaviour, at least on iOS) -- also, unless macOS / iOS sound player. AVAudioEngine - WIP #6728 fixes those problems.

I can work on that (including mac, iOS and linux tests), but this effort should also take into account #6728 -- so everything gets tweaked coherently?