28 Jul
2011
28 Jul
'11
5:34 a.m.
On 07/27/2011 09:04 PM, Paul Davis wrote:
On Wed, Jul 27, 2011 at 9:40 PM, Gabriel Beddingfield
<gabrbedd(a)gmail.com> wrote:
Very true. I was envisioning that a thread would start and act as the
jack server.
I also considered adding logic to detect if the application violated
rules. (E.g. "this function may only be called from the process
callback." ... like jack_last_frame_time())
As you've suggested to me in the past... one way that this could be
hacked up quickly is to link to have the test program link to
libjackserver.so -- thus becoming jackd.
-gabriel
The mock library wouldn't necc. /work/...
just simply do just enough for
testing.
you have to define "testing" for that to be viable.
suppose you want to test internal client latency or data "movement"
that relies on JACK port connectivity.
this pretty much requires a working libjack that does everything
except talk to a real backend. aka jackd -d dummy
remember that "time" is an important component of any code that uses a
JACK-like API. a test framework has to replicate the periodic nature
of it, at the very least, even if its not RT-ish.