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!
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 !