10 Aug
2005
10 Aug
'05
5:38 p.m.
On Tue, 2005-08-09 at 22:12 -0400, Lee Revell wrote:
On Tue, 2005-08-09 at 16:49 -0400, Paul Davis wrote:
Hmm, I think I might be on to something. This sounds like the exact
same bug, but they can produce it without JACK:
http://www.winehq.org/hypermail/wine-patches/2005/08/0173.html
The WINE developer had the same idea:
//* /*FIXME*/: snd_pcm_mmap_hw_ptr() should not be accessed by a user app. *//
//* It will NOT return what why want anyway. *//
hw_ptr = _snd_pcm_mmap_hw_ptr(wwo->pcm);
I thought, maybe it is not returning the correct information for
GetPosition, so that is why the crackling exists, since new samples are
off-position from what they should be in order to guarantee a smooth
sound
So in both cases we're operating in mmap mode and ALSA is returning a
slightly incorrect hardware pointer which leads to crackling.
Lee
as far as we can tell, this is an ALSA (kernel)
driver issue. it does
not affect other backends, and does not affect (we think) every ALSA
supported piece of h/w. it would be nice for it to be either fixed or at
least tracked down conclusively.
OK, here's an idea. Say there was an off-by-one error or some other bug
in the ALSA middle layer that caused the reported value of the hardware
pointer to be off by one. So snd_pcm_avail_update would report 64
frames available while there were actually 63. If JACK gets scheduled
within the space of one frame (quite possible especially with the RT
kernel, it's a ~20us window at 48KHz) then we could overwrite the wrong
part of the buffer - a frame or two ahead of the hardware pointer.
AFAICT this would introduce a crackle, but no xruns would be reported.