is that the DAC runs autonomously, and interrupts when it wants more data. I can't 'choose' how fast to give it samples. As the CPU and DAC clocks won't be exactly synchronised, over time I'll end up with either too many or too few samples in my buffer.

Not if you buffer in between. Since decoding MPEG-frames is independant of clocking, you can run this as fast or slow as you like. Just decode a bit faster if the buffer you're using to feed the DAC is running below a certain treshhold and halt decoding of input-frames if the buffer gets to full.

Or what I did, decode always as fast as possible and try to keep the input-buffers as full as possible. This will allow usage of smaller buffers.

The only problem there is, that of course you need to be in control of your MPEG-stream. That is, it needs to be from an asynchronous source like a disk and not from a synchronous like a live network-stream (like shoutcast).

But in that case, the problem is not the difference between the CPU clock and the DAC clock, but the source-clock (for instance shoutcast-server) and your DAC-clock. That is a standard, but not easy to solve problem.

If that is the case, indeed you have this problem:

I guess I need to add or delete samples, either by changing the buffer or by adjusting the resampling ratio slightly. My question is when to do it and how much to adjust.

You may not believe how many commercial products just use one buffer and when it runs out, stall the whole system untill new data is there, and simply trow samples away. Usually the clock-differences are so small we are talking about just a few samples per hour or less!

Of course if your product doesn't allow this, you need to take care of this in a better way, but the solution is hard. Look for instance how it is done in network protocols like RTP/RTCP/etc.

Regards,

Armin