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.
