19 Oct
2010
19 Oct
'10
11:25 a.m.
Hello everyone!
I was wondering about this. In Nama it is allowed to connect multiple
jack_ports to one ecasound port. So I can connect a pack of hydrogen ports to
one ecasound port. So I don't have to record 30-odd tracks for one drumkit.
But the connection takes very long. Would it be possible to move all the
connects in the background and let them finish their jobs there.
The number of ports I'm connecting is around 60-66, so 30-33 pairs. Or is
there another way (with external utilities or a Perl module, to accelerate
this process?
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net
the Linux TextBased Studio guide
======= AND MY PERSONAL PAGES AT: =======
http://www.juliencoder.de
20 Oct
20 Oct
5:37 a.m.
On Tue, Oct 19, 2010 at 01:25:23PM +0200, Julien Claassen wrote:
Hello everyone!
I was wondering about this. In Nama it is allowed to connect
multiple jack_ports to one ecasound port. So I can connect a pack of
hydrogen ports to one ecasound port. So I don't have to record
30-odd tracks for one drumkit. But the connection takes very long.
Would it be possible to move all the connects in the background and
let them finish their jobs there.
The number of ports I'm connecting is around 60-66, so 30-33
pairs. Or is there another way (with external utilities or a Perl
module, to accelerate this process?
Nama could easily be modified to start 60-or-so parallel
jack_connect processes in the background, however I'm
curious: is there any special reason why jack_connect should
take a long time to return?
Would parallel jack_connect processes be competing for resources
in some way?
It might be informative to start Ecasound in the --server
mode with the -ddd (debugging) flag, and look for any
signs of bottleneck on that end.
Since JACK has an "industrial strength" design, I would
be surprised if the JACK server's implementation turned out
to be a limiting factor.
jack_connect, on the other hand, might suffer from some
sub-optimal behavior.
It would be great if we could track down the reason for
this slow response connecting Ecasound ports to Hydrogen.
Joel
Kindest regards
Julien
--
Joel Roth
12:49 p.m.
On Wed, Oct 20, 2010 at 1:37 AM, Joel Roth <joelz(a)pobox.com> wrote:
Nama could easily be modified to start 60-or-so
parallel
jack_connect processes in the background, however I'm
curious: is there any special reason why jack_connect should
take a long time to return?
it creates and destroys a client per transaction. depending on server
settings, this could slow things down quite a lot.
jack.plumbing is a better idea, since AFAIK it reads a config file and
does all the required connections from within a single client.
5160
days inactive
5161
days old
linux-audio-user@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Joel Roth -
Julien Claassen -
Paul Davis