1517 2025-07-07 09:40:19 +0200 Invalid charset for JOAL Strings 2025-07-08 13:42:22 +0200 1 1 3 JogAmp Joal core 2.6.0 All all RESOLVED FIXED P4 normal --- 1 mfery sgothel DEFECT ca08b5ab2d64f23331580dcb9b9e0a2b807e4608 --- oldest_to_newest 7196 0 mfery 2025-07-07 09:40:19 +0200 When we fetching string with alcGetString and alcGetStringAsDoubleNullTerminatedString, we retrieve strings with wrong charset. Since theses strings can be used to select the audio device, this can be annoying :c Atm we can work around this issue if we retrieve JOAL strings with UTF-8 charset instead the US-ASCII charset (Maybe it's related of openal-soft build or maybe after the migration to java 11?). We have reproduced this issue on Fedora Linux 42 & Windows 10 Tested with 2 followings RC : * https://jogamp.org/deployment/v2.6.0-rc-20250706/jar/ * https://jogamp.org/deployment/v2.6.0-rc-20250628/jar/ With following call : * java -cp joal.jar:joal-natives-linux-amd64.jar:joal-test.jar:gluegen-rt.jar:gluegen-rt-natives-linux-amd64.jar com.jogamp.openal.test.manual.ALCSystemEventTest for Fedora Linux 42 * java -cp joal.jar:joal-natives-windows-amd64.jar:joal-test.jar:gluegen-rt.jar:gluegen-rt-natives-windows-amd64.jar com.jogamp.openal.test.manual.ALCSystemEventTest for Windows 10 If I've forgotten anything or if I can help, don't hesitate! 7198 1 sgothel 2025-07-07 21:26:45 +0200 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? 7199 2 mfery 2025-07-08 09:23:28 +0200 (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. 7200 3 894 mfery 2025-07-08 09:26:45 +0200 Created attachment 894 Patch used in my case to work around this issue (For reference) 7201 4 sgothel 2025-07-08 12:36:47 +0200 (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 7202 5 sgothel 2025-07-08 12:39:40 +0200 (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! 7203 6 sgothel 2025-07-08 12:44:06 +0200 commit ca08b5ab2d64f23331580dcb9b9e0a2b807e4608 done 7204 7 mfery 2025-07-08 13:42:22 +0200 Thanks a lot ! 894 2025-07-08 09:26:45 +0200 2025-07-08 09:26:45 +0200 Patch used in my case to work around this issue (For reference) joal-charset-encoding.patch text/plain 1079 mfery SW5kZXg6IHNyYy9qYXZhL2pvZ2FtcC9vcGVuYWwvQUxDSW1wbC5qYXZhCjwrPlVURi04Cj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KZGlmZiAtLWdpdCBhL3NyYy9qYXZhL2pvZ2FtcC9vcGVuYWwvQUxDSW1wbC5qYXZhIGIv c3JjL2phdmEvam9nYW1wL29wZW5hbC9BTENJbXBsLmphdmEKLS0tIGEvc3JjL2phdmEvam9nYW1w L29wZW5hbC9BTENJbXBsLmphdmEJKHJldmlzaW9uIGU1ZTA2YzMxNjlmZTUzN2IxNWM1ZWM4NmM2 YzAzMmM3ZWM1Mjc0M2IpCisrKyBiL3NyYy9qYXZhL2pvZ2FtcC9vcGVuYWwvQUxDSW1wbC5qYXZh CShkYXRlIDE3NTE5NTg3Mjk3NzApCkBAIC01Myw3ICs1Myw3IEBACiAgICAgICAgIGZpbmFsIGJ5 dGVbXSByZXMgPSBuZXcgYnl0ZVtidWYuY2FwYWNpdHkoKV07CiAgICAgICAgIGJ1Zi5nZXQocmVz KTsKICAgICAgICAgdHJ5IHsKLSAgICAgICAgICAgIHJldHVybiBuZXcgU3RyaW5nKHJlcywgIlVT LUFTQ0lJIik7CisgICAgICAgICAgICByZXR1cm4gbmV3IFN0cmluZyhyZXMsICJVVEYtOCIpOwog ICAgICAgICB9IGNhdGNoIChmaW5hbCBVbnN1cHBvcnRlZEVuY29kaW5nRXhjZXB0aW9uIGUpIHsK ICAgICAgICAgICAgIHRocm93IG5ldyBBTEV4Y2VwdGlvbihlKTsKICAgICAgICAgfQpAQCAtMTEx LDcgKzExMSw3IEBACiAgICAgICAgICAgICAgICAgd2hpbGUgKChpIDwgYnl0ZXMubGVuZ3RoKSAm JiAoYnl0ZXNbaV0gIT0gMCkpIHsKICAgICAgICAgICAgICAgICAgICAgaSsrOwogICAgICAgICAg ICAgICAgIH0KLSAgICAgICAgICAgICAgICByZXMuYWRkKG5ldyBTdHJpbmcoYnl0ZXMsIHN0YXJ0 SW5kZXgsIGkgLSBzdGFydEluZGV4LCAiVVMtQVNDSUkiKSk7CisgICAgICAgICAgICAgICAgcmVz LmFkZChuZXcgU3RyaW5nKGJ5dGVzLCBzdGFydEluZGV4LCBpIC0gc3RhcnRJbmRleCwgIlVURi04 IikpOwogICAgICAgICAgICAgICAgIGkrKzsKICAgICAgICAgICAgIH0KICAgICAgICAgICAgIHJl dHVybiAoU3RyaW5nW10pIHJlcy50b0FycmF5KG5ldyBTdHJpbmdbcmVzLnNpemUoKV0pOwo=