Falcosoft wrote on 2024-04-21, 22:51:

Yes, and compiling with Visual Studio is not as straightforward as it should be. So more frequent builds would be better.

https://github.com/nukeykt/Nuked-SC55/pull/44 … ment-2070281797

There is a problem compiling Nuked-SC55 with Visual Studio 2022. Now I don't remember the error specifically but you need to manually add the linker flag "/ENTRY:WinMainCRTStartup" otherwise the compilation fails (I haven't found any other ways) . I'm no expert on this, but perhaps there is something wrong with the code that needs to be fixed?

I also think that Visual Studio displays many more warnings with the latest build than before.

EDIT
The error should be "Error LNK2019 unresolved external symbol main referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ)"
https://cplusplus.com/forum/windows/277119/
"you provided a WinMain() as if you were writing a GUI application."
Compilation seems to break at "utf8main_win32.cpp".

Eivind wrote on 2024-04-22, 15:58:

As an unrelated side note - ever since I've started playing with this emulator, I've gotten sporadic (not very frequent) stuck notes. This happens when playing MIDI files from players both on the mac and Pi4, and also when using the Roland UM-ONE connected to a retro computer playing Doom, on both platforms. I always figured this issue had something to do with my MIDI setup, since I don't think anyone else has reported on this? Thoughts?

I tried using the previous Raspberry Pi OS (based on Debian 11 "bullseye") instead of the current Debian 12 "bookworm" version - and that got rid of the stuck notes. However, it also increased the CPU usage substantially, coming very close to the 100% mark. Very hard to know what exactly is the cause of any of this - but at least I feel I'm making progress. Would be very interesting to see if I could get the emulator running on Circle, like the mt32-pi project...

Eivind wrote on 2024-04-23, 10:53:

Eivind wrote on 2024-04-22, 15:58:

As an unrelated side note - ever since I've started playing with this emulator, I've gotten sporadic (not very frequent) stuck notes. This happens when playing MIDI files from players both on the mac and Pi4, and also when using the Roland UM-ONE connected to a retro computer playing Doom, on both platforms. I always figured this issue had something to do with my MIDI setup, since I don't think anyone else has reported on this? Thoughts?

I tried using the previous Raspberry Pi OS (based on Debian 11 "bullseye") instead of the current Debian 12 "bookworm" version - and that got rid of the stuck notes. However, it also increased the CPU usage substantially, coming very close to the 100% mark. Very hard to know what exactly is the cause of any of this - but at least I feel I'm making progress. Would be very interesting to see if I could get the emulator running on Circle, like the mt32-pi project...

Do you have some instructions how to trigger this stuck notes problem in a reproducible way?

Falcosoft wrote on 2024-04-23, 11:14:

Do you have some instructions how to trigger this sticky notes problem in a reproducible way?

Not at all I'm afraid. It happens like once every couple of minutes of continuous playback. Doesn't seem to coincide with anything else AFAIK. I've looked closely at CPU usage and I'm not seeing any correlation.
I'm thinking it probably points to a MIDI message being corrupted or lost somewhere along the path, but I'm not familiar enough with how this works to do more than guess.

Eivind wrote on 2024-04-23, 11:20:

Falcosoft wrote on 2024-04-23, 11:14:

Do you have some instructions how to trigger this sticky notes problem in a reproducible way?

Not at all I'm afraid. It happens like once every couple of minutes of continuous playback. Doesn't seem to coincide with anything else AFAIK. I've looked closely at CPU usage and I'm not seeing any correlation.
I'm thinking it probably points to a MIDI message being corrupted or lost somewhere along the path, but I'm not familiar enough with how this works to do more than guess.

If I understand you correctly it can happen at different places even in case of the same Midi file/game.
This somewhat reminds me to a problem mentioned in an issue report related to compiling/building:
https://github.com/nukeykt/Nuked-SC55/issues/16

000MDK commented 3 weeks ago I don't know yet if this is build-system related or to any of the latest code changes here: any of […]
Show full quote

000MDK commented 3 weeks ago
I don't know yet if this is build-system related or to any of the latest code changes here:
any of my builds are unusable as notes keep getting stuck - this does not happen with binary release 0.1.1
I'll look into it and report back

Just to make sure the problem is related to receiving Midi In data or not you can try to run the 4 demo song of the ROM continuously and notice if the stuck notes problem manifests itself or not.

Falcosoft wrote on 2024-04-23, 11:32:

If I understand you correctly it can happen at different places even in case of the same Midi file/game.

Correct.

Falcosoft wrote on 2024-04-23, 11:32:

This somewhat reminds me to a problem mentioned in an issue report related to compiling/building:
https://github.com/nukeykt/Nuked-SC55/issues/16

That's interesting. Skimming through that thread, it seems like building a 32-bit binary solves the issue? I can try playing around with doing the same on my end, and see if that changes anything! 👍

EDIT:

Falcosoft wrote on 2024-04-23, 11:32:

Just to make sure the problem is related to receiving Midi In data or not you can try to run the 4 demo song of the ROM continuously and notice if the stuck notes problem manifests itself or not.

Yes, that's a good idea! Hard to do on the gui-less RPi4 though - I can try using the full graphical Raspberry Pi OS (but I suspect that's going to be too slow) - or even better, get to implementing controlling the SC55 from a headless build by capturing stdin keys (bypassing SDL).
Should be able to test this quickly on the mac though.

Btw, the rtmidi project is in pretty active development, with the master branch (which we're pulling) being updated frequently...

Eivind wrote on 2024-04-23, 11:40:

Falcosoft wrote on 2024-04-23, 11:32:

Just to make sure the problem is related to receiving Midi In data or not you can try to run the 4 demo song of the ROM continuously and notice if the stuck notes problem manifests itself or not.

Yes, that's a good idea! Hard to do on the gui-less RPi4 though - I can try using the full graphical Raspberry Pi OS (but I suspect that's going to be too slow) - or even better, get to implementing controlling the SC55 from a headless build by capturing stdin keys (bypassing SDL).
Should be able to test this quickly on the mac though.

Tested running the demo songs for 20 minutes on the mac, no stuck notes, perfect playback.

Eivind wrote on 2024-04-23, 12:17:

Eivind wrote on 2024-04-23, 11:40:

Falcosoft wrote on 2024-04-23, 11:32:

Just to make sure the problem is related to receiving Midi In data or not you can try to run the 4 demo song of the ROM continuously and notice if the stuck notes problem manifests itself or not.

Yes, that's a good idea! Hard to do on the gui-less RPi4 though - I can try using the full graphical Raspberry Pi OS (but I suspect that's going to be too slow) - or even better, get to implementing controlling the SC55 from a headless build by capturing stdin keys (bypassing SDL).
Should be able to test this quickly on the mac though.

Tested running the demo songs for 20 minutes on the mac, no stuck notes, perfect playback.

Then the problem is almost sure to be Midi input related. Since the problem cannot be reproduced on Windows and the main difference is that on Windows no middleware is used but WinMM Midi functions directly there is a chance that the problem is middleware/RtMidi related.
There is a commit that has not been included in master so far that uses portMidi instead of RtMidi. You can try it to confirm/refute if the problem is RtMidi specific or not:
https://github.com/nukeykt/Nuked-SC55/pull/17 … 3679fb4f0270b4d

Falcosoft wrote on 2024-04-23, 13:54:

Then the problem is almost sure to be Midi input related. Since the problem cannot be reproduced on Windows and the main difference is that on Windows no middleware is used but WinMM Midi functions directly there is a chance that the problem is middleware/RtMidi related.
There is a commit that has not been included in master so far that uses portMidi instead of RtMidi. You can try it to confirm/refute if the problem is RtMidi specific or not:
https://github.com/nukeykt/Nuked-SC55/pull/17 … 3679fb4f0270b4d

I had stuck notes on Windows 11 when I simply let Doom run unattended for many minutes (could have been 10 or 20 minutes).
Setup: loopMIDI with Nuked-SC55 v0.2.0-hotfix2, RetroBat using the DOSBox-pure core in RetroArch, set to "Frontend MIDI Device" in the core options and the loopMIDI midi device in the general MIDI settings of RetroArch.
System: Ryzen 5 3600XT with 16GByte RAM.

However, to be honest, when I had this stuck notes, I might still have used v0.1.1, so I might give it another try to be sure.

https://files.catbox.moe/97med1.mid#X-Files.mid

I dunno, which did it.
Maybe the float output somehow resampled better by OS/driver?
Or maybe the increased dynamic range?

In any case, the coarse aliasing on the flute lead is gone.
Most of it, anyway. There's a bit of buzz at the end of the flute notes.

I'm gonna put inline resampling and it will be the kitten's tits now.

Falcosoft wrote on 2024-04-23, 13:54:

Then the problem is almost sure to be Midi input related. Since the problem cannot be reproduced on Windows and the main difference is that on Windows no middleware is used but WinMM Midi functions directly there is a chance that the problem is middleware/RtMidi related.
There is a commit that has not been included in master so far that uses portMidi instead of RtMidi. You can try it to confirm/refute if the problem is RtMidi specific or not:
https://github.com/nukeykt/Nuked-SC55/pull/17 … 3679fb4f0270b4d

I tried using portMidi instead of RtMidi, but it was unusably slow on the Pi so I just gave that up.

So, after quite a bit of experimenting, here's where I'm currently at:
- The difference in CPU usage between the two Pi linux distros turned out to be a difference in which cpu scaling governor was set as the default (resulted in different clock speed and thereby cpu % reported).
- Seems like I finally got rid of the stuck/wrong notes issue by wrapping a small piece of existing uart code between a thread lock/unlock. I'm guessing sometimes there'd be a race condition causing errors in the uart_buffer.
- I incorporated Falcosoft's INT16/FLOAT32 code and played around with it. It might not be as clear cut as always using pageSize/pageNum:8192/2 for FLOAT32 - at least not on macOS and linux. Too high a pageSize will cause microscopic tempo stutters, for now something around 6144/3 seems to work better on the Pi at least, but I'll keep experimenting.
- I improved optimizations further (I think I mentioned this earlier) by using C++ template functions and small dispatch tables to pick the correct functions (out of a limited set generated by the compiler) at runtime based on rom set and audio format, to eliminate all those runtime conditionals. I'm apparently getting good performance now on the Pi4 whatever I throw at it. Will make a new branch on my fork on github.

Eivind wrote on 2024-04-24, 21:14:

So, after quite a bit of experimenting, here's where I'm currently at: - The difference in CPU usage between the two Pi linux di […]
Show full quote

So, after quite a bit of experimenting, here's where I'm currently at:
- The difference in CPU usage between the two Pi linux distros turned out to be a difference in which cpu scaling governor was set as the default (resulted in different clock speed and thereby cpu % reported).
- Seems like I finally got rid of the stuck/wrong notes issue by wrapping a small piece of existing uart code between a thread lock/unlock. I'm guessing sometimes there'd be a race condition causing errors in the uart_buffer.
- I incorporated Falcosoft's INT16/FLOAT32 code and played around with it. It might not be as clear cut as always using pageSize/pageNum:8192/2 for FLOAT32 - at least not on macOS and linux. Too high a pageSize will cause microscopic tempo stutters, for now something around 6144/3 seems to work better on the Pi at least, but I'll keep experimenting.
- I improved optimizations further (I think I mentioned this earlier) by using C++ template functions and small dispatch tables to pick the correct functions (out of a limited set generated by the compiler) at runtime based on rom set and audio format, to eliminate all those runtime conditionals. I'm apparently getting good performance now on the Pi4 whatever I throw at it. Will make a new branch on my fork on github.

Does removing those particular conditionals make a big difference? I would have thought those particular conditionals would be "best case scenario" for branch predictors in modern CPU's.

sherman wrote on 2024-04-24, 21:34:

Does removing those particular conditionals make a big difference? I would have thought those particular conditionals would be "best case scenario" for branch predictors in modern CPU's.

It's extremely time consuming and hard to profile each and every conditional in the code, but in general, yeah it makes a pretty substantial difference.
Normally I wouldn't bother with this stuff at all, but this particular code base has quite a few loops each running tens/hundreds of thousands of times per second. Turns out that every bit of branching you can eliminate usually increases performance in these situations.

Eivind wrote on 2024-04-24, 21:14:

- I incorporated Falcosoft's INT16/FLOAT32 code and played around with it. It might not be as clear cut as always using pageSize/pageNum:8192/2 for FLOAT32 - at least not on macOS and linux. Too high a pageSize will cause microscopic tempo stutters, for now something around 6144/3 seems to work better on the Pi at least, but I'll keep experimenting.

Actually we all somewhat missed the fact that the biggest role of pageSize is how frequently the engine updates the Midi state. So actually higher pageSize values even if they increase the stability of audio output they adversely affect Midi precision and timing. The lower the pageSize the better the precision. So I do not know if floating point output on Pi is worth the effort if the price is less precise Midi with timing issues.
The default values of 512/32 chosen by Nukeykt is much more understandable this way. So I suggest that you should never go beyond 2048 pageSize. At the frequency of 66207 (default for mkII) a pagesize of 2048 already means a rather high ~30 ms update period that can cause timing issues in case of tight Midi titles.

Falcosoft wrote on 2024-04-25, 15:04:

Actually we all somewhat missed the fact that the biggest role of pageSize is how frequently the engine updates the Midi state. So actually higher pageSize values even if they increase the stability of audio output they adversely affect Midi precision and timing. The lowest the pageSize the better the precision. So I do not know if floating point output on Pi is worth the effort if the price is less precise Midi with timing issues.
The default values of 512/32 chosen by Nukeykt is much more understandable this way. So I suggest that you should never go beyond 2048 pageSize. At the frequency of 66207 (default for mkII) a pagesize of 2048 already means a rather high ~30 ms update period that can cause timing issues in case of tight Midi titles.

Good points - and it matches what I'm seeing here as well - the timing often seems ever so slightly off when using high pageSizes. But as previously mentioned - on the Pi too low values when using floating point samples is completely unusable and results in ALSA buffer underruns and horrible clicks and noises.

To take a step back - say we're using the emulator to play music from DOS games (which I assume is the main point for most people) - what, if any, advantages are there to using 32-bit float samples vs 16-bit int ones?

Eivind wrote on 2024-04-25, 15:13:

Falcosoft wrote on 2024-04-25, 15:04:

Actually we all somewhat missed the fact that the biggest role of pageSize is how frequently the engine updates the Midi state. So actually higher pageSize values even if they increase the stability of audio output they adversely affect Midi precision and timing. The lowest the pageSize the better the precision. So I do not know if floating point output on Pi is worth the effort if the price is less precise Midi with timing issues.
The default values of 512/32 chosen by Nukeykt is much more understandable this way. So I suggest that you should never go beyond 2048 pageSize. At the frequency of 66207 (default for mkII) a pagesize of 2048 already means a rather high ~30 ms update period that can cause timing issues in case of tight Midi titles.

Good points - and it matches what I'm seeing here as well - the timing often seems ever so slightly off when using high pageSizes. But as previously mentioned - on the Pi too low values when using floating point samples is completely unusable and results in ALSA buffer underruns and horrible clicks and noises.

To take a step back - say we're using the emulator to play music from DOS games (which I assume is the main point for most people) - what, if any, advantages are there to using 32-bit float samples vs 16-bit int ones?

It does not depend on what you use the emulator for (games/Midi files). With the current implementation FLOAT32 doubles dynamic range/sample resolution. More precisely in order to prevent clipping the INT16 output path halves sample resolution in the last step currently. It can be heard in case of any Midi titles since the overall volume of INT16 is halved. And in case of low volume Midi files the noise is also more audible if you want to get the same audio output level.
BTW, on Windows seemingly FLOAT32 has no such negative effect. You can use the same buffer sizes as with INT16. Maybe it's because the native format of shared mode WASAPI (that SDL2 uses on Win Vista+) is 32-bit float.

Eivind wrote on 2024-04-24, 21:14:

- I incorporated Falcosoft's INT16/FLOAT32 code and played around with it. It might not be as clear cut as always using pageSize/pageNum:8192/2 for FLOAT32 - at least not on macOS and linux. Too high a pageSize will cause microscopic tempo stutters, for now something around 6144/3 seems to work better on the Pi at least, but I'll keep experimenting.

Hi.
pageSize/pageNum by default, if I understand correctly, is set to 512:32 (16384). To test, I set it to 512:4. It still seems to work well, is this a correct value or is it too low?
I also noticed that the log console doesn't show the custom buffer (to see if it's working).

Kappa971 wrote on 2024-04-25, 15:49:

Hi. pageSize/pageNum by default, if I understand correctly, is set to 512:32 (16384). To test, I set it to 512:4. It still seems […]
Show full quote

Eivind wrote on 2024-04-24, 21:14:

- I incorporated Falcosoft's INT16/FLOAT32 code and played around with it. It might not be as clear cut as always using pageSize/pageNum:8192/2 for FLOAT32 - at least not on macOS and linux. Too high a pageSize will cause microscopic tempo stutters, for now something around 6144/3 seems to work better on the Pi at least, but I'll keep experimenting.

Hi.
pageSize/pageNum by default, if I understand correctly, is set to 512:32 (16384). To test, I set it to 512:4. It still seems to work well, is this a correct value or is it too low?
I also noticed that the log console doesn't show the custom buffer (to see if it's working).

512/4 compared to 512:32 (default) does not alter the Midi precision/timing at all it only decreases the audio latency. The console only shows the pageSize changes (pageSize /4 exactly as B=xxx).

Falcosoft wrote on 2024-04-25, 15:32:

It does not depend on what you use the emulator for (games/Midi files). With the current implementation FLOAT32 doubles dynamic range/sample resolution. More precisely in order to prevent clipping the INT16 output path halves sample resolution in the last step currently. It can be heard in case of any Midi titles since the overall volume of INT16 is halved. And in case of low volume Midi files the noise is also more audible if you want to get the same audio output level.
BTW, on Windows seemingly FLOAT32 has no such negative effect. You can use the same buffer sizes as with INT16. Maybe it's because the native format of shared mode WASAPI (that SDL2 uses on Win Vista+) is 32-bit float.

I apologize in advance if this is a stupid question, but if you don't ask, you don't learn! 😁
Please help me understand why we'd need to right-shift the 32-bit integer samples coming from pcm.cpp by 15 instead of 14 (I assume 18-bit samples from ROM, shifted up by 14 to fill 32 bits to increase precision in processing)? I'm sure I'm missing something essential here, but why would the right-shifted-by-14 value be clipping at all? Because of the implementation details of the audio processing in pcm.cpp? In my (I'm sure naive) thinking, the original hardware wouldn't produce 18-bit output samples that clipped?