This is a singleton, even if you are not enforcing it in the "traditional" manner. I don't recommend this approach, and I think you should find another way.
For example, why not create a single SoundSystem
instance when your program starts? You don't need to explicitly enforce its single-ness, just pass that instance along to other objects that need access to the sound system. As a bonus, this also lets you easily drop in support for different types of SoundSystem
s if you need it some day (a nice little extra benefit, even if you don't need this).
On top of all this, will the OpanAL initialization itself fail if you try and initialize multiple SoundSystem
s? If not, then there's not really a reason to place an artificial limit. If so, then you can just let OpanAL determine what is and isn't an error. But in any case, it wouldn't be a risk if you simply just create one instance and pass it off instead of letting all your application classes query the instance themselves.
Be careful you don't fall into the XY Problem trap here. Singletons aren't inherently evil, but for some reason they are frequently misused, hence the general advice against them. There is usually a cleaner way, and these cleaner ways usually come with a lot of bonus added benefit. Think about the actual problem you are trying to solve / situation you are trying to avoid here.