| Summary: | Invalid charset for JOAL Strings | ||
|---|---|---|---|
| Product: | [JogAmp] Joal | Reporter: | Mathieu Féry (MathiusD) <mfery> |
| Component: | core | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | 2.6.0 | ||
| Hardware: | All | ||
| OS: | all | ||
| Type: | DEFECT | SCM Refs: |
ca08b5ab2d64f23331580dcb9b9e0a2b807e4608
|
| Workaround: | --- | ||
| Attachments: | Patch used in my case to work around this issue (For reference) | ||
|
Description
Mathieu Féry (MathiusD)
2025-07-07 09:40:19 CEST
Do I understand you correctly that: - We interpret the returned string hard decoded as US-ASCII? - This is true for e.g. alcGetString in our source code. - The actual produced device string is UTF-8 and hence the wrong decoding 'ruins' the data? Notes: - The OpenAL manual doesn't mention encoding. - OpenAL-Soft uses std::string and seems not to apply special encoding - std::string can contain UTF-8 as long one safely uses the given byte length - c-str ASCII `strlen` uses codepoint `\0` (EOS null-byte) and no UTF-8 codepoint producses it (no collision) If above is true, we could simply use UTF-8 in our Java code from the byte array, which is compatible w/ US-ASCII. OK? (In reply to Sven Gothel from comment #1) > Do I understand you correctly that: > - We interpret the returned string hard decoded as US-ASCII? > - This is true for e.g. alcGetString in our source code. Yes, for alcGetString and alcGetStringAsDoubleNullTerminatedString in src/java/jogamp/openal/ALCImpl.java > - The actual produced device string is UTF-8 and hence the wrong decoding 'ruins' the data? Yes for example in my case i have theses names of devices : > Capture devices: > Audio interne St��r��o analogique, input, default true > Monitor of Audio interne St��r��o analogique, input, default false > Monitor of HDA NVidia St��r��o num��rique (HDMI), input, default false Instead of this with UTF-8 charset : > Capture devices: > Audio interne Stéréo analogique, input, default true > Monitor of Audio interne Stéréo analogique, input, default false > Monitor of HDA NVidia Stéréo numérique (HDMI), input, default false And since we can retrieve a device with the name, a wrong encoding 'break' opening of device related (Example in my case) > Error: Failed to open default output device Audio interne St��r��o analogique > Error: Failed to open output device HDA NVidia St��r��o num��rique (HDMI) > If above is true, we could simply use UTF-8 in our Java code from the byte array, > which is compatible w/ US-ASCII. > > OK? Yes, that's the workaround I used and from what you describe in your notes it seems safe to use, so it sounds like the right solution to me. Created attachment 894 [details]
Patch used in my case to work around this issue (For reference)
(In reply to Mathieu Féry (MathiusD) from comment #3) Perfect, thx. Shall I do a git pull/merge or apply your patch 'manually'? ~Sven (In reply to Sven Gothel from comment #4) OK, will use your patch and commit with you as author. Guess that's the fastest best way :) Thank you! commit ca08b5ab2d64f23331580dcb9b9e0a2b807e4608 done Thanks a lot ! |