On 07/28/2011 05:34 AM, Gabriel Beddingfield wrote: > On 07/27/2011 09:04 PM, Paul Davis wrote: >> On Wed, Jul 27, 2011 at 9:40 PM, Gabriel Beddingfield >> <gabrb...@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())
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. > 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@lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev