Program is very laggy and unstable under Windows

[freq-mod]

Under Linux, SMF-DSP works fine, without any problems whatsoever. Under Windows 10 x64, with same hardware, it is unusable:

• up to 14 seconds delay between selecting the midi file and any sound starting to play
• no sync between piano display and audio
• extreme lag, songs are played back at fraction of their speed
• player often ends up unresponding, mostly when trying to close it

What's weird it doesn't use more than 5% of CPU 🤔 Version I downloaded is 32-bit Windows artifact from Github Actions.

[jpcima]

There is a problem synchronizing audio and midi timing, in case of under-run or disruption. (like pulseaudio suspend) And I haven't identified a way that I can compensate this disruption unfortunately.. still researching for solutions

There is a timing drift which I know can accumulate over time, and can be created also on linux when something is causing pulseaudio to suspend temporarily.

It's when the audio clock is getting behind the midi clock, but I can't explain why Windows would be more affected, working pretty ok on my side.

Have you tried perhaps to increase synth-audio-latency?

[freq-mod]

Have you tried perhaps to increase synth-audio-latency?

yeah, from 50 to 250. I can't tell if it changed anything, to be honest. Maaaaybe it's marginally better

[freq-mod]

But, tbh, audio/piano desync is the least problem. This happens if program is used for a few minutes: crash.zip - it is supposed to passport.mid, btw. And it's one of the least extreme cases, most of the time midi payback just "hangs"

[freq-mod]

Also, I tested SMF-DSP on a much more powerful Windows PC (quad core Ryzen 5). Results were pretty much the same, so it's not a hardware problem.

[jpcima]

I'm not able to reproduce a problem like described on up-to-date Windows OS. The software runs normal. Are you able to run ./smf-dsp.exe in a unix-style shell? (git bash/msys2) This shows a console log, which might give some clues.

[freq-mod]

$ ./smf-dsp.exe 22:32:40.844 [-] info Start 22:32:40.892 [-] info Configuration directory: C:/Users/user/AppData/Local/SMF-DSP/ 22:32:40.894 [-] info Loading theme: default 22:32:40.907 [-] info Perform plugin scan 22:32:40.907 [-] info Use portable application plugin search 22:32:40.907 [-] info Plugin directory: C:/Users/user/Downloads/SMF-DSP 32-bit for Windows/smf-dsp-win32/ 22:32:40.909 [] success Synth plugin found: FM-OPL3 (ADLMIDI) 22:32:40.911 [] success Synth plugin found: Fluidsynth 22:32:40.912 [] success Synth plugin found: MT32EMU 22:32:40.913 [] success Synth plugin found: FM-OPN2 (OPNMIDI) 22:32:40.915 [] success Synth plugin found: SCC (emidi) 22:32:40.916 [] success Synth plugin found: TiMidity++ 22:32:40.917 [-] info Audio interface: WASAPI 22:32:41.045 [-] info Audio device: Speakers (Realtek(R) Audio) 22:32:41.310 [-] info Software latency: 4 s 22:32:41.310 [-] info Nominal buffer size: 176400 22:32:41.310 [*] success Initialized audio device: SoundIo Segmentation fault 🤔

[freq-mod]

it keeps segfaulting when trying to run using git bash

[jpcima]

Software latency: 4 s

Ouch !!!! This is way, way excessive. It's got to do with the soundio build possibly, and how latency is determined, I'll have a look around that code again.

[jpcima]

It's a special case documented in libsoundio when a buffered mode is used. This is fixed in 72a61e8