soundStream constructor is being called twice

[dimitre]

ofSoundStream::ofSoundStream() is being called twice, even if in my example I'm only using one ofSoundStream
This calls this function twice setSoundStream(std::make_shared<OF_SOUND_STREAM_TYPE>());
which creates two different objects in memory
both for iOS and macOS. probably all platforms

it can be tested in a simple example, only creating one ofSoundStream object

class ofApp : public ofBaseApp{
	public:
		void setup();
		void update();
		void draw();
		void keyPressed(int key);

	ofSoundStream soundStream;
};

To inspect what is being called I've made this alterations

using std::cout;
using std::endl;
//------------------------------------------------------------
ofSoundStream::ofSoundStream(){
	cout << "ofSoundStream" << endl;
	#ifdef OF_SOUND_STREAM_TYPE
		setSoundStream(std::make_shared<OF_SOUND_STREAM_TYPE>());
	#endif
}

//------------------------------------------------------------
void ofSoundStream::setSoundStream(const shared_ptr<ofBaseSoundStream> & soundStreamPtr){
    std::cout << "setSoundStream " << &soundStreamPtr << std::endl;
	soundStream = soundStreamPtr;
}

result

ofSoundStream
setSoundStream 0x16d62e230
2023-02-02 21:15:20.708128-0300 Empty[47621:2755547] Metal API Validation Enabled
ofSoundStream
setSoundStream 0x16d6331d0

[artificiel]

there is a global soundStream tucked in an anonymous namespace in ofSoundStream.cpp

openFrameworks/libs/openFrameworks/sound/ofSoundStream.cpp

Lines 23 to 25 in 72a6ea3

	namespace{
	ofSoundStream systemSoundStream;
	}

it connects with the pseudo-static ofSoundStreamSetup|Start|Stop|Close()).

so having ofSoundStream soundStream; in app.h is redundant as it will simply "overwrite" the global systemSoundStream and lay around doing nothing (but provide trampoline to the global's methods). I think this stems from a design goal of OF to encourage the pattern of having plain objects declared in .h as it seems there was an effort done to make it behave like a standard allocation.

so in short: remove the ofSoundStream soundStream; in app.h and the example works as well, but you cannot make use of the direct soundStream.functions().

maybe the idea of doing that that should not be proposed, and if there are more methods that need access create the desired global ofSoundStream*() so there is a consistant access pattern.

[dimitre]

Yeah this can explain, but I'm not sure why it only allocates the other object once we have declared ofSoundStream soundStream; and at the same time.

I've noticed some years ago using ofSoundStream object was preferred over ofSoundStreamSetup. Maybe it it time to deprecate ofSoundStreamSetup ?

[artificiel]

[edit: while correct it it's essence, this post had deficiencies re: c++ terminology; see the next one for more precise information]

[artificiel]

I did a bit more reading to make sure my terminology is good and what happens is this:

the anonymous namespace of the ofSoundStream translation unit (.cpp + included .h) contains an ofSoundStream object named systemSoundStream. this gets compiled as ofSoundStream.o, as part of the OF compilation.

but this .o gets linked into the app only if something within is referenced (note: I am not sure this must be referred to as the linking per se, or a more subtle manipulation/inclusion of the symbols within). no matter the correct term/sequence, the systemSoundStream symbol does not end up in the binary, thus obviously does to get instantiated.

if the app references at least 1 symbol of ofSoundStream.o, it gets linked (the whole thing), thus systemSoundStream gets constructed. if a reference in question is a .h-declared ofSoundStream soundstream (or whatever other means of instantiating an ofSoundStream), it's a second instantiation of an ofSoundStream.

(note: while it's not relevant to this discussion, there are methods to alter this behaviour: the --undefined linker flag; --whole-archive linker flag (not fine-grained); the enabling the "target membership" of the ofSoundStream.cpp Xcode inspector -- it then gets compiled within the app and the systemSoundStream gets constructed no matter if there is usage of it's symbols. I'm mentioning this as most discussions around the topic are about cases where people want to maintain static things in libraries that are otherwise not referenced https://stackoverflow.com/questions/11631161/force-to-link-against-unused-shared-library https://stackoverflow.com/questions/7253801/how-to-force-symbols-from-a-static-library-to-be-included-in-a-shared-library-bu )

so I guess the discussion should center on:

• is it desirable to have multiple instances of ofSoundStream, or otherwise dynamic instantiations? (I don't think so?)
• if so, is ofSoundStream designed to have multiple, parallel interactions with the actual sound back end? in a good cross-platform way?
• if not, is the anonymous namespace systemSoundStream instance the correct way to go (using ofSoundStream*() global calls)?
• or if the explicit instantiation in .h is preferred, the systemSoundStream (and it's ofSoundStream() calls) should be removed?

once understood, I find that the "automatic" instantiating(linking) of systemSoundStream based on actual symbol reference is pretty efficient. but it should not be a source of ambiguity as it currently is.

[2bbb]

I've only read a little bit,

change definition of systemSoundStream from:

namespace{
    ofSoundStream systemSoundStream;
}

to:

namespace{
    ofSoundStream &getSystemSoundStream() {
        static ofSoundStream systemSoundStream;
        return systemSoundStream;
    }
}

and replace systemSoundStream.method() to getSystemSoundStream().method().
now, it will be instantiated when it is needed (first time of calling getSystemSoundStream).

is this not good?

[2bbb]

please check #7301

[artificiel]

@dimitre can be closed!