10 Aug
2005
10 Aug
'05
11:34 a.m.
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