28 Jul
2011
28 Jul
'11
9:02 a.m.
On 07/28/2011 05:34 AM, Gabriel Beddingfield wrote:
On 07/27/2011 09:04 PM, Paul Davis wrote:
http://repo.or.cz/w/jack_interposer.git 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.
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()) 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. 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev