[Windows|macOS|Linux|BSD] - Crash when setting sample rate

[freq-mod]

Checklist

• I am reporting exactly 1 bug with this issue.
• This bug hasn't already been reported.
• This bug hasn't already been fixed in the latest development build.

---

Bug Description

Going into settings, sound tab, setting the sample rate to the highest possible, which is 249600 hz for me, causes to crash the program with terminal output stating:

QFont::fromString: Invalid description '(empty)'
QFont::fromString: Invalid description '(empty)'
QFont::fromString: Invalid description '(empty)'
QFont::fromString: Invalid description '(empty)'
RtAudio pulse: _NOT_ running realtime scheduling
QWidget::setWindowModified: The window title does not contain a '[*]' placeholder
RtAudio pulse: _NOT_ running realtime scheduling
BambooTracker: chip/blip_buf/blip_buf.c:174: blip_clocks_needed: Assertion `samples >= 0 && m->avail + samples <= m->size' failed.
Aborted (core dumped)

How to reproduce

1.Run program
2. Go into config settings, sound tab
3. Set buffer length to sth very low, 3ms should work
4. Set sample rate to highest possible (249600)

System Information

• Operating System: PopOS 22.04 (lol, ubuntu)
• BambooTracker Version: fresh master
• Build Type: self built

[rerrahkr]

Thank you for your report. It seems the buffer length of blip_buf is insufficient. My device cannot output at 249600Hz, so I cannot reproduce it. I don't know what the appropriate length is, so I can only take an ad hoc approach.
In #484, I doubled the buffer size. Will this solve the problem?

[freq-mod]

It appears that it didnt help.

BambooTracker: chip/blip_buf/blip_buf.c:174: blip_clocks_needed: Assertion `samples >= 0 && m->avail + samples <= m->size' failed.
Aborted (core dumped)

Only difference is that it doesnt crashes instantly, only after about 10 seconds, depending on a buffer size.

[rerrahkr]

It is not clear how long the buffer length should be to avoid the problem... If the buffer length is set to be long (e.g. 200 ms), does the problem not occur?

It is not good to have the application forcefully terminate due to abort, so I will try to fix it that the audio processing stops when an error occurs.

[freq-mod]

At over 100 ms, it seems stable, butits unusable due to how distorted, crunchy and laggy sound becomes. It becomes clean at around 20 ms, but then again, it crashes...

[rerrahkr]

Fixed to stop playback and display an error message box without calling abort.
The problem of audio playback not working properly at high sample rates remains, so the settings must be changed, but the worst-case scenario of a crash will be avoided.