[Solved]AudioDeviceSelectorComponent not get along with ASIO

General JUCE discussion
#21

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 an example that asserts:

g.drawText ("Joël", 0, 0, 300, 100, juce::Justification::centredLeft, false);

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):

g.drawText (juce::CharPointer_UTF16 (L"Joël"), 0, 0, 300, 100, juce::Justification::centredLeft, false);
#22

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.

#23

Ok Jules, I’ll check it.

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.

Gabriel

#24

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!

#25

[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 an example that asserts:

g.drawText ("Joël", 0, 0, 300, 100, juce::Justification::centredLeft, false);

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):

g.drawText (juce::CharPointer_UTF16 (L"Joël"), 0, 0, 300, 100, juce::Justification::centredLeft, false); [/quote]

This is the track, jrlanglois!

#26

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.

#27

Jules & Co.

Solved.

Should I change the topic caption to [Solved]?

#28

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]

I completely agree!

#29

By the way, I forgot to say

Thank you, Jules!

#30

No problem, glad we got there in the end!

#31

Okay so what’s the conclusion here? Is any additional work required in my application or is this something JUCE can handle?

#32

Don’t worry, it’s just a fix inside the ASIO code.

#33

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 ?

Thx