Ah, the PWM thing was in reference to some effects that can be used to push the type of sounds beyond plain square waves.. It's simply play this all back as plain 4bit samples at 15.6KHz, although with the interrupts reduced enormously, but still leaving that 15.6KHz timing precision for when it's actually needed..
This isn't playing back using any PWM methods for the sample data itself.. An earlier version did use Phaerons DAC method which had PWM as part of its design, but I stopped using that because a) it eats the entire POKEY resources b) I couldn't see how I could control the rate as simply, although I didn't put much effort into understanding what he'd done to the poor POKEY to get that method working.. The desire for it to be usable over a 4bit DAC, hence a lot of other machines being able to use this, thankfully kept me from pursuing that avenue
The PWM effects I meant were along the lines of because we are in control of generating each single cycle of the waveform, indeed that's the guts of it in that it just generates the transitions between the hi/lo parts at the right time, with pulse width control, that the codes in the position of being able to take a new frequency and pulse width value (well actually it's two frequency values, which describe the pulse width, although it can be stored as only the PW, and then the correct two F values determined) after each pair of transition value are generated, so with we can create for each voice a pulse width modulated stream of data, along with being able to change the frequency as well.. The high pitched carrier in the case doing it like this is in fact fundamental frequency of the note we want to play, so we want it audible otherwise we might as well pack out bags and go home
I've a newer version coming that has more speedups, and also pre-caches the Nintendo APU registers since the amount of time the NSF player is taking is mental.. It means a little pause at startup, but there's enough working still being down with all the registers changes, and frequency and duty calcs, and also the register unpacking, to be representative of what is expected of a decent music driver, well one that I'd write anyway
And for the record, the reason why the CPU time seem to spike alternately, is simply because it builds in 256 sample chunks, so it tends to cycle between building one buffer being built during the screen period, with more DMA, and the next during the screen off period, roughly.. The VBXE versions display the true nature of the beast