Checking the Jack API

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

Checking the Jack API

Stéphane Letz
We are in the process of checking the Jack API with automatic testing  
tools. We are discovered several problems on some functions (probably  
not used so often...) that is: jack_port_by_name, jack_port_by_id ,  
jack_port_lock/unlock, and jack_port_tie/untie

- we have a patch to correct most of the problems. As a consequence  
we had to correct jack_port_unregister also. As a consequence of this  
correction, some clients (like Ardour ) break because they seem to  
incorrectly use jack_port_unregister several time for a same port...

-  jack_port_tie/untie does not work, but correcting them would  
require some deeper changes in the jack port data structure. Are  
those function really needed or could it be possible to just remove  
them from the API?

- there is a final issue : jack_port_register works even if an empty  
string is used for the portname, and jack_port_register allows to  
register several ports with the same name. Should these two cases be  
checked and forbidden?

Comments?

Stephane and Samuel


-------------------------------------------------------
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Jack O'Quin-2
Stéphane Letz <[hidden email]> writes:

> We are in the process of checking the Jack API with automatic testing
> tools.

Good work.  Are these tools generally available?  Only on OSX?

> We are discovered several problems on some functions (probably not
> used so often...) that is: jack_port_by_name, jack_port_by_id ,
> jack_port_lock/unlock, and jack_port_tie/untie

I would like to look at the fixes.  We may need to decide which are
safe on a case-by-case basis.

> - we have a patch to correct most of the problems. As a consequence
> we had to correct jack_port_unregister also. As a consequence of this
> correction, some clients (like Ardour ) break because they seem to
> incorrectly use jack_port_unregister several time for a same port...

In my view, this is not a good time (in the pre-1.0 release cycle) to
introduce incompatible API changes.  Even to fix a bug.  The change is
likely to cause more trouble than the bug did.

> -  jack_port_tie/untie does not work, but correcting them would
> require some deeper changes in the jack port data structure. Are
> those function really needed or could it be possible to just remove
> them from the API?

IMHO, we should not remove anything at this point in the 1.0 release
cycle.  This kind of cleanup should be done *after* 1.0 (some may
disagree).  :-)

> - there is a final issue : jack_port_register works even if an empty
> string is used for the portname, and jack_port_register allows to
> register several ports with the same name. Should these two cases be
> checked and forbidden?

Not sure about the empty string, "clientname:" might be valid.

I doubt that duplicate names should be allowed.

Thanks for your efforts...
--
  joq


-------------------------------------------------------
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Stéphane Letz

Le 27 oct. 05 à 17:19, Jack O'Quin a écrit :

> Stéphane Letz <[hidden email]> writes:
>
>
>> We are in the process of checking the Jack API with automatic testing
>> tools.
>>
>
> Good work.  Are these tools generally available?  Only on OSX?

Generally available.

>
>
>> We are discovered several problems on some functions (probably not
>> used so often...) that is: jack_port_by_name, jack_port_by_id ,
>> jack_port_lock/unlock, and jack_port_tie/untie
>>
>
> I would like to look at the fixes.  We may need to decide which are
> safe on a case-by-case basis.

I'll send a patch soon.

>
>
>> - we have a patch to correct most of the problems. As a consequence
>> we had to correct jack_port_unregister also. As a consequence of this
>> correction, some clients (like Ardour ) break because they seem to
>> incorrectly use jack_port_unregister several time for a same port...
>>
>
> In my view, this is not a good time (in the pre-1.0 release cycle) to
> introduce incompatible API changes.  Even to fix a bug.  The change is
> likely to cause more trouble than the bug did.

It does not change the API.
Only change the internal implementation (basically  
jack_port_unregister  now free the port instead of letting it in the  
client port list)


>
>
>> -  jack_port_tie/untie does not work, but correcting them would
>> require some deeper changes in the jack port data structure. Are
>> those function really needed or could it be possible to just remove
>> them from the API?
>>
>
> IMHO, we should not remove anything at this point in the 1.0 release
> cycle.  This kind of cleanup should be done *after* 1.0 (some may
> disagree).  :-)
>
>
>> - there is a final issue : jack_port_register works even if an empty
>> string is used for the portname, and jack_port_register allows to
>> register several ports with the same name. Should these two cases be
>> checked and forbidden?
>>
>
> Not sure about the empty string, "clientname:" might be valid.

The doc says for jack_port_register:

"All ports have a type, which may be any non-NULL and non-zero length  
string, passed as an argument."

>
> I doubt that duplicate names should be allowed.

I agree since  duplicate clients are also *not* allowed...

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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Lee Revell
On Thu, 2005-10-27 at 17:32 +0200, Stéphane Letz wrote:
> >
> > I doubt that duplicate names should be allowed.
>
> I agree since  duplicate clients are also *not* allowed...

FWIW I'm pretty sure we've seen users hit by this bug.

Lee



-------------------------------------------------------
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Fons Adriaensen
On Thu, Oct 27, 2005 at 02:04:08PM -0400, Lee Revell wrote:

> > > I doubt that duplicate names should be allowed.
> >
> > I agree since  duplicate clients are also *not* allowed...
>
> FWIW I'm pretty sure we've seen users hit by this bug.

I'd agree. As to the 'tie' feature, I think it should remain.
It's quite useful in some cases (in the same way as the monitor
option on external outputs), and I'm pretty sure it *did* work
at some time.

For the future, I'd love to see a three level port naming
system in the style  client:group:port. It's quite handy if
you use multi-channel signals (e.g. Ambisonics) all the time.
The grouping could be emulated by clients that manage / show
connections such as qjackctl, but things are much easier when
it is supported directly.

--
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Vinay Venkataraghavan
How do I unsubscribe from this list.
Thanks



               
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com


-------------------------------------------------------
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Steve Harris-2
In reply to this post by Fons Adriaensen
On Thu, Oct 27, 2005 at 09:25:00 +0200, fons adriaensen wrote:

> On Thu, Oct 27, 2005 at 02:04:08PM -0400, Lee Revell wrote:
>
> > > > I doubt that duplicate names should be allowed.
> > >
> > > I agree since  duplicate clients are also *not* allowed...
> >
> > FWIW I'm pretty sure we've seen users hit by this bug.
>
> I'd agree. As to the 'tie' feature, I think it should remain.
> It's quite useful in some cases (in the same way as the monitor
> option on external outputs), and I'm pretty sure it *did* work
> at some time.

I dont think its ever worked, but I agree it would be useful if it did. If
you look back in the archives to around the time I was writing meterbridge
you might find some bug reports. I did dig around in the code and found
some logic bugs, but the things I did to try and fix it just made it work
less.

> For the future, I'd love to see a three level port naming
> system in the style  client:group:port. It's quite handy if
> you use multi-channel signals (e.g. Ambisonics) all the time.
> The grouping could be emulated by clients that manage / show
> connections such as qjackctl, but things are much easier when
> it is supported directly.

Another option would be to add a sperator to port names, eg. /, so you can
have arbirary levels of grouping, though that might just be a pain in the
ass for people writing guis.

- Steve


-------------------------------------------------------
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Alfons Adriaensen
On Fri, Oct 28, 2005 at 09:36:52AM +0100, Steve Harris wrote:

> > For the future, I'd love to see a three level port naming
> > system in the style  client:group:port. It's quite handy if
> > you use multi-channel signals (e.g. Ambisonics) all the time.
> > The grouping could be emulated by clients that manage / show
> > connections such as qjackctl, but things are much easier when
> > it is supported directly.
>
> Another option would be to add a sperator to port names, eg. /, so you can
> have arbirary levels of grouping, though that might just be a pain in the
> ass for people writing guis.

That would even be better, in particular for apps like ardour that
have many ports that change all the time. It would be quite useful
to be able to say to qjackctl (or similar apps) 'show me all of
ardour's auxiliary sends' or some such. Structured names is all
you need for that, and things would probably be easier than the
'sorting' that qjackctl relies on now.

--
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Checking the Jack API

Stéphane Letz
In reply to this post by Steve Harris-2

Le 28 oct. 05 à 10:36, Steve Harris a écrit :

> On Thu, Oct 27, 2005 at 09:25:00 +0200, fons adriaensen wrote:
>
>> On Thu, Oct 27, 2005 at 02:04:08PM -0400, Lee Revell wrote:
>>
>>
>>>>> I doubt that duplicate names should be allowed.
>>>>>
>>>>
>>>> I agree since  duplicate clients are also *not* allowed...
>>>>
>>>
>>> FWIW I'm pretty sure we've seen users hit by this bug.
>>>
>>
>> I'd agree. As to the 'tie' feature, I think it should remain.
>> It's quite useful in some cases (in the same way as the monitor
>> option on external outputs), and I'm pretty sure it *did* work
>> at some time.
>>
>
> I dont think its ever worked, but I agree it would be useful if it  
> did. If
> you look back in the archives to around the time I was writing  
> meterbridge
> you might find some bug reports. I did dig around in the code and  
> found
> some logic bugs, but the things I did to try and fix it just made  
> it work
> less.
>

I don't think it ever worked, since the way to solve the bug requires  
a change in the port structure...
I'll try to correct this problem also

>
>> For the future, I'd love to see a three level port naming
>> system in the style  client:group:port. It's quite handy if
>> you use multi-channel signals (e.g. Ambisonics) all the time.
>> The grouping could be emulated by clients that manage / show
>> connections such as qjackctl, but things are much easier when
>> it is supported directly.
>>
>
> Another option would be to add a sperator to port names, eg. /, so  
> you can
> have arbirary levels of grouping, though that might just be a pain  
> in the
> ass for people writing guis.
>
> - Steve

I am sure a lot of things will have to be discussed after a 1.0  
version....

Stephane

PS: I hope to send a patch to correct all detected pb next week. The  
jack_port_register correction can be done without breaking Ardour also.

-------------------------------------------------------
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
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel