Re: [Jackit-devel] port and connection monitoring

On Sun, 2007-04-01 at 00:15 +0200, Fons Adriaensen wrote:
> Hello,
> 
> I've been looking into JACK's API as regards port and connection
> monitoring - those calls used by an app such as qjackctl.
> 
> There are a few odd things there.
> 
> - While you can get a notification for each port created or removed
> there seems to be no such thing for connections or disconnections.
> Apparently the only thing you can do when getting a graph-reorder
> callback is to scan all connections of all ports of all clients,
> and sort out what has changed. This is not very useful.

Agreed.  Working around this for Patchage was incredibly annoying and
ugly (not to mention significantly slower than it needs to be).

Simple connection/disconnection updates from Jack (ie foo:a bar:b were
connected or disconnected) would be a very (very) nice thing.

-DR-


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Jackit-devel] port and connection monitoring

On Sat, 2007-03-31 at 21:34 -0400, Dave Robillard wrote:
> On Sun, 2007-04-01 at 00:15 +0200, Fons Adriaensen wrote:
> > Hello,
> > 
> > I've been looking into JACK's API as regards port and connection
> > monitoring - those calls used by an app such as qjackctl.
> > 
> > There are a few odd things there.
> > 
> > - While you can get a notification for each port created or removed
> > there seems to be no such thing for connections or disconnections.
> > Apparently the only thing you can do when getting a graph-reorder
> > callback is to scan all connections of all ports of all clients,
> > and sort out what has changed. This is not very useful.
> 
> Agreed.  Working around this for Patchage was incredibly annoying and
> ugly (not to mention significantly slower than it needs to be).
> 
> Simple connection/disconnection updates from Jack (ie foo:a bar:b were
> connected or disconnected) would be a very (very) nice thing.

Agreed. I'm using the graph order callback and iterating over all ports
in Dino as well.

--ll

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your

Re: [Jackit-devel] port and connection monitoring

On Sun, Apr 01, 2007 at 11:49:53AM +0200, Lars Luthman wrote:

> Agreed. I'm using the graph order callback and iterating over all ports
> in Dino as well.

Using _only_ the graph reorder callback will not work in all cases.

When a new app is started, you normally get a number of port-registration
callbacks followed by a graph-reorder. Even if you ignore the port
callbacks you will discover the new app in the graph callback. So
far so good.

But I have one app that creates 64 output ports. When this is started,
I _first_ get a graph callback - and scanning the ports at that time
doesn't show the new ones - followed by the port callbacks.
So ignoring the port callbacks means you discover the new app only
later, when it gets connected.

So solve this you need to do the scanning also on each port callback.

Of course you can just set a flag, wait a tenth of second until all port
callbacks have arrived, then do the scan once.

Doing this you get O(N^2) complexity, where N is the number of ports.
Without the waiting it's O(N^3). A good interface could be O(N) or
even a O(1).

--

-- 
FA

[Jackit-devel] FreeBoB to FFADO migration & jackd backend

Hi all,

I'm doing the code migration from freebob to ffado, and I wanted to ask 
the opinions on what to do with the backend.

First of all, for those not at LAC: the FreeBoB project is being renamed 
to FFADO (Free Firewire Audio Drivers). This because this name is 
platform & vendor agnostic, which better reflects the current situation 
and gives us a better perspective for the future.

Now to the real issue:
The current backend bears the name 'freebob', and should therefore be 
renamed to something else (in order to avoid confusion). The question 
then becomes: what should it be renamed to?

There are IMHO 2 options: 'ffado' or 'firewire'. Personally I would opt 
for the second name. The FFADO project aims to support all firewire 
audio devices anyway so I guess we can do this. I feel that end-users 
will have less problems with figuring out what the backend does when 
it's called 'firewire'.

A related issue is: what about the freebob backend? The long-term ideal 
situation of course would be to have only one firewire backend. But do 
we keep it for people still using the old libraries? Or do we require 
everybody to upgrade to FFADO when they want a newer jackd? When 
released, FFADO will be a superset of FreeBoB, therefore 'functionally' 
there will be no problem. There are however some issues with respect to 
installation (e.g. needs kernel >= 2.6.21 to operate properly), so that 
might cause some problems when trying to propagate this into distro's.

Re: [Jackit-devel] FreeBoB to FFADO migration & jackd backend

Pieter Palmers wrote:
> Hi all,
> 
> I'm doing the code migration from freebob to ffado, and I wanted to ask 
> the opinions on what to do with the backend.
> 
> First of all, for those not at LAC: the FreeBoB project is being renamed 
> to FFADO (Free Firewire Audio Drivers). This because this name is 
> platform & vendor agnostic, which better reflects the current situation 
> and gives us a better perspective for the future.
> 
> Now to the real issue:
> The current backend bears the name 'freebob', and should therefore be 
> renamed to something else (in order to avoid confusion). The question 
> then becomes: what should it be renamed to?

what do you mean with back-end in this case: the kernel-module or the
user-space library?

kernel module: "firewire" is probably the best name. - but I guess it
has legal issues, too! - "linux1394" is IMO better than "freebob".

libs are more complicated, even/esp. if they superseed the functions in
the old-library..

> There are IMHO 2 options: 'ffado' or 'firewire'. Personally I would opt 
> for the second name. The FFADO project aims to support all firewire 
> audio devices anyway so I guess we can do this. I feel that end-users 
> will have less problems with figuring out what the backend does when 

Re: [Jackit-devel] FreeBoB to FFADO migration & jackd backend

Robin Gareus wrote:
> Pieter Palmers wrote:
>> Hi all,
>>
>> I'm doing the code migration from freebob to ffado, and I wanted to ask 
>> the opinions on what to do with the backend.
>>
>> First of all, for those not at LAC: the FreeBoB project is being renamed 
>> to FFADO (Free Firewire Audio Drivers). This because this name is 
>> platform & vendor agnostic, which better reflects the current situation 
>> and gives us a better perspective for the future.
>>
>> Now to the real issue:
>> The current backend bears the name 'freebob', and should therefore be 
>> renamed to something else (in order to avoid confusion). The question 
>> then becomes: what should it be renamed to?
> 
> 
> what do you mean with back-end in this case: the kernel-module or the
> user-space library?
The backend for jackd:

jackd -d alsa
jackd -d freebob
jackd -d firewire?

> 
> kernel module: "firewire" is probably the best name. - but I guess it
> has legal issues, too! - "linux1394" is IMO better than "freebob".

Re: [Jackit-devel] FreeBoB to FFADO migration & jackd backend

Pieter Palmers wrote:
> Robin Gareus wrote:
>> Pieter Palmers wrote:
>>> Hi all,

>>> [..]

> jackd -d alsa
> jackd -d freebob
> jackd -d firewire?

honestly I don't own firewire hardware myself, but I'd vote for
 "-d firewire" !

on a related issues: would it make sense to provide aliases for the
drivers?  or a step further: collection of "known to work
configurations" for common SICs (fi. map VENDOR/ID,... -> suggest driver
and options eg. "-n3", etc.)

>>
>> kernel module: "firewire" is probably the best name. - but I guess it
>> has legal issues, too! - "linux1394" is IMO better than "freebob".
> 
> Legal issues are no issue. As far as I understand our communication with
> 1394TA correctly, there should be no problem in getting a license for
> the firewire name, if that is even necessary.

great. that makes sense: freebob/ffado complies to the specs and thus
should be allowed to display the "firewire" logo with pride!

Re: [Jackit-devel] port and connection monitoring

On Sun, 2007-04-01 at 12:22 +0200, Fons Adriaensen wrote:
> On Sun, Apr 01, 2007 at 11:49:53AM +0200, Lars Luthman wrote:
> 
> > Agreed. I'm using the graph order callback and iterating over all ports
> > in Dino as well.
> 
> Using _only_ the graph reorder callback will not work in all cases.
> 
> When a new app is started, you normally get a number of port-registration
> callbacks followed by a graph-reorder. Even if you ignore the port
> callbacks you will discover the new app in the graph callback. So
> far so good.
> 
> But I have one app that creates 64 output ports. When this is started,
> I _first_ get a graph callback - and scanning the ports at that time
> doesn't show the new ones - followed by the port callbacks.
> So ignoring the port callbacks means you discover the new app only
> later, when it gets connected.

This happens even if there are connections to the new ports?  That's
definitely a bug.

-DR-


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: [Jackit-devel] FreeBoB to FFADO migration & jackd backend

Pieter Palmers <pieterp <at> joow.be> writes:

> code migration from freebob to ffado

How about a friendly name?;). This is a very important part of a piece
of code, in my opinion, as it creates an exotic atmosphere;). 

> Free Firewire

Shouldn't we stay as far away from this name as possible?. The
international standard is 1394 and this is an implementation of that
specification.

I don't think we should mention the name firewire anywhere, other than
in a FAQ;).

--

-- 
Esben Stien is b0ef <at> e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
           sip:b0ef <at>    e     e 
           jid:b0ef <at>     n     n

Re: [Jackit-devel] port and connection monitoring

On Sun, Apr 01, 2007 at 03:30:18PM -0400, Dave Robillard wrote:

> > But I have one app that creates 64 output ports. When this is started,
> > I _first_ get a graph callback - and scanning the ports at that time
> > doesn't show the new ones - followed by the port callbacks.
> > So ignoring the port callbacks means you discover the new app only
> > later, when it gets connected.
> 
> This happens even if there are connections to the new ports?  That's
> definitely a bug.

No, when a connection is made to the new app there is a graph-reorder cb
and then all new ports are visible.

The point is that relying only the graph-reorder cb to discover the new
app will not work in this case as the this cb is made before the new ports
exist. 

--

-- 
FA

Follie! Follie! Delirio vano è questo !

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV