Can't you just add another pseudo hardware device to the emuated SNES that claims to be able to affect the CPU just after the beginning of every frame? Then that device would get control at the right spot every frame, without adding any checks in the emulator (since I'm assuming you already have the framework for this sort of event).I simply can't reliably detect the start of vblank and have the video code blitted to the screen. No matter how many places I tell bsnes to check to see if we've reached vblank (over 40,000 times a second), it's still not enough and I miss entire vblank periods 20% of the time. Most likely, there are too many parts in bsnes that eat up so much CPU time that it jumps right over vblank.
Could this be because your application is asking for another page flip before the first one has occurred, and the API must block that thread until the first completes?It's too bad video drivers and/or API developers are too incompetent to design APIs that handle page flipping completely transparently in the background without deadlocking your applications when you request to blit the image to the screen.
This always happens to me when I don't want to slow down and approach the problem in isolation from the main project. At some point in the future I eventually do that, then spend a week or more experimenting with the concepts alone and figure it out. I have to become interested in the topic for its own sake, rather than as a mere problem to be solved and forgotten.Anyway, I've given up, sadly. I can't think of any way to do this, and I've exceeded my patience and run out of ideas.
The number of samples have to vary by one or two, since there is some fraction of a sample extra each frame.Funny that I just now realized that when sinimas made the comment that the number of audio samples generated per video frame should be constant, and while immediately thinking "no, that's not true", realized, "wait... actually, yes, that should be true".
Cosine introduces discontinuities at each point, and it shows in frequency graphs. Here are the four compared (FIR using 11 point kernels), using a sweep from 16 kHz to 0 kHz in a 32 kHz sampled stream, resampled to 44.1 kHz by these.I like cosine, because the graphs for it are prettier, they look almost identical to hermite, and besides the end points, very similar to cubic as well.
You can see the low frequency aliases in linear and cosine (cosine comes out worse in some ways), while Hermite and FIR have one that is mostly inaudible in the upper range.