New subject: [linux-audio-user] Re: [Jackit-devel] Re: Again on sudden and occasional Jack crackling sound

10 Aug 2005

Lee Revell:
...

 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.

 I suspect it's in the ALSA core (could be alsa-lib or in the kernel) as
 it's been reported with everything from ice1712 to emu10k1 to RME
 hardware to cheap onboard stuff.

Okey, this might be totally wrong. It might be that I haven't fully
understood
how the lock/unlock-stuff in the jack engine works.

But reading the code for jack_driver_buffer_size in jackd/engine, the
following seems to happen:

1. Lock graph
2. Change the buffer sizes integer for all the clients on the server:
   for-each-client-do: client->control->nframes = nframes;
3. Unlock the graph.
4. Lock the graph
5. Send a message to all clients that the buffersize must be changed.
5. Unlock the graph.

So, from what I can see, a process-cycle can happen between point 3 and 4,
where the server think the buffersize is the new value, while the clients
thing the buffersize is the old value.

[linux-audio-user] Re: Again on sudden and occasional Jack crackling sound