Recently, Ubuntu had a new LTS, 22.04, which switches the sound system to PipeWire. This is in the long term a good thing, however, previous versions used pulseaudio, and before that OSS, and before that ALSA.
With PulseAudio, an OSS proxy package was provided that allowed applications that used OSS's dev tree muxes/dsp end points to allow applications expecting them to work on PulseAudio.
Unfortunately there's some issue/bug/other with the current 22.04 release. After installing OSSPD (the proxy package), I've noticed that the sound implementation in wxWidgets will lock up a mutex permanently when a wave file is being played in a loop. Unfortunately this is the method I use to generate sound on LisaEm.
So the effect is that whenever the Lisa plays a sound, LisaEm will permanently lock up.
A bunch of this is related to wxWidgets not supporting anything else, and on GTK requiring SDL for wave playback. There's a note that says wxWidgets requires SDL for this, which is less than ideal as it requires me to link in yet another library that's not quite large, but misused as SDL also does graphics and other things that are unused.
Sound seems to be a second class citizen in wxWidgets currently, and for backwards compatibility this is also an issue. All it can do is play a single wave file at a time, optionally asynchronously, and optionally looping the same sound. If another sound play call is issued the current sound stops playing. This works ok for windows and macos without SDL (I think), but never for GTK+ (Linux, *BSD, *Solaris). There were some discussions in the wxWidgets forums about this, but nothing has been implemented. So I'm leaning either for a workaround, or a replacement.
Unfortunately since my current daily driver development machine runs Linux this is a blocker.
Since I'm getting ready for a prod release, this is a problem as it requires a new, mostly untested, solution.
There's what I'm looking at as strategies:
* change the wave file size I'm using to several seconds instead of using looping - this would require more memory use and a work around, but it might work, haven't tested to see if I can stop the sound early successfully if it's something like 5-10 seconds of a wave file.
* directly talk to SDL and see if I can produce working sound that way.
* switch to OpenAL or SoundVox, and a few others - of the two, OpenAL is the smallest and most widely compatible - leaning to this as well. There's a small snag here, OpenAL is no longer provided for modern macos, however it does still compile there, and can run fine. No telling if it will still work in the future, but it's no different than X11 or OpenGL support. As part of Apple's war on all things GPL (including bash, and gcc) and closing off source code they've removed this as well in favor of proprietary frameworks.
* directly targeting the PipeWire calls is not an option, as I'd like to avoid writing platform specific code as much as possible and worse, elder Linux and other OS's that may use ALSA, pulseaudio, OSS, JACK, etc. would then also need yet another exception to work.
Ideally I need something that can play multiple wave files in the background (floppy, widget, imagewriter, etc), but also optionally constantly play sound data preferably without having to create a wave file either in RAM or on disk and then calling the play function. Something like a circular buffer that I can feed new values from the shift register of the VIA to generate sound - like a mixer or the way classic macos does.
The sound output of the VIA is just 1 bit, so it's an 8 cycle (8 bits in SR) timed square wave pattern at a specific volume so perhaps a synth output would be a good shortcut so I don't have to manually generate a large repeating buffer in memory with it.
