HL/hxcpp: audio2.Audio.samplesPerSecond is 0

[MoritzBrueckner]

Describe the bug When using hxcpp on Windows, kha.audio2.Audio.samplesPerSecond is 0 after System.start() run successfully:

System.start({title: "Test", width: 1024, height: 768}, function(_) {
    trace(kha.audio2.Audio.samplesPerSecond);
    // Output: 0
}

This is independent of whether DirectSound or WASAPI is used.

On HL/C for example, the sample rate gets correctly set by a call to kore_init_audio(), on hxcpp I could not find an equivalent call.

Execution Environment:

• Host system (where you compile your code): Windows 10
• Target system (where you run your code): Windows 10
• IDE used (if any): Visual Studio 2019, compiling in Debug mode for x64
• Kha revision: 6855acab5c7ead698a0e81c31ffd28c02bd04e43, Kinc: 7911546. There are no modified submodules

---

A few other related problems that I want to mention here (I will open issues for them eventually but I first have to do some more tests):

• The sampleRate for the audio buffer in hxcpp seems to be hard-coded, I'm not sure if that's on purpose.
• Kha seems to pretty much ignore the audio hardware's settings (sample rate, buffer size) on all targets I tested.
• On Krom and HL/C, the playback has slightly wrong pitch and speed for me. A workaround is to use 44100 * (44100 / 48000) as the sound's samplerate (at least for my setup). The sounds are all in 44100 Hz.

[MoritzBrueckner]

Unfortunately I now experienced the same issue with hl and I don't know why it didn't happen yesterday. But the good news is that I found a possible solution for hl (not yet for hxcpp).

The call to kore_init_audio() currently looks like this on hl:

https://github.com/Kode/Kha/blob/96528518c62ba4279cfac793d0a9a319d1892624/Backends/Kinc-HL/kha/SystemImpl.hx#L42

The last parameter is implicitly converted to a hl.Ref<Int>, but apparently the reference in the generated c code doesn't point to the integer holding the sample rate, but to a copy of that integer. I'm not sure if this is an issue with hl or expected behaviour, but there is a simple workaround in Kha:

final samplesRef: hl.Ref<Int> = kha.audio2.Audio.samplesPerSecond;
kore_init_audio(kha.audio2.Audio._callCallback, kha.audio2.Audio._readSample, samplesRef);
kha.audio2.Audio.samplesPerSecond = samplesRef.get();

• SystemImpl.c without the workaround:

  r30 = (kha__audio2__$Audio)g$_kha_audio2_Audio;
  r10 = r30->samplesPerSecond; // <-- the bad copy happens here, both values are plain integers
  r11 = &r10;
  r31 = &cl$1;
  r32 = &cl$2;
  hl_kore_init_audio(r31,r32,r11);

• SystemImpl.c with the workaround:

  r30 = (kha__audio2__$Audio)g$_kha_audio2_Audio;
  r10 = r30->samplesPerSecond;
  r11 = &r10;
  r31 = &cl$1;
  r32 = &cl$2;
  hl_kore_init_audio(r31,r32,r11);
  r12 = *r11;
  r30 = (kha__audio2__$Audio)g$_kha_audio2_Audio;
  r30->samplesPerSecond = r12;

@ RobDangerous Would this fix in Kha be ok or is it actually a bug in hl that needs to be fixed?

---

Edit: I also found the issue with hxcpp, the samplerate is assigned in run_kinc(), however that is called after the System.start() callback has run:

https://github.com/Kode/Kha/blob/96528518c62ba4279cfac793d0a9a319d1892624/Backends/Kinc-hxcpp/kha/SystemImpl.hx#L173-L175

[RobDangerous]

The fix is fine by me but I have no idea whether it's an HL-bug - maybe ask Nic about it.

[MoritzBrueckner]

Yeah it seems to be a known Haxe or HL bug: https://github.com/HaxeFoundation/haxe/issues/9803. There doesn't seem to be much activity on this, so for now I would propose to use the workaround from above: https://github.com/Kode/Kha/pull/1361.

As for the hxcpp issue: should there be a similar function like kore_init_audio for Kinc-hxcpp? I guess it wouldn't work well to swap run_kinc() and calling the callback...

[RobDangerous]

Yes, something similar was needed.