[CM] Snd: imprecision when playing selections

[Daniel Lopez]

Hi,

I'm finding that when playing a selection, Snd usually doesn't stop (or 
loop) exactly at the end of the selection, but goes further up to a 
number of samples that is a multiple of the audio backend's buffer size.

For example, I've been using ALSA and my mus-alsa-buffer-size is 1024. 
If I have a drum loop loaded in and put the selection end just before a 
clearly visible attack in the waveform, then experiment with moving the 
selection start back and forth and playing the sound with the arrowhead 
at the bottom-left, sometimes I will hear a bit of that attack at the 
end even though it's outside the selection - and more of it if the size 
of the whole selection is just a little over a 1024 length boundary.

If the end of the sound is reached while the playback is overshooting to 
fill its buffer, zeroes are played instead. To test this - hear how this 
plays a smooth loop of 8*1024 buffers of white noise:

(with-sound ()
   (let ((r (make-rand 44100)))
     (do ((i 0 (+ i 1)))
         ((= i 16383))  ; use your own mus-alsa-buffer-size * 8 - 1
       (outa i (rand r)))))
(play-region-forever (select-all))

But if you increase the number in there by 1 to 16384, there's a big 
audible gap in the loop.

I can reduce my ALSA buffer size to some extent by configuration, but 
it's never going to get down to 1 and I reckon Snd should be streaming 
the samples to ALSA in such a way that it's always exact. Tweaking the 
ALSA buffer size is normally only supposed to be about finding out a 
trade off between latency and choppiness depending on the speed of your 
computer (right?).

I tried it with OSS also (well, still ALSA actually but using the OSS 
wrapper) and still have the same type of problem (except here my default 
buffer size is 16384 so it's a lot worse).

I was looking into the source code and to my dismay it seems like this 
might be caused by the core of the sound playback code in snd-dac.c 
rather than any one backend in audio.c. I hope I'm missing something, 
because I imagine it might be quite an upheaval to fix this otherwise. 
Please (if you can) say it ain't so!

Daniel