I have to avoid confusing the different time scales involved in the mixing business.

0. Mixer time: That does not really exist. Input channels have time / position information, output channels have it. The main mixer just shoves blocks of anonymous samples (or, more properly: audio frames) back and forth. It does not care about time itself.
1. Input file time: Let that be the "native" time base an input file has. Three minutes of 44100 kHz audio input, for example.
2. Filtered input file time: The effect chain might change the timing or just the sampling rate (the latter case just means that one has to be careful when translating sample offsets to time). Notable example is the timepitch filter.
3. Chesamplify time: The almighty audio adaption routine might change both time itself or sampling rate. This is the final context of the sample offsets the mixer handles.
4. Output time: Well, the outputs also have sampling rates and positions. I don't do much with that, but at least one has ot bear in mind that there could be another resampling step from mixer sampling rate to output sampling rate (in future).

Now, which time is the interesting one for the user, to be shown in status display? I think it's input file time, unfiltered. Well, this may be separate from the true playback time, but it identifies certain points in the stream, even if the stream is stretched / squeezed in time. The second verse starts at 1:32, even if it takes over 3 minutes to reach that.

This is actually what is used currently, but with one catch: I try to sutract the amount of samples pushed to the mixer buffer. This is ridiculous. First, those buffered samples have no simple relation to actual input samples, second, the mixer buffer usually is small and at the time the message reaches the client, it might already be played back. Just give the input file time as it is, thank you.

So, this is actually something simple, then. Ignore what's in the processing chain, report the offset of the last sample that has been pushed into that one.

But there is a related issue that I need to handle: When pre-buffering a track (for following, gapless style) .... NO! That was the OLD DerMixD. My memory is really fuzzy. I solved that issue already: Followers are not pre-buffered anymore. The leading inchannel notes its end and tells the following one to take over, nicely placing its data at the right offset to continue.
