dirkwhoffmann
commented
4 years ago I need to give you some background information first. In earlier versions of VirtualC64, I had lots of trouble with buffer underflows and overflows. That was because the emulator and the audio engine needed to be synced perfectly to avoid these issues. Eventually I came up with the idea to get both in sync by slightly adjusting the sample rate when an overflow or underflows occurred.
Let’s have a look at the relevant code snippet. Hot stuff, buckle up 😬:
void
SIDBridge::handleBufferOverflow()
{
// There are two common scenarios in which buffer overflows occur:
//
// (1) The consumer runs slightly slower than the producer.
// (2) The consumer is halted or not startet yet.
debug(2, "SID RINGBUFFER OVERFLOW (r: %ld w: %ld)\n", readPtr, writePtr);
// Determine the elapsed seconds since the last pointer adjustment.
uint64_t now = mach_absolute_time();
double elapsedTime = (double)(now - lastAlignment) / 1000000000.0;
lastAlignment = now;
// Adjust the sample rate, if condition (1) holds.
if (elapsedTime > 10.0) {
bufferOverflows++;
// Decrease the sample rate based on what we've measured.
int offPerSecond = (int)(samplesAhead / elapsedTime);
setSampleRate(getSampleRate() - offPerSecond);
}
// Reset the write pointer
alignWritePtr();
}As mentioned in the code, there are two common situations for buffer overflows to occur. Situation (1) is the one we want to use for sample rate adjustment. In situation (2), we don’t want to change the sample rate.
Hence, the function needs to find out if situations (1) or (2) holds. The main idea is to compute the elapsed time between two consecutive buffer overflows (variable elapsedTime represents this value in seconds). If the last buffer overrun was more than 10 seconds ago, the function assumes situation (1) and slightly adjust the sample rate. In original VirtualC64, this code works pretty well, so I think we should keep it for the web version 🤤.
This means that I have to reject my previous claim that the timing stuff is irrelevant for the web version. I simply forgot about the fact that the timing stuff is needed for making sampling rate adjustment to work.
the core periodically likes to change sample rate from ... well ... 44100 to 44100
This is, because the timing related variables have wrong units. In your implementation, I presume that elapsedTime is a very large number (it should be seconds). As a result, VirtualC64 thinks that the last buffer overflow was years ago and to fix that, it has to change the sampleRate by an amount that is smaller than 1 Hz. Because the sample rate is an integer, it is clamped to 0 Hz.
If my explanation was clear enough, the answers to the following questions should be superfluous.
does the web Audio has to read more often or a larger amount to prevent these ?
Nope. If you start with a sample rate that is roughly correct (first buffer exception is more than 10 sec away), the adjustment code does the rest for you 😎.
does that mean that when I put the c64web to halt, that I have to stop reading samples from the SID in my web audio stream ?
No, you can keep on reading samples. Buffer underflows will occur frequently, but the handler won’t screw up anything (it’ll detect situation (2)). The only annoying thing is the large amount of debug messages in level 2.
mithrendal
to check the last consumer🤗 of mach_absolute_time I enabled
c64->sid.setDebugLevel(2);when running vc64web ... this interestingly logs overflows in the sid every second or so 😳
when vc64web is halted it logs many many underruns per second ... watch out for MSG_HALT where the underruns wave begins
Question for the underruns... does that mean that when I put the c64web to halt, that I have to stop reading samples from the SID in my web audio stream ?
Question for the overruns ... does the web Audio has to read more often or a larger amount to prevent these ?
is it ok when I only read mono samples like in the current implementation?
Is the the over and underruns a bad thing that has to be corrected or should I just don't care about it ? Sound for my ears is fine anyway...
What is strange though is that the core periodcally likes to change sample rate from ... well ... 44100 to 44100 🙄... why did it want to do that ?🤔
SIDBridge: Changing sample rate from 44100 to 44100 vC64.html:1:528 ReSID: Setting sample rate to 44100 samples per second. vC64.html:1:528 FastSID: Setting sample rate to 44100 vC64.html:1:528