Proposition for easier jackd / jackdmp management for packagers

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

Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz
Hi all,

Some weeks ago we had a discussion about how to allow easier  
cohabitation of jackd  and jackdmp installation. To summarize the  
current situation, jackdmp install phase basically redirect the  
libjack.so link to point to libjackmp.so , so that applications can  
be used transparently with jackdmp. The problem is that as soon as  
this link is broken, jackd cannot be launched anymore (since jackd  
executable *also* uses the libjack.so link). This is a real mess,  
since the 2 server cannot be tested easily by users.

I worked then at the following workaround:

- implement a new libjackdwrapper.so library in jackdmp code base,  
that implement the exact same Jack API. This library dynamically load  
(using dlopen/dlsym) both real libjack.so and libjackdmp.so files.  
When accessed by a jack client (jack_client_open/ jack_client_new),  
the wrapper try to open the jack client using the libjack.so (this  
would mean : the jackd server is currently running) and in case of  
failure,  try to open the jack client using the libjackdmp.so  (this  
would mean : the jackdmp server is currently running). When the  
client is running, all further jack API calls are redirected on the  
running server using the identified library.

- the jackdmp install script  does a libjack.so ==>  
libjackdwrapper.so link.

- the user can start jack or jackdmp and all jack clients launched  
later on correctly see the running server.

This solution already works on the jackdmp side, but not of the jackd  
side because as said before jackd executable *also* uses the  
libjack.so link. Thus one would need to restructure the way the jackd  
code base is compiled on server and client side:

- current situation :  the dynamic library  libjack.so, jackd,  
jack_alsa.so... (basically all drivers) and jack clients link to  
libjack.so

- proposition: define a new libjackd.so dynamic library that would  
contain only the *server* side of the code, jackd, jack_alsa.so...  
(basically all drivers) would link to this new libjackd.so dynamic  
library and  jack clients link to libjack.so (where libjack.so is  
only the *client* side of the code)

Any coments?

Thanks

Stephane



-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Fons Adriaensen-2
On Fri, Jan 05, 2007 at 11:02:12AM +0100, Stéphane Letz wrote:

> Any coments?

Is all this really necessary ? I can't imagine why someone would
need to be able to switch between jackd and jackdmp, except for
testing the latter. Some overhead is perfectly acceptable in that
case.

What I'd like to see is a jackdmp installation that is really
self-contained and doesn't need an existing jackd. Or at least
one that does not assume that jackd is in /usr/local.

--
FA

Lascia la spina, cogli la rosa.


-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Daniel James-2
In reply to this post by Stéphane Letz
Hi Stéphane,

> I worked then at the following workaround:
>
> - implement a new libjackdwrapper.so library in jackdmp code base,  
> that implement the exact same Jack API. This library dynamically load  
> (using dlopen/dlsym) both real libjack.so and libjackdmp.so files.  
> When accessed by a jack client (jack_client_open/ jack_client_new),  
> the wrapper try to open the jack client using the libjack.so

This sounds excessively complicated. Why not just have a completely
separate set of libraries under /usr/lib/jackdmp, with jackdmp run from
a different command line argument? qjackctl already supports multiple
server paths.

Applications using jackdmp transparently is one thing, but surely the
user should have control over which implementation of jackd is run, if
more than one is installed?

 From a distro point of view, we need people to be able to install a
jackdmp package from our repository that does not break the existing
jackd install, or require the removal of all packages with a dependency
on jackd. For the time being, I'd guess most distros will build their
client application packages against classical jackd, since only a
minority of users have dual-core or dual-processor machines.

Anyone trying jackdmp on a production machine will want to keep
classical jackd and all its dependencies installed so they can quickly
switch back if jackdmp does not work for them.

Just to clarify, what happens if a user attempts to run jackdmp on a
single-processor system? Is the performance comparable to classical
jackd, or does it fail entirely?

Cheers!

Daniel

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz
In reply to this post by Fons Adriaensen-2

Le 5 janv. 07 à 12:16, Fons Adriaensen a écrit :

> On Fri, Jan 05, 2007 at 11:02:12AM +0100, Stéphane Letz wrote:
>
>> Any coments?
>
> Is all this really necessary ? I can't imagine why someone would
> need to be able to switch between jackd and jackdmp, except for
> testing the latter. Some overhead is perfectly acceptable in that
> case.

One reason is that jackdmp does not have yet Freebob drivers for  
example, thus you'll still need jackd.

>
> What I'd like to see is a jackdmp installation that is really
> self-contained and doesn't need an existing jackd. Or at least
> one that does not assume that jackd is in /usr/local.

The /usr/local issue is supposed to be improved in current version.  
At least by editing the path in the makefile before compiling.

And jackdmp installation should be self-contained, if not then please  
report the problem you get.

Thanks

Stephane

PS: good luck for your new job!



-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz
In reply to this post by Daniel James-2

Le 5 janv. 07 à 12:13, Daniel James a écrit :

> Hi Stéphane,
>
>> I worked then at the following workaround:
>> - implement a new libjackdwrapper.so library in jackdmp code  
>> base,  that implement the exact same Jack API. This library  
>> dynamically load  (using dlopen/dlsym) both real libjack.so and  
>> libjackdmp.so files.  When accessed by a jack client  
>> (jack_client_open/ jack_client_new),  the wrapper try to open the  
>> jack client using the libjack.so
>
> This sounds excessively complicated. Why not just have a completely  
> separate set of libraries under /usr/lib/jackdmp, with jackdmp run  
> from a different command line argument? qjackctl already supports  
> multiple server paths.
>
> Applications using jackdmp transparently is one thing, but surely  
> the user should have control over which implementation of jackd is  
> run, if more than one is installed?
>
> From a distro point of view, we need people to be able to install a  
> jackdmp package from our repository that does not break the  
> existing jackd install, or require the removal of all packages with  
> a dependency on jackd. For the time being, I'd guess most distros  
> will build their client application packages against classical  
> jackd, since only a minority of users have dual-core or dual-
> processor machines.
>
> Anyone trying jackdmp on a production machine will want to keep  
> classical jackd and all its dependencies installed so they can  
> quickly switch back if jackdmp does not work for them.

Hi Daniel,

This are the points ((-: , allows easy switch between the 2 installed  
version, do not break existing jackd installation *and* transparently  
allow applications to use the correct running server. Applications  
*see* the server by means of libjack.so, the point to keep  
transparent use of applications is to always keep this libjack.so  
entry point.

Let me explain more:

- jackd compilation/install would create (more or less) :  
libjackd.so, jackd, jack_als.so...., and libjack.so. You start the  
server using "jackd -R -d alsa..." or with qjackcl as usual.

- jackdmp compilation/install already creates : libjackdmp.so,  
jackdmp, jack_alsa.so.... (but in a separated folder to avoid clash  
with regular jack drivers), and libjackmp.so.  You start the server  
using "jackdmp -R -d alsa..." or with qjackcl as usual.

- jackdmp installer would add this libjackwrapper.so indirection as  
explained before. Then as a user you do  "jackd -R -d alsa..." or  
with qjackcl as usual, then start jack clients and they see jackd, or  
you do  "jackdmp -R -d alsa..." or with qjackcl as usual then start  
jack clients and they see jackdmp,

-  and in case jackd *and* jackdmp are running at the same time  
(which is not supposed to happen.. but) , then jackd would be choosen  
by default for instance.

>
> Just to clarify, what happens if a user attempts to run jackdmp on  
> a single-processor system? Is the performance comparable to  
> classical jackd, or does it fail entirely?

It just work the same! No performance issue.

In jackdmp view, a mono processor machine is only a "particular case"  
of the MP model.

Regards

Stephane



-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Daniel James-2
Hi Stéphane,

I think your proposal is more likely to be accepted if it doesn't
require modifications to classical jackd.

 >> what happens if a user attempts to run jackdmp on a
>> single-processor system? Is the performance comparable to classical
>> jackd, or does it fail entirely?
>
> It just work the same! No performance issue.
>
> In jackdmp view, a mono processor machine is only a "particular case" of
> the MP model.

In that case, I see much less need to have both classical jackd and
jackdmp installed at the same time. The problem for a distro which
remains is how to solve the dependencies for jack applications when a
user removes jack to replace it with jackdmp.

Cheers!

Daniel


-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Jack O'Quin
In reply to this post by Stéphane Letz
On 1/5/07, Stéphane Letz <[hidden email]> wrote:

> - current situation :  the dynamic library  libjack.so, jackd,
> jack_alsa.so... (basically all drivers) and jack clients link to
> libjack.so
>
> - proposition: define a new libjackd.so dynamic library that would
> contain only the *server* side of the code, jackd, jack_alsa.so...
> (basically all drivers) would link to this new libjackd.so dynamic
> library and  jack clients link to libjack.so (where libjack.so is
> only the *client* side of the code)
>
> Any coments?

This would cause many more maintenance problems than it
could possibly solve.  Users will become hopelessly confused.

We should consider implementing any "pluggable client library"
ideas after release 1.0 is frozen.
--
 joq

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz

Le 5 janv. 07 à 14:17, Jack O'Quin a écrit :

> On 1/5/07, Stéphane Letz <[hidden email]> wrote:
>
>> - current situation :  the dynamic library  libjack.so, jackd,
>> jack_alsa.so... (basically all drivers) and jack clients link to
>> libjack.so
>>
>> - proposition: define a new libjackd.so dynamic library that would
>> contain only the *server* side of the code, jackd, jack_alsa.so...
>> (basically all drivers) would link to this new libjackd.so dynamic
>> library and  jack clients link to libjack.so (where libjack.so is
>> only the *client* side of the code)
>>
>> Any coments?
>
> This would cause many more maintenance problems than it
> could possibly solve.

Well after the jackd change i suggest would be done, the  maintenance  
problems would be on jackdmp side... and I can do that.

> Users will become hopelessly confused.

Maybe, maybe not..
>
> We should consider implementing any "pluggable client library"
> ideas after release 1.0 is frozen.
> --
> joq


)-:

Stephane
-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Kjetil Matheussen
In reply to this post by Stéphane Letz


"Jack O'Quin":

> On 1/5/07, St?phane Letz <[hidden email]> wrote:
>
>> - current situation :  the dynamic library  libjack.so, jackd,
>> jack_alsa.so... (basically all drivers) and jack clients link to
>> libjack.so
>>
>> - proposition: define a new libjackd.so dynamic library that would
>> contain only the *server* side of the code, jackd, jack_alsa.so...
>> (basically all drivers) would link to this new libjackd.so dynamic
>> library and  jack clients link to libjack.so (where libjack.so is
>> only the *client* side of the code)
>>
>> Any coments?

Not really, this sounds like a very good solution to a complicated
problem.


>
> This would cause many more maintenance problems than it
> could possibly solve.  Users will become hopelessly confused.
>

Quite the opposite. This will make many users less confused. The
situation now is that jackd performs inadequate on MP machines and
that it very often crackle when connecting ports. Therefore its not
unlikely that many users want to try jackdmp, where, in the current
situation, the install process is more confusing than this proposal.

Besides, if the necessary modifications are not done to jackd to make it
coexist properly with jackdmp, theres a certain risk that someone forks
it, or at least that many distributions will apply the needed patches
themself. I think its better to do in the main distribution instead, since
its probably not a change that will lead to instabilities or unexpected
behaviours.


-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

cannam
On Friday 05 Jan 2007 13:48, Kjetil S. Matheussen wrote:

> "Jack O'Quin":
> > On 1/5/07, St?phane Letz <[hidden email]> wrote:
> >> - current situation :  the dynamic library  libjack.so, jackd,
> >> jack_alsa.so... (basically all drivers) and jack clients link to
> >> libjack.so
> >>
> >> - proposition: define a new libjackd.so dynamic library that would
> >> contain only the *server* side of the code, jackd, jack_alsa.so...
> >> (basically all drivers) would link to this new libjackd.so dynamic
> >> library and  jack clients link to libjack.so (where libjack.so is
> >> only the *client* side of the code)
> >>
> >> Any coments?
>
> Not really, this sounds like a very good solution to a complicated
> problem.

I also think it's a good idea.  And I don't think anyone who doesn't have
jackdmp installed will notice the difference.

A disadvantage is that if jackd links to libjackd rather than libjack, there
will be some memory wasted in loading both libjackd and libjack (unlike the
current situation where jackd and its clients use the same shared library).

Going a bit further, why not statically link jackd against libjack for
effectively the same result?


Chris

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz

Le 5 janv. 07 à 15:06, Chris Cannam a écrit :

> On Friday 05 Jan 2007 13:48, Kjetil S. Matheussen wrote:
>> "Jack O'Quin":
>>> On 1/5/07, St?phane Letz <[hidden email]> wrote:
>>>> - current situation :  the dynamic library  libjack.so, jackd,
>>>> jack_alsa.so... (basically all drivers) and jack clients link to
>>>> libjack.so
>>>>
>>>> - proposition: define a new libjackd.so dynamic library that would
>>>> contain only the *server* side of the code, jackd, jack_alsa.so...
>>>> (basically all drivers) would link to this new libjackd.so dynamic
>>>> library and  jack clients link to libjack.so (where libjack.so is
>>>> only the *client* side of the code)
>>>>
>>>> Any coments?
>>
>> Not really, this sounds like a very good solution to a complicated
>> problem.
>
> I also think it's a good idea.  And I don't think anyone who  
> doesn't have
> jackdmp installed will notice the difference.
>
> A disadvantage is that if jackd links to libjackd rather than  
> libjack, there
> will be some memory wasted in loading both libjackd and libjack  
> (unlike the
> current situation where jackd and its clients use the same shared  
> library).
>
> Going a bit further, why not statically link jackd against libjack for
> effectively the same result?

Because jackd *and* the drivers need to share the same code and data.

Stephane


-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

cannam
On Friday 05 Jan 2007 14:12, Stéphane Letz wrote:
> Le 5 janv. 07 à 15:06, Chris Cannam a écrit :
> > Going a bit further, why not statically link jackd against libjack for
> > effectively the same result?
>
> Because jackd *and* the drivers need to share the same code and data.

Oh yes.  Ignore me.


Chris

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Daniel James-2
In reply to this post by Kjetil Matheussen
Hi Kjetil,

> Besides, if the necessary modifications are not done to jackd to make it
> coexist properly with jackdmp, theres a certain risk that someone forks
> it, or at least that many distributions will apply the needed patches
> themself. I think its better to do in the main distribution instead

As distro packagers, we'd like to see a solution upstream too.

Cheers!

Daniel

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

John Rigg-3
In reply to this post by Stéphane Letz
On Fri, Jan 05, 2007 at 12:38:18PM +0100, Stéphane Letz wrote:

>
> Le 5 janv. 07 à 12:16, Fons Adriaensen a écrit :
>
> > On Fri, Jan 05, 2007 at 11:02:12AM +0100, Stéphane Letz wrote:
> >
> >> Any coments?
> >
> > Is all this really necessary ? I can't imagine why someone would
> > need to be able to switch between jackd and jackdmp, except for
> > testing the latter. Some overhead is perfectly acceptable in that
> > case.
>
> One reason is that jackdmp does not have yet Freebob drivers for  
> example, thus you'll still need jackd.

Another reason is that jackdmp can't correctly recognize pcm_multi devices
defined in .asoundrc yet (unless that's been fixed since I last tried it).
That means it can't be used with multiple sound cards. On my SMP setup with
3 x Delta 1010 I have to use jackd.

However, when stereo mastering I can't use pcm_multi without JAMin indicating
xruns, so I only run JACK on a single card. In this case it would be
nice to have the option of using jackdmp.

John

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz

Le 5 janv. 07 à 17:30, John Rigg a écrit :

> On Fri, Jan 05, 2007 at 12:38:18PM +0100, Stéphane Letz wrote:
>>
>> Le 5 janv. 07 à 12:16, Fons Adriaensen a écrit :
>>
>>> On Fri, Jan 05, 2007 at 11:02:12AM +0100, Stéphane Letz wrote:
>>>
>>>> Any coments?
>>>
>>> Is all this really necessary ? I can't imagine why someone would
>>> need to be able to switch between jackd and jackdmp, except for
>>> testing the latter. Some overhead is perfectly acceptable in that
>>> case.
>>
>> One reason is that jackdmp does not have yet Freebob drivers for
>> example, thus you'll still need jackd.
>
> Another reason is that jackdmp can't correctly recognize pcm_multi  
> devices
> defined in .asoundrc yet (unless that's been fixed since I last  
> tried it).
> That means it can't be used with multiple sound cards. On my SMP  
> setup with
> 3 x Delta 1010 I have to use jackd.
>

The ALSA backend code has been synchronized with jack SVN version in  
jackdmp 0.59 package. Maybe you should try again and report problems.


>
> However, when stereo mastering I can't use pcm_multi without JAMin  
> indicating
> xruns, so I only run JACK on a single card. In this case it would be
> nice to have the option of using jackdmp.
>
> John

Thanks

Stephane



-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Lee Revell
In reply to this post by John Rigg-3
On Fri, 2007-01-05 at 16:30 +0000, John Rigg wrote:
> Another reason is that jackdmp can't correctly recognize pcm_multi
> devices defined in .asoundrc yet (unless that's been fixed since I
> last tried it). That means it can't be used with multiple sound cards.
> On my SMP setup with 3 x Delta 1010 I have to use jackd.

I think both jackd and jackdmp need to be updated to use the new device
enumeration API that was added to ALSA in 1.0.13 or 1.0.14.

Lee


-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Fernando Lopez-Lezcano
In reply to this post by Stéphane Letz
On Fri, 2007-01-05 at 13:00 +0100, Stéphane Letz wrote:
> Le 5 janv. 07 à 12:13, Daniel James a écrit :
> > Just to clarify, what happens if a user attempts to run jackdmp on  
> > a single-processor system? Is the performance comparable to  
> > classical jackd, or does it fail entirely?
>
> It just work the same! No performance issue.

Nope, it works _better_ :-)

If I understand correctly jackdmp does cannot have xruns if reordering
the graph on client connections / disconnections takes a while.

-- Fernando



-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Stéphane Letz

Le 5 janv. 07 à 22:08, Fernando Lopez-Lezcano a écrit :

> On Fri, 2007-01-05 at 13:00 +0100, Stéphane Letz wrote:
>> Le 5 janv. 07 à 12:13, Daniel James a écrit :
>>> Just to clarify, what happens if a user attempts to run jackdmp on
>>> a single-processor system? Is the performance comparable to
>>> classical jackd, or does it fail entirely?
>>
>> It just work the same! No performance issue.
>
> Nope, it works _better_ :-)
>
> If I understand correctly jackdmp does cannot have xruns if reordering
> the graph on client connections / disconnections takes a while.
>
> -- Fernando

Yes, your'e right, it's better in this area, but I was not  
considering that as "performance" gain per se ((-:
Another gain in the fact than in "asynchronous mode", the system get  
somewhat more robust (less audible audio glitches) in a loaded context.

Stephane


-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

Fernando Lopez-Lezcano
In reply to this post by cannam
On Fri, 2007-01-05 at 14:06 +0000, Chris Cannam wrote:

> On Friday 05 Jan 2007 13:48, Kjetil S. Matheussen wrote:
> > "Jack O'Quin":
> > > On 1/5/07, St?phane Letz <[hidden email]> wrote:
> > >> - current situation :  the dynamic library  libjack.so, jackd,
> > >> jack_alsa.so... (basically all drivers) and jack clients link to
> > >> libjack.so
> > >>
> > >> - proposition: define a new libjackd.so dynamic library that would
> > >> contain only the *server* side of the code, jackd, jack_alsa.so...
> > >> (basically all drivers) would link to this new libjackd.so dynamic
> > >> library and  jack clients link to libjack.so (where libjack.so is
> > >> only the *client* side of the code)
> > >>
> > >> Any coments?
> >
> > Not really, this sounds like a very good solution to a complicated
> > problem.
>
> I also think it's a good idea.  And I don't think anyone who doesn't have
> jackdmp installed will notice the difference.

good_idea++

We really need something that will solve this problem transparently.

>From the point of view of a packager this is what should happen (spelled
out in excruciating detail, sorry for the length):

[to avoid the "my distro is better than yours" problem let's use "dumb",
a new package dependency manager I just invented :-]

I want to install jack, so I open a terminal and say:

  dumb install jack-audio-connection-kit

which brings all the packages I need.
I want a drum machine:

  dumb install hydrogen

so now I can "jackd -R -d alsa" and hydrogen should happily start and
work (both are packaged by an imaginary perfect distro where all
programs always work out of the box :-).

Now I want to try out jackdmp:

  dumb install jackdmp
  (or whatever is the final package name chosen)

Now I should be able to stop jackd and "jackdmp -R -d alsa". Hydrogen
should still work, only there will be no xruns if I connect or
disconnect other clients, and depending on the graph I will be able to
use both processors in my old dual athlon mp machine :-)

I should still be able to stop jackdmp, start jackd again and have
everything still work. If I try to start jackd while jackdmp is running
(or viceversa) I get a nice error message:

   "Jackdmp is already running, quit it and its clients before
    starting jackd"

At this point I could decide that jackdmp is really cool and and I will
no longer need jack-audio-connection-kit. So I do:

  dumb remove jack-audio-connection-kit

and jackd is gone. Jackdmp still works and all apps are still happy. Or
I could get rid of jackdmp by doing:

  dumb remove jackdmp

and jackd and friends would still work[*].

All this in an ideal world....

Now, what is that this implies (of the underlying software) from the
packagers point of view:

"jack-audio-connection-kit" and "jackdmp" are independent packages. One
of them cannot trample on files that were installed by the other (AFAIK
in package managers I know of).

So, somehow jack-audio-connection-kit must have installed some other
unknown package (jack-audio-connection-switcher?) that provides the
basic functionality of deciding which server is running and routing
library calls to the appropriate library (what Stéphane was suggesting,
I think). Is this part of jack? Or is this part of jackdmp? (meaning
"how is that thing built and from what source code base?" - which is
sort of academic as long as it is there and works). Also, the process of
building jack/jackdmp clients themselves should just "require" the
presence of jack-audio-connection-kit-devel in the build environment as
before.

Everything transparent, all users very happy, nobody's confused.

As to anything like this being post 1.0....
Oh well. I disagree, the sooner the better.
Because, when is 1.0 going to happen?
[not complaining, just saying...]

-- Fernando

[*] or I could give up, decide that a flute is better, and run "dumb
remove all", he he he ;-p



-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Proposition for easier jackd / jackdmp management for packagers

John Rigg-3
In reply to this post by Stéphane Letz
On Fri, Jan 05, 2007 at 05:15:05PM +0100, Stéphane Letz wrote:

>
> Le 5 janv. 07 à 17:30, John Rigg a écrit :
> >Another reason is that jackdmp can't correctly recognize pcm_multi  
> >devices
> >defined in .asoundrc yet (unless that's been fixed since I last  
> >tried it).
> >That means it can't be used with multiple sound cards. On my SMP  
> >setup with
> >3 x Delta 1010 I have to use jackd.
> >
>
> The ALSA backend code has been synchronized with jack SVN version in  
> jackdmp 0.59 package. Maybe you should try again and report problems.

I just tried jackdmp 0.60 and the problem still exists.
It refuses to run at all in duplex mode with the virtual devices defined
in my .asoundrc ( http://www.sound-man.co.uk/linuxaudio/asoundrc24 )
This happens both with and without the pcm_multi patch (for alsa-lib > 1.0.8)
that is necessary to make jackd work in duplex mode with multiple cards
(for more info on that patch and my system config see:
http://www.sound-man.co.uk/linuxaudio/ice1712multi.html )

In playback-only mode it runs, but it uses 10 jack ports, not 24
as defined in my .asoundrc. In capture-only it runs with 12 jack
ports instead of 24. (The ice1712 chip has 12 input and 10 output
ports, so jackdmp is ignoring my .asoundrc definitions).

This is the same as last time I tried it (jackdmp 0.47).
Stéphane, I'll try to make time over the weekend to send you
jackdmp -v messages. The messages I've looked at so far look
very similar to the ones I sent you for 0.47 last January.

John

-------------------------------------------------------------------------
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
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
12