[openal] OpenAL soft on win32: AL lib: (EE) ALCmmdevPlayback_open: Device init failed: 0x80004005

[Chris Robinson]

On 10/12/2014 05:26 AM, Lex wrote:
> You're right:
> AL lib: (WW) ALCmmdevPlayback_open: Failed to find device name matching "R"
>
> Full output goes bellow my signature just in case. There you can see
> device names as OpenAl Soft sees them.
>
> So, I have Russian localization of Windows and therefore device names
> come with Cyrillic in them, which goes out as a garbage. So that nails
> down the problem to be either OpenAL not returning the names correctly
> or CAudio (openal c++ wrapper library) not handling them appropriately.

I think it may be cAudio. The mess OpenAL Soft's log shows is likely due 
to it using the *printf family of functions, which doesn't play well 
with the UTF-8 characters it's trying to print. But OpenAL Soft does get 
the WideChar string as a base (which has all the characters as Windows 
itself sees them) and converts it to UTF-8 using Windows' 
WideCharToMultiByte function with CP_UTF8 (which can equally represent 
all the same characters), so it should have the name correctly stored as 
UTF-8.

Looking at cAudio's source for the fromUTF8 method, though, it seems a 
bit iffy to me.
<https://github.com/R4stl1n/cAudio/blob/master/cAudio/include/cAudioString.h#L103>
It first converts the UTF-8 string to a WideChar string using Windows' 
MultiByteToWideChar function, then it tries to convert the WideChar 
string back to a multi-byte string using wcstombs (and for added 
confusion, cAudioString may be a basic_string<wchar_t> if UNICODE or 
_UNICODE is set, so it gets converted back to a WideChar string again; 
also, it leaks the 'convert' buffer).

The problem here is that wcstombs does the conversion based on the 
current locale, and also stops converting when it encounters a character 
that can't be represented in that locale. So if the locale is set to 
something that can't handle some characters in the device name, cAudio 
will truncate the name, and so won't get recognized.

Locales have always been kind of a messy thing for me to understand, and 
I'm sure Windows makes such things even more difficult. Though I'd 
recommend for cAudio to just use UTF-8, and only when interfacing with 
Windows convert to/from WideChar strings and explicitly using the 
WideChar functions; see <http://utf8everywhere.org/>). Otherwise, you'll 
just need to try to make sure you have a UTF-8 locale set in your 
app/system, or at least a locale that can otherwise handle all the 
characters you need.