Validation tools + patch

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Validation tools + patch

Stéphane Letz
Hi Joq,

Here is our validation tools + patch for jackd. The validation tools  
allow to test most of the Jack API and the patch correct some of the  
problems we discovered while testing.

The corrected functions are: jack_port_unregister, jack_port_lock/
jack_port_unlock, jack_port_by_name and jack_port_by_id.  A check  
must be done on the patch before committing.

The validation tools allow to generate some graph in particular to  
show the behaviour of the jack_frame_time when a client is using the  
Jack API. We discovered that the value returned by jack_frame_time is  
disturbed when the freewheel  mode is used and  buffer size is  
changed. More precisely the jack_frame_time value is disturbed  
*after* the jackd server is starting again (after FW of BS change) It  
takes several second to return to a correct value. It seems that some  
values use in the timing calculation are not re-initialized to  
correct values *after* the FW of BS change.

Stephane and Samuel




jack_test-0.1.tar.gz (23K) Download Attachment
patch.diff (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Validation tools + patch

Alfons Adriaensen
On Tue, Nov 15, 2005 at 02:29:54PM +0100, St?phane Letz wrote:

> The validation tools allow to generate some graph in particular to  
> show the behaviour of the jack_frame_time when a client is using the  
> Jack API. We discovered that the value returned by jack_frame_time is  
> disturbed when the freewheel  mode is used and  buffer size is  
> changed. More precisely the jack_frame_time value is disturbed  
> *after* the jackd server is starting again (after FW of BS change) It  
> takes several second to return to a correct value.

You're observing the filtering action of the DLL.

> It seems that some  
> values use in the timing calculation are not re-initialized to  
> correct values *after* the FW of BS change.

I've long suspected there was something odd there, but never found
the time to look into it in depth. ISTR jackd has three 'states'
governing the DLL and I often wondered why - two should be enough
in all cases. During FW, the DLL should be 'frozen', as it has no
valid information to work on. Those DLL state elements that represent
a deviation from nominal sample frequency will still be valid after
the FW.

--
FA







-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Validation tools + patch

Stéphane Letz

Le 15 nov. 05 à 15:00, Alfons Adriaensen a écrit :

> On Tue, Nov 15, 2005 at 02:29:54PM +0100, St?phane Letz wrote:
>
>> The validation tools allow to generate some graph in particular to
>> show the behaviour of the jack_frame_time when a client is using the
>> Jack API. We discovered that the value returned by jack_frame_time is
>> disturbed when the freewheel  mode is used and  buffer size is
>> changed. More precisely the jack_frame_time value is disturbed
>> *after* the jackd server is starting again (after FW of BS change) It
>> takes several second to return to a correct value.
>
> You're observing the filtering action of the DLL.

>
>> It seems that some
>> values use in the timing calculation are not re-initialized to
>> correct values *after* the FW of BS change.
>
> I've long suspected there was something odd there, but never found
> the time to look into it in depth. ISTR jackd has three 'states'
> governing the DLL and I often wondered why - two should be enough
> in all cases. During FW, the DLL should be 'frozen', as it has no
> valid information to work on. Those DLL state elements that represent
> a deviation from nominal sample frequency will still be valid after
> the FW.
>
> --  

Ok, but the thing is that this "adapdation"  behaviour is not seen at  
starting time.
So in jackdmp version I just re-initialzed the DLL values to the one  
it get at start time (basically it does something special for the  
*first* cycle  in jack_run_cycle with the engine->first_wakeup flag  
and the second_order_integrator is set to 0) when jack restart after  
FW or buffer size changes.
Then the adapdation period is then much faster.

Do you think this is correct?

Stephane

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
<a href="http://ads.osdn.com/?ad_idv28&alloc_id845&op=click">http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Validation tools + patch

Alfons Adriaensen
On Tue, Nov 15, 2005 at 03:20:00PM +0100, St?phane Letz wrote:

> Ok, but the thing is that this "adapdation"  behaviour is not seen at  
> starting time.
> So in jackdmp version I just re-initialzed the DLL values to the one  
> it get at start time (basically it does something special for the  
> *first* cycle  in jack_run_cycle with the engine->first_wakeup flag  
> and the second_order_integrator is set to 0) when jack restart after  
> FW or buffer size changes.
> Then the adapdation period is then much faster.
>
> Do you think this is correct?

I can't check this here (at work). Will look into it later.

--
FA


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Validation tools + patch

Fons Adriaensen
In reply to this post by Stéphane Letz
On Tue, Nov 15, 2005 at 03:20:00PM +0100, Stéphane Letz wrote:

> So in jackdmp version I just re-initialzed the DLL values to the one  
> it get at start time (basically it does something special for the  
> *first* cycle  in jack_run_cycle with the engine->first_wakeup flag  
> and the second_order_integrator is set to 0) when jack restart after  
> FW or buffer size changes.
> Then the adapdation period is then much faster.
>
> Do you think this is correct?

Yes, that seems to be correct. You *could* re-use the second
integrator value after a FW, or multiply it by the buffer size
ratio after a change, but it's not really necessary.

--
FA



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
<a href="http://ads.osdn.com/?ad_idv28&alloc_id845&op=click">http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel