I see what he’s talking about - I’ve run into this issue before. A GitHub project is perhaps overkill to illustrate.
I’ve done a test using my first name (Joël) as the string, and basically the String class is trying to interpret the ‘ë’ as ASCII - which is out of range.
Here’s a version of my example that works perfectly - take notice of the conversion (for some unknown reason, UTF8 didn’t work correctly here - so I didn’t use it):
If you pass a damaged string into drawText or any other function that tries to use the string, then you’ll see heap errors like this!
Looking at the ASIO code, it’s assuming that the channel names returned by the driver are in utf-8. I guess that with your driver, it’s not utf-8, so the string is getting created with an illegal character sequence.
I’ve added a check now, so that if the driver returns data that isn’t utf-8, it’ll attempt to parse it as a local encoding. Let me know if that sorts things out.
Just to clarify this issue, The problem is not generated by my driver. It is the Generic Steinberg ASIO Driver taking the regular PC AC97 resources, this is, the speaker and microphone built in in every tower/laptop.
Can you put this test program into a GitHub repository that anyone can pull and compile? Make sure to include the JUCE sources in the repository along with the project files (especially Visual Studio 2010).[/quote]
Vinn, it is the “plugin Host” example as it is, without any customization!
[quote=“jrlanglois”]I see what he’s talking about - I’ve run into this issue before. A GitHub project is perhaps overkill to illustrate.
I’ve done a test using my first name (Joël) as the string, and basically the String class is trying to interpret the ‘ë’ as ASCII - which is out of range.
Here’s a version of my example that works perfectly - take notice of the conversion (for some unknown reason, UTF8 didn’t work correctly here - so I didn’t use it):
The fault actually lies with Steinberg, because their API says that drivers should return these character strings as a char*, but fails to specify the encoding format.
Although it could be argued that for an ASIO driver to be safe, it really should only return pure ASCII strings. Since it’s impossible to know what format an app is expecting, there’s a risk that anything except ASCII could cause undefined behaviour.
The fault actually lies with Steinberg, because their API says that drivers should return these character strings as a char*, but fails to specify the encoding format.
Although it could be argued that for an ASIO driver to be safe, it really should only return pure ASCII strings. Since it’s impossible to know what format an app is expecting, there’s a risk that anything except ASCII could cause undefined behaviour.[/quote]
Some Chinese users have problems under Win8 (the problem does not seem to occur with their Win8 Pro computers). It seems to be linked to AudioDeviceSelectorComponent (difficult for me to test as I don't have problems on my computers) and I was wondering if this could be caused by their using of MultiByte (instead of UTF) char sets. Did your fix also apply to MultiByte ?