headers
Paul Davis | 1 Dec 2002 04:24

Re: pause for thought

>Thanks for sharing this with the list.  My initial comment was short and
>vague because I didn't know if there was any interest in this.  There
>seems to be enough interest for deeper discussion.  If you choose to
>share this with jackit-devel, please include the entire message, since
>parts of it that may not be relevant to you might be relevant to
>others.  Here I go.
>
>The bus concept is more about acknowledging what jack already is than
>about changing jack.  In fact my idea introduces no changes to clients,
>and adds one change to the server.  It also fits in with the current
>connection and session work being done.
>
>The basic idea is bus vs. patchbay, not bus vs. ports.  Clients still
>have input and output ports.  My observation is that the general
>jackit-devel mentality is patchbay centric, but jack's current
>connection method is much more bus-like than patchbay-like, and one
>small change would give jack full bus power.  Also, in the pro audio
>world, the word "patchbay" has a specific meaning that is quite
>different from the way jack connects clients, and I would like to avoid
>confusion that could hinder jack's adoption in this field.
>
>Patchbays are used when the routing requirements of a studio are greater
>than the mixer's bus architecture can provide, and I will show that it
>is impossible to exceed the bus capabilities of a jack system, making
>patchbays unnecessary.  Patchbays primarily provide one-to-one
>connections, though in a half-normaled configuration they function as a
>"Y" chord and allow for one-to-two connections (but not two-to-one). 
>They *never* allow many-to-one connections.  The only devices in the
>entire audio world that support many-to-one connections, otherwise known
>as mixing, are the busses found inside mixers.  Audio busses are much
(Continue reading)

Permalink | Reply | 2 comments |
headers
Melanie | 1 Dec 2002 22:42
Gravatar

Server closed socket?

Hello,
  I am experiencing some strange problem with jack from current CVS.

My application prints "engine has shut down socket; thread exiting" and 
jackd displays
"**** alsa_pcm: xrun of at least 4.059 msecs subgraph starting at 
djplay_8235_1 timed out (subgraph_wait_fd=16, status = 1024, state = 
Running)"

System load is about 30-40%. It works well for a few minutes, then it does 
this. Restarting the application makes it work again, but sooner or later 
it happens again.

The application is 2 jack clients in one, each publishing 2 ports. They are 
connected to the 2 output ports on the sound card, so on-the-fly mixing 
does take place.

Where could the problem be?

Regards,

Melanie

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 9 comments |
headers
Paul Davis | 2 Dec 2002 04:33

Re: Server closed socket?

>Hello,
>  I am experiencing some strange problem with jack from current CVS.
>
>My application prints "engine has shut down socket; thread exiting" and 
>jackd displays
>"**** alsa_pcm: xrun of at least 4.059 msecs subgraph starting at 
>djplay_8235_1 timed out (subgraph_wait_fd=16, status = 1024, state = 
>Running)"
>
>System load is about 30-40%. It works well for a few minutes, then it does 
>this. Restarting the application makes it work again, but sooner or later 
>it happens again.
>
>The application is 2 jack clients in one, each publishing 2 ports. They are 
>connected to the 2 output ports on the sound card, so on-the-fly mixing 
>does take place.
>
>Where could the problem be?

your application isn't meeting JACK's scheduling requirements. my
guess would be that you are running jack with the -R flag. under such
conditions, the code in your process() callback needs to be pretty
much deterministically real-time. that means:

     a) no malloc activity, no blocking system calls
     b) cycles_to_execute = (A * nframes) + B
         where A and B are constants.

btw, this "2 jack clients in one" is a silly design, i think. we
discussed this in another context a few months ago, and its hard for
(Continue reading)

Permalink | Reply | 8 comments |
headers
Steve Harris | 1 Dec 2002 12:34
Picon
Favicon

Re: Re: pause for thought

On Sat, Nov 30, 2002 at 10:24:59 -0500, Paul Davis wrote:
> Tom ? wrote:
> >The basic idea is bus vs. patchbay, not bus vs. ports.  Clients still
> >have input and output ports.  My observation is that the general
> >jackit-devel mentality is patchbay centric, but jack's current
> >connection method is much more bus-like than patchbay-like, and one
> >small change would give jack full bus power.  Also, in the pro audio
> >world, the word "patchbay" has a specific meaning that is quite
> >different from the way jack connects clients, and I would like to avoid
> >confusion that could hinder jack's adoption in this field.

This is not that straigtforward, its down to the argument between new
concept => new word and metphors. In this case I think the metphor is
slightly better:

Joe Sixpack runs jack, he runs a few apps and the're not talking to each
other in the way he wants, so he looks down the list of jack applications
and sees "foo patchbay", launches it and hey presto it does what he wants
(and some other things).

Also, "jack patchbay" is a term used by developers, and we all know the
distinction between a hardware patchbay and a jack one.

NB the most popular "patchbay" is actually called qjackconnect, which
   doesn't have patchbay in the title anyway. ;)

> The problem with using JACK in combination with a bus model is
> actually very simply solved, and Steve has already pointed out the
> solution: allow input<->input connections to be made. As far as i can
> tell, it makes no difference to the graph sorting algorithm or
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Vehmanen | 1 Dec 2002 21:39

Re: [ecasound] unknown source port in attempted connection []

On Sun, 1 Dec 2002, Oliver Thuns wrote:

> I updated jack 0.38 (debian package) to jack 0.40.1 (cvs), because the 
> latest ecasound uses alsa_pcm:playback_ and jack 0.38 does not. Now I 
> get an error, when I use jack output from ecasound. Do you have any idea 
> what's wrong with my setup?
[...]
> I recompiled ecasound after I installed jack 0.40.1

This seems like the recompilation failed for some reason (not all parts
of ecasound were recompiled, or old JACK libs/headers were 
used in recompilation). Try compiling ecasound from scratch (make clean ; 
make ...) and see if the problems persists.

You could also try the following:

ecasound -f:16,2,48000 -i foo.org -o jack
jack_connect ecasound:out_1 alsa_pcm:playback_1
jack_connect ecasound:out_2 alsa_pcm:playback_2

This works even with older jackd-versions if you replace
'playback' with 'out'.

--

-- 
 http://www.eca.cx
 Audio software for Linux!

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
(Continue reading)

Permalink | Reply | 0 comments |
headers
smoerk | 1 Dec 2002 13:09
Picon
Picon

alsa_pcm:playback/capture

Hi,

I don't understand why the plugs to the soundcard are named

alsa_pcm:playback_*
alsa_pcm:capture_*

when jackd has a -d parameter for the driver, which could be another 
device than alsa in the future. couldn't you name it in a more general 
way, like

playback:in_*
capture:out_*

play:in_*
record:out_*
(which I prefer, this is normaly used on amplifiers)

soundcard:in_*
soundcard:out_*
(which could be confusing)

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 4 comments |
headers
Paul Davis | 1 Dec 2002 17:58

Re: alsa_pcm:playback/capture

>this sounds good. :-) I have now alsaplayer from debian and jackd 0.40.1 
>from cvs, which don't play together anymore. what are physical ports? 
>all ports which are named playback and capture?

ports that have the JackPortIsPhysical flag set. they are expected to
correspond to things like i/o connectors on an audio interface.

--p

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Andy Lo-A-Foe | 1 Dec 2002 17:47

Re: alsa_pcm:playback/capture

On Sun, Dec 01, 2002 at 06:03:14PM +0200, smoerk wrote:

> this sounds good. :-) I have now alsaplayer from debian and jackd 0.40.1 
> from cvs, which don't play together anymore. what are physical ports? 
> all ports which are named playback and capture?

I just release alsaplayer 0.99.73, which should use the new jack naming
scheme. 

Andy

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Paul Davis | 2 Dec 2002 21:22

Re: Launch meterbridge from qjackconnect

>The problem seems to be that there are three qjackconnect threads running,
>where jackd seems to open to of them. And it looks like

1 of them is the original thread that the program started with.
1 of them is the pthread_manager, present in all apps that use LinuxThreads
1 of them is the JACK thread.

>  jack_deactivate(jack_handle);
>  jack_client_close(jack_handle);
>
>does not close the threads.

this is a bug. i can fix that. but i don't think its central to your
problem. however, i need to think more about it. 

--p

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 0 comments |
headers
chrismorgan | 2 Dec 2002 21:46
Favicon

Re: Re: Launch meterbridge from qjackconnect

> 
> >The problem seems to be that there are three qjackconnect threads running,
> >where jackd seems to open to of them. And it looks like
> 
> 1 of them is the original thread that the program started with.
> 1 of them is the pthread_manager, present in all apps that use LinuxThreads
> 1 of them is the JACK thread.
> 
> >  jack_deactivate(jack_handle);
> >  jack_client_close(jack_handle);
> >
> >does not close the threads.
> 
I've seen the same problem with the jack driver I wrote for wine where the client should have closed but
stayed around for quite some time, >500ms.  My workaround was to only close the jack clients on exit and
simply mark them as inuse or not-inuse once they were opened but it would be nice to not need to do that ;-)  

> this is a bug. i can fix that. but i don't think its central to your
> problem. however, i need to think more about it. 
> 
> --p

-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
Permalink | Reply | 2 comments |

Gmane