[openal] OpenAL soft on win32: AL lib: (EE) ALCmmdevPlayback_open: Device init failed: 0x80004005
chris.kcat at gmail.com
Sun Oct 12 14:29:18 EDT 2014
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
Looking at cAudio's source for the fromUTF8 method, though, it seems a
bit iffy to me.
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.
More information about the openal