The wxBell() command does nothing on Linux (Ubuntu) and I read a suggestion to use wxSound. Now I found a license free sound sample for the 'wrong-answer'-sound here: http://www.orangefreesounds.com/wrong-answer-sound-effect/
Unfortunately, that is in *.mp3 format. So I found an online conversion program here: https://www.online-convert.com/result/57548c3f-6cf3-40b5-9dcc-f7c3e5f03ab3 It offers various options, like 32 bit floating point, signed or unsigned integers of 8, 16, 24 or 32 bits, either little or big endian, different sample rates etc.
But when the constructor of wxSound tries to read the converted file, I get: Sound file '../wrong-answer.wav' is in unsupported format. (At least it can find it).
This while I can play at least one of those converted files (16 bits signed integer, 44100Hz, mono) by double clicking on it in nautilus. (The video player seems to be called Totem).
But the big question is: what bit resolution, sampling rate, #channels and PCM format will be acceptable for wxSound?
And this is a lot of hassle for a simple beeping/buzzing sound. Even my ZX Spectrum could do this in 1983 without extra resource files. There you had a beep command where you could pass the frequency and duration. Isn't something similar possible without having to use SDL (a linux native API call for instance)?
Bonus points: is there a solution that works over ssh, now we all work at home? Software runs on company server. We get the GUI at home with ssh -X, but sound?
wxBell() uses the "bell" configured in your desktop environment, so its behaviour depends on the platform.
As for wxSound, it's unfortunately a bit difficult to say what exactly it doesn't like in your file because it has several checks, but normally it shouldn't fail on valid WAV data. If you built wxWidgets yourself, the simplest way to find out what's wrong is to run the program under gdb, do b wxSound::LoadWAV and execute this function step by step to see which check fails.