0
0

The revision states:
– Win – Fixed device enumeration, device names are now encoded as multibyte.

like UTF-8?

When using 4.29.07 (still threadening as Ansi), i now get ?? for WaveOut (should be SB Live! Wave Out [1400]), while DirectSound still shows correct text (DirectSound (SB Live! Wave Out [1400]))… bit strange because WaveOut description should be same in Ansi and UTF8?
So, after threading as UTF-8, both names seem to be ok.

  • You must to post comments
0
0

That is odd, the change basically uses the wide char version of the device name, then converts it to multibyte using the default locale for the machine.

This was done in an effort to maintain the same API. However in the next development release we will be returning to ASCII and providing wide char versions of getDriverInfo and getRecordDriverInfo.

I’m not sure I follow what you mean by "(still threadening as Ansi)". Can you give us steps to reproduce this here?

  • You must to post comments
0
0

threadening like working with it as ansi string.
Must admit so that my UTF-8 knowledge is not so good at all…

  • You must to post comments
0
0

For your usage you should not need to worry about UTF-8 or multibyte.

The way multibyte works is if the device string is all ANSI standard chars you can use it as normal, i.e. the multibyte representation looks exactly the same as normal chars for those characters. If the string has foreign characters in it, it will be encoded as multibyte (so if you deal with it as normal chars it will look garbled).

So basically if you are dealing entirely with english devices you should see no difference in behaviour, however if you use a device with a different character set, depending on your locale settings in the OS you will either get foreign multibyte chars or question marks.

It should be fully backwards compatible with how FMOD has always worked.

Can you show us a code example of what you do when it works and what you do when it doesn’t?

  • You must to post comments
0
0

That’s what I read. Seems I miss something when using it, or conversation in PureBasic does not work properly.
Anyway, works so far for that version, just wanted to know for sure if it’s UTF-8, because multibyte can be a lot of things.

  • You must to post comments
0
0

The encoding is using the system default codepage specified by the locale of the OS, this is not UTF-8.

I’m interested in tracking what your actual issue is though. If you simply treat the device names as normal chars (no consideration for multibyte) everything should work as expected (providing the device name is all english characters). If it doesn’t then there is a bug that needs to be addressed on our side.

Can you run the recording example and post the output for the device list as "DirectSound", "Windows Multimedia WaveOut" and "WASAPI" (if you are on Vista or Win7).

  • You must to post comments
0
0

After some more testing with the visual basic recording example and testing on other computers, seems it’s on the Windows 98 machine, while it works properly on two Windows XP machines. If that’s any hint… otherwise I’ll setup a clean original 98 but from experience that’s a waste of time. Anyway some info:

screenshot from examples\bin\recording.exe
http://ctuser.net/_files/recording_waveout_win98.png

some output from the vb6 testings:
http://ctuser.net/_files/recording_waveout_win98.txt
the strange byte strings seem to vary each time, but didn’t take a close look yet.
Also trying to investigate why it works on my real project with utf-8 at all.

  • You must to post comments
0
0

k, guess the utf-8 was my mistake, probably just worked because it was an older fmodex version by accident.

Just tried with an original windows 98 with only (original) soundcard driver installed, similar weird device name for waveout like the image (link) post yesterday.

BTW, the visual basic recording example still uses FMOD_System_SetRecordDriver; it was removed with fmodex 4.22.00 (or 4.21 series) and removed from vb6 api declaration (fmodex.bas) with 4.22.05, but the project (both recording projects?) have not been updated likewise.

  • You must to post comments
0
0

We were not aware there would be an issue with Win98. While it is a very old OS I don’t like the idea that stable branches are now broken with it. I will possibly remove the multibyte implementation from stable branches, reverting back to ASCII character.

For proper Unicode support development branches have wide char versions of getDriverInfo and getRecordDriverInfo.

Thanks for spotting the incompatibility.

EDIT: I have logged that there are issues with the VC6 projects, someone will address this for a future release.

  • You must to post comments
0
0

Just wonder why it’s with waveout only. maybe if it’s a windows 98 flaw; How about adding a small workaround that use ansi api and convert to widechar, then process as usual, internally having unicode. Tell me if you need any testing on win98.

  • You must to post comments
0
0

We have discussed this internally and decided to go ahead with removing the multibyte implementation in favour of using wide char which is provided in dev branch.

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.