10 Aug
2005
10 Aug
'05
12:12 a.m.
On Tue, 2005-08-09 at 16:49 -0400, Paul Davis wrote:
On Tue, 2005-08-09 at 22:17 +0000, Salvatore Di Pietro
wrote:
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.
Does this sound reasonable?
Lee
Moreover, using jack_bufsize, or resizing buffer
within Ardour, causes
complete muting of output sound (bit not clients death, as it was
before), until I restart jack.
Notice that this "complete muting" only affects the output ports, i.e. I
can continue recording with qarecord, or ardour, I just cannot hear (and
monitor) anything anymore until I restart jack and its clients.
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.