On Wed, 2005-08-10 at 14:33 +0200, Kjetil Svalastog Matheussen wrote: > 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. nope. see libjack/driver.c:jack_driver_nt_bufsize() which is called if using the ALSA backend or any other non-thread-providing backend. we stop the backend (e.g. the ALSA PCM device), then reset the parameters. during the reset, the backend calls the engine's buffer size callback, which notifies all clients of the change. then we restart the backend. --p
