Jack and jackdmp

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

Jack and jackdmp

juuso.alasuutari (Bugzilla)
I'm sure this is one of those questions that gets asked every second month...
But I'll ask it anyway.

What's the current relationship between the jack and jackdmp projects? From a
user/programmer perspective it seems unfortunate that the developer resources
are divided like this. I do understand that one is C and the other is C++,
which can make collaboration somewhat difficult, but I still get the feeling
that a considerable amount of work is being duplicated.

I would love to run a jackd that makes better use of multiple cores (if it
indeed is possible), and that's why jackdmp with its in-development
pipelining stuff looks attractive. But alas, jackdmp doesn't do MIDI yet. And
to be honest, if it _did_ do MIDI, I'd feel even worse having to choose
between two great projects which, in an ideal world, could join forces.

And how much less efficient is jackd in utilizing several cores, then? I
realize that that may sound rude, but my intention is not to insult anyone.
It's simply a thought that easily springs to mind when one sees a project
like jackdmp evolve parallel to jack. If jackdmp is better with multiple
cores, and doesn't suck with single-processor machines either, then will this
technical knowledge find its way to the jack project also?

Thanks,
Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack and jackdmp

Stéphane Letz

Le 13 sept. 07 à 22:45, Juuso Alasuutari a écrit :

> I'm sure this is one of those questions that gets asked every  
> second month...
> But I'll ask it anyway.
>
> What's the current relationship between the jack and jackdmp projects?

They both exists ... ((-:

> From a
> user/programmer perspective it seems unfortunate that the developer  
> resources
> are divided like this. I do understand that one is C and the other  
> is C++,
> which can make collaboration somewhat difficult, but I still get  
> the feeling
> that a considerable amount of work is being duplicated.
>
> I would love to run a jackd that makes better use of multiple cores  
> (if it
> indeed is possible), and that's why jackdmp with its in-development
> pipelining stuff looks attractive.

They are 2 answers here:

1) jackdmp "standard" implementation (SVN trunk  distributed in a  
package) allows better use of multi-cores machines in some specific  
graph topologies, that is when *explicit* parallel clients are in the  
graph (clients with the same inputs dependencies). It does that using  
kind of "data-flow" approach. An example:  IN ==> A ==> C and IN ==>  
B ==> C, A and B can be run in parallel on 2 cores as soon as he "IN"  
delivers its output, and C will be run when A *and* B have produced  
their output.

2) SVN trunk jackdmp cannot help in pure sequential cases (like IN  
==> A ==> B ==> C),  that is jackdmp and jackd are strictly  
equivalent in this area. The "pipelilning" experimental version (in  
SVN exp branch) improves the situation in sequential cases also, by  
dividing the global buffer in smaller slices, thus allowing the next  
client in the chain to start processing a part of the buffer on a new  
core while the previous client still process another slice of the  
global buffer, and so on.


> But alas, jackdmp doesn't do MIDI yet.

There is a "not complete" midi branch, but yes it is not in the trunk  
yet.

> And
> to be honest, if it _did_ do MIDI, I'd feel even worse having to  
> choose
> between two great projects which, in an ideal world, could join  
> forces.

Paul can answer better than me here.

>
> And how much less efficient is jackd in utilizing several cores, then?

jackd precompule the chain of client scheduling as a sequence of  
activation : in the previous 1) example, it would sort the client  
list as:  IN , A , B, C (or the equivalent IN, B, A, C) . Then A , B,  
C are activated in order. The server does not "see" that A and B  
could be run at the same time on 2 cores.

> I
> realize that that may sound rude, but my intention is not to insult  
> anyone.
> It's simply a thought that easily springs to mind when one sees a  
> project
> like jackdmp evolve parallel to jack. If jackdmp is better with  
> multiple
> cores, and doesn't suck with single-processor machines either, then  
> will this
> technical knowledge find its way to the jack project also?
>
>
I guess the logical next step would be to have jackdmp become the  
reference implementation at some point. But here again, Paul can  
answer better.

Stephane


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Jack and jackdmp

Dmitry Baikov
On 9/14/07, Stéphane Letz <[hidden email]> wrote:
> > But alas, jackdmp doesn't do MIDI yet.
>
> There is a "not complete" midi branch, but yes it is not in the trunk
> yet.

It only lacks alsa-midi driver. The MIDI itself works as it should.
Yes, yes, Stéphane, I promised to finish the work on alsa-midi driver :)
I will, Real Soon(tm) :)


Dmitry.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel