Someone using one of my programs on Linux got a crash at startup. I got a backtrace:
#0 0x00007ffff600d257 in kill () at ../sysdeps/unix/syscall-template.S:81 #1 0x0000000000562424 in juce::String::String (this=0x7fffffffdd20, t=0xec48b0 "Microsoft® LifeCam Studio(TM), USB Audio\nDefault Audio Device") at ../../JuceLibraryCode/modules/juce_core/text/juce_String.cpp:311 #2 0x00000000004966a9 in juce::(anonymous namespace)::ALSAAudioIODeviceType::hintToString (hints=0xf11690, type=0x8051ea "DESC") at ../../JuceLibraryCode/modules/juce_audio_devices/native/juce_linux_ALSA.cpp:1202 #3 0x0000000000495b29 in juce::(anonymous namespace)::ALSAAudioIODeviceType::enumerateAlsaPCMDevices (this=0xeb37b0)
It's pretty clear what's going on from the stack trace - he has a webcam named "Microsoft® LifeCam Studio(TM), USB Audio" and the ® character is messing up the string constructor in ALSAAudioIODeviceType::hintToString, which is expecting only ASCII.
Unplugging that web camera did indeed fix the issue, but unfortunately my code isn't involved here, so I can't fix it in my codespace - it needs to be dealt with in Juce.
Since this is a Microsoft product, other people will no doubt have this issue.
I unfortunately don't have such a device to test, but I can get the other developer to make tests. I'm not sure what encoding the string is coming in as - so that it prints out right on his terminal as the correct string. My guess is UTF-8...?
I'm going to try that right now with him. If that works, perhaps that might at least make this issue go away without breaking anything that worked. If one day an audio device has a non-UTF-8 encoding, well, we can burn that bridge when we come to it...