Yes, good point. The documentation says that as soon as you read the DMAgic status register, it will continue its job.
However, the CPU is still stalled by this and if you haven't unset the 'I' bit in the CPU status register, then the IRQ handler will simply continue from where you read the DMAgic status. So long as you have cleared the source of the IRQ as well.
Unsetting the 'I' bit in an IRQ (with CLI) already causes all kinds of trouble so you're not likely to be doing it.
This would be the theory, at least.
Its not the greatest, IMHO... I'd prefer to see the DMAgic begin its job again _after_ the RTI but its not a great deal different to doing it yourself with a read of the DMAgic status and then an RTI.
As for the prior points of using DMAgic to move audio data into IO registers, this is quite conveniently possibly by setting the IO and HOLD bits in the destination. Using that, you will move the entire source up to size onto the one IO register. Nice!
I've been working with Paul on the DMAgic and the IO bit is now implemented (will be shortly in the repo.).
If the digital audio generator knows the playback rate (which I suppose should be simple enough, you want only a certain range of specific values) and sample size (again, only a couple of values) and has a small buffer, then using the DMAgic to fill it will be trivial and the audio will play.
I think Paul is not going to like the idea, though... He has in the past said that this kind of approach is not really in the spirit of 8bit design. Personally, I don't really mind I suppose but generating the timing for 11025/22050/44100/48000kHz audio will be annoying since these are odd values. Using other sample rates will be awkward because modern tools assume these are standard.
It is all pretty simple compared with other problems though, I think.