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: > > > 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. > 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
