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
_______________________________________________
Cmdist mailing list
[email protected]
https://cm-mail.stanford.edu/mailman/listinfo/cmdist
