Encoding error in ALSAAudioIODeviceType::hintToString

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...




The following fix for ALSAAudioIODeviceType::hintToString seems to work:

    static String hintToString (const void* hints, const char* type)
        char* const hint = snd_device_name_get_hint (hints, type);
        const CharPointer_UTF8 cp8(hint);
        const String s (cp8);
        ::free (hint);
        return s;

...which seems to prove that at least this Microsoft device is emitting its device string at UTF-8.

Thanks to Tylor Steinberger for working with me to debug this!


Thanks - yes, I think I should have treated that string as UTF8 - have changed that now, so hopefully should work ok!

It's really not clear what encoding that string is supposed to be in, frankly - or at least no one seems to mention it.  But, UTF-8 is better than what's there, as it includes ASCII and we know that Microsoft uses it...