On 29.04.2025 16:02, Will Godfrey wrote:
With the current master, and a first time start, on a machine that's been off
overnight there is a series of Xruns on the first note played. After that it
seems fine - even if the machine is switched off, then back on again.
This makes me think Yoshimi is addressing and writing to an area of memory
right outside its 'footprint', which co-incidentally nothing else is using.
I'm guessing that on short periods of downtime that memory area doesn't have
time to relax to its default value.
Because I have to wait 24 hours between tests, I haven't been able to pin this
down :(
This doesn't happen with V2.3.3.3
I think this is more likely to be a coincidence. All Linux kernels do
over-committing, which means the memory you asked for and received,
won't *actually* be allocated until to write to it. Many applications
(ab)use this by allocating way more than they need. Frankly, some
applications allocate an insane amount (I have one app in particular
which takes up more than 1TB of virtual memory, yet it uses only 250MB!).
The thing is that the time it takes for the kernel to allocate your page
when you actually write to it, is extremely non-deterministic, and even
clean-room experiments are going to see very fluctuating results due to
the unpredictability of memory fragmentation. The way real time
applications are supposed to deal with this is twofold:
1. Allocate all memory upfront, the audio loop must never allocate.
2. `mlock()` all the memory you get, to prevent it from being swapped out.
In most cases step 2 can be replaced by simply writing something into
all the buffers, since usually it won't swap until you are low on memory
anyway. But only `mlock()` really guarantees it.
Yoshimi breaks both of these rules, and not in a way which is easy to
fix. We get away with allocating memory *most of time*, but the symptom
you are seeing is likely one of the few cases where it comes back to
bite us. To look on the bright side: Doing allocation-free programming
is really difficult, and Yoshimi works pretty well without it. We have
to appreciate that the developers working on it have one less pain point
to deal with.
--
Kristian
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
