10 Aug
2005
10 Aug
'05
10:34 a.m.
Lee Revell:
On Tue, 2005-08-09 at 16:49 -0400, Paul Davis 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.
On Tue, 2005-08-09 at 22:17 +0000, Salvatore Di
Pietro wrote:
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.
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.