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:
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.
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())
checks for rt-violations.
export LD_PRELOAD=PATH/TO/jack_interposer.so
your_jack_app_to_test
The program will abort as a soon as a non-rt-safe operation is performed
from the jack process callback thread and inform you about the function.