kcat
alOpenDevice fails when device name uses Japanese characters
alcOpenDevice returns null when the device name in Windows has characters like this:
OpenAL Soft on 繧ｹ繝斐・繧ｫ繝ｼ (Realtek(R) Audio)
This string is retrieved via alGetString with ALC_ALL_DEVICES_SPECIFIER, then passed straight back into alcOpenDevice. ANSI decoding/encoding is used for both functions.
alGetError and alcGetError both report no issues.
I'm unable to reproduce this by changing my device's name to the above, however the users facing these issues have their Windows language set to Japanese. I'd like to check here first before changing my Windows language :)
OpenAL Soft actually uses UTF-8 strings, not ANSI. If it's passed from alcGetString directly to alcOpenDevice it should be fine, although if the names are passed through WinAPI functions expecting ANSI encodings, and/or converted from ANSI to WideChar and back, the names could get mangled.
You can convert them from UTF-8 to WideChar and back (e.g. MultiByteToWideChar(CP_UTF8, ...); and WideCharToMultiByte(CP_UTF8, ...);), and they should be fine, otherwise you need to make sure whatever functions the names pass through won't change the bytes.
I changed my encoding to UTF8 and the device name was correctly decoded as OpenAL Soft on 繧ｹ繝斐・繧ｫ繝ｼ (Realtek(R) Audio), but passing it back to alcOpenDevice returned null.
I tried ANSI again and the device name was decoded as OpenAL Soft on 繧ｹç¹æ–・繧ｫç¹ï½¼ (Realtek USB2.0 Audio), and I was able to pass this to alcOpenDevice and get a valid result.
I would need to see code relating to how you handle the device string. If you take the pointer directly for one of the names returned by alcGetString(NULL, ALC_ALL_DEVICES_SPECIFIER), it should open the device. If you copy the string, you need to make sure it does a byte-for-byte copy, or you otherwise need to make sure to undo any transformation done to it, before passing it to alcOpenAdevice. If it's not working, it's not being copied correctly.
Are you able to provide a trace log from when it fails to open? You can set the ALSOFT_LOGLEVEL environment variable to 3 to have it write out an informative log to stderr (or also set the ALSOFT_LOGFILE environment variable to a full path+filename to have it write the log there instead, as long as the app has write permissions there).