Ahh, thanks everyone!
As it turns out, my problem was in my test patch, and [delay] does work to the nearest 64 samples, as I verified by using a [tabwrite~] and toggling values to [sig~]. I was lead astray by the use of the [realtime] object to meaure the delay.
What happens, is that the realtime object measures exactly that (as we would hope!). Hence that object *does* get blocked for what I assume is the time between writing to the DAC, and the time the next output buffer gets ready to be written. So, the PD application does have this jitter, but that doesn't mean that the delay isn't correct, because PD messages get activated not in real time but several times (DAC-buffer-size/PD-block-size?) in the course of generating an output buffer to write to the DAC.
Hope I explained that clearly enough.
Larry