Yes, my philosophy is that if there's not a good reason why it shouldn't work, then it should.
And in this case I think I can get it to work (the thing is mainly that the processing speed is critical, worst case I could shave off a row of scanlines to speed it up and make it fast enough, but I'd rather not).
The timing is not too critical, just synchronize on a per-frame basis, 60 Hz.
With Kefrens bars and the endtune it's simple: the timing is far more critical. Kefrens bars needs to be timed exactly to the start of each scanline, so that is roughly 262*60Hz = 15.7KHz, and the endtune needs to be timed to 16.5 KHz sample replay.
This is basically maxing out the CPU, and the timing is done by hand-crafting the code to take an exact amount of cycles. Adding any kind of synchronization, such as polling loops or timer interrupts is going to add a lot of CPU overhead, and suddenly you may need a CPU that is more than twice as fast to do the same effect in a way that it is not directly dependent on the CPU speed.
So there isn't really a way to fix this. The same effects may suddenly require a 286 or more, which defeats the point, and they aren't really the same effects anymore, because they work in a different way.