24 Aug
2017
24 Aug
'17
6:21 p.m.
"Chris Caudle" <chris(a)chriscaudle.org> writes:
On Thu, August 24, 2017 4:12 pm, Malik Costet wrote:
As a note aside: I had the Aeolus/jackd combination occasionally getting
stuck and just producing noise semipermanently. It might have been
because I was running 32-bit applications on 64-bit kernel: ALSA passes
structures into system calls that are different in size for 32-bit and
64-bit code and does no conversions to make them fit. It's a wonder
that the application usually worked. Until it didn't, of course. I was
running a 64-bit Jackd however.
--
David Kastrup
the server should not make it
possible for one misbehaving client to impair functionality of behaving
clients.
In general that should be the case. When clients are too slow in
processing you will sometimes see jackd messages about removing
"zombified" clients.
The behavior you described seems like jackd for some reason was processing
the buffers as if the client app was still filling the buffers with new
data, when in fact it had not.
I think the original message said that jackd kept playing old audio. If it
was just jack playing out the buffers with old data I would expect at most
maybe 30 ms of audio (e.g. 512 samples per period, 3 periods, 48k
samples/second) which would not really be recognizable audio. Was that
what was meant by playing back old audio, or did it mean a recognizable
section of audio, like 250 ms or more? In that case I would suspect the
application was mismanaging the buffers in some way.