19 Sep
2014
19 Sep
'14
11:53 p.m.
On Fri, 19 Sep 2014 17:36:00 -0400
Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Fri, Sep 19, 2014 at 5:32 PM, Paul Davis
<paul(a)linuxaudiosystems.com>
wrote:
Thanks Paul. This makes perfect sense, and again is more-or-less what I'd
guessed. It basically underlines that a client really can't make any
assumptions :(
If a client fails to send anything to the buffer, is it likely to contain just
random data, zeros or the last block of data the client sent?
This may be a bit over the top, but I'm thinking along the lines of a client
knowing it will take (say) 5mS to fully process but only having 2mS available
and deciding to just return a sort of approximation instead.
It's probably not worth the effort, but I wondered if the client could attempt
to be a 'good citizen' and take some form of remedial action.
--
It wasn't me! (Well actually, it probably was)
... the hard part is not dodging what life throws at you,
but trying to catch the good bits.
Say we have A, B & C in that order and B&C each take 3mS to return but A
note that nobody but the user can
know that A is the time hog. A could be a
huge but very efficient signal processor and C could be a badly written
delay line. The amount of time they take relative to what they "should"
take is not known to JACK (and in most cases, not even to the user). takes
6mS. Does C get booted out even though it was A that was the time hog?