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

From: Kjetil Svalastog Matheussen <k.s.matheussen@email-addr-hidden>
Date: Wed Aug 10 2005 - 15:33:58 EEST

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.
Received on Wed Aug 10 16:15:09 2005

This archive was generated by hypermail 2.1.8 : Wed Aug 10 2005 - 16:15:09 EEST