[LAD] Testdriven development with JACK?

Robin Gareus robin at gareus.org
Thu Jul 28 07:01:32 UTC 2011


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
>> <gabrbedd at 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev



More information about the Linux-audio-dev mailing list