Re: [LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
Le 5 févr. 08 à 00:10, Krzysztof Foltman a écrit : > Paul Davis wrote: >> there are many parts of the JACK API that are not RT-bound. in fact, >> basically *all* of it except for a clients process() callback, >> which a >> client is not required to register. >> > I guess the "synchronous" response to port appearance/connection > events > (like application connecting ports before next event is generated by > JACK) pretty much requires RT in those applications. Is that right? > > Or are those callbacks called in non-audio thread context and don't > block audio? (I suppose they block audio, because I see several > watchdog > timeouts which seem to be related to patchbay applications doing > screen > updates etc.) > > Krzysztof > jackdmp used a 2 threads model on client side: one RT thread for audio (call the "process" callback) and one non RT thread for "notification" callback (like graph reorder, port register, connect/ disconnect...) Stéphane ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
Paul Davis wrote: > there are many parts of the JACK API that are not RT-bound. in fact, > basically *all* of it except for a clients process() callback, which a > client is not required to register. > I guess the "synchronous" response to port appearance/connection events (like application connecting ports before next event is generated by JACK) pretty much requires RT in those applications. Is that right? Or are those callbacks called in non-audio thread context and don't block audio? (I suppose they block audio, because I see several watchdog timeouts which seem to be related to patchbay applications doing screen updates etc.) Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
On Mon, 2008-02-04 at 22:23 +0200, Juuso Alasuutari wrote: > I'm assuming you meant to post this to the list, Paul. > > In reply to your comment: > > One of the motives behind jack-dbus is that a JACK control application > shouldn't have to be RT capable since it's not processing any > realtime-sensitive data anyway. From a technical perspective, could > libjack be extended with such a non realtime control API? there are many parts of the JACK API that are not RT-bound. in fact, basically *all* of it except for a clients process() callback, which a client is not required to register. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 3
On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote: > Fons Adriaensen wrote: > > I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP. > The core issue is abstracting the interfaces involved. As long as it > serves to free LASH from being a libjack client Why is freeing LASH from being a libjack client a goal? Bob -- Bob Ham <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] [Fwd: Re: Summercode 2008: LASH, pt. 3]
I'm assuming you meant to post this to the list, Paul. In reply to your comment: One of the motives behind jack-dbus is that a JACK control application shouldn't have to be RT capable since it's not processing any realtime-sensitive data anyway. From a technical perspective, could libjack be extended with such a non realtime control API? Original Message Subject: Re: [LAD] Summercode 2008: LASH, pt. 3 Date: Mon, 04 Feb 2008 11:33:44 -0500 From: Paul Davis <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: Linux Audio Systems To: Juuso Alasuutari <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote: > That being said, I still do favor D-Bus over OSC. The point is that they are both irrelevant in the context of JACK itself. First you need an API in JACK to control what you want to control. Then you need a JACK-aware application that speaks . When it gets it invokes the of the JACK API. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
Fons Adriaensen: > > On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote: > >> Where jack_autoconnect() would use environment variables, >> read .rc files, invoke the Buddha, or consult Paul Davis or >> the oracle of Delphi to find out which ports to use, but >> without requiring any special support from jackd itself. > > The code required is much shorter than the length of this > thread so far, so I take the liberty to post it. > Quickly but not fully tested. > > I would say that your function is a connect-many-ports-at-once function, not an autoconnect function. What I'm thinking is that the jackd program has an extra option called "--autoconnect-ports / -ap", which contains a comma-separated list of port names. If its not supplied, or "--no-autoconnect / -no" is not supplied either, jack_autoconnect(client,num_ports,port); will connect to the physical ports. This requires some modification to jack. But it shouln't be that much of a work. Besides, two other functions are needed as well: int jack_get_num_autoconnect_playback_ports(void); int jack_get_num_autoconnect_record_ports(void); ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, Feb 04, 2008 at 03:32:23PM +0100, Fons Adriaensen wrote:
> Where jack_autoconnect() would use environment variables,
> read .rc files, invoke the Buddha, or consult Paul Davis or
> the oracle of Delphi to find out which ports to use, but
> without requiring any special support from jackd itself.
The code required is much shorter than the length of this
thread so far, so I take the liberty to post it.
Quickly but not fully tested.
Enjoy.
(C) Fons Adriaensen, License: GPL
--- jack_autoconnect.h
#ifndef __JACK_AUTOCONNECT_H
#define __JACK_AUTOCONNECT_H
#ifdef __cplusplus
extern "C" {
#endif
#include
/*
Connect to JACK ports specified by an environment variable.
Args:
client: Pointer to jack client_t of your application.
nport: The number of ports to connect.
ports: An array of existing jack ports you want to connect.
envvar: The name of the environment variable containing a comma-separated
list of the full
names of the ports you want your ports connected to.
Returns:
-1 if 'envvar' does not exist, the number of connections made otherwise.
Ports can be input or output in any mix, but of course directions should match
those of the ports specified by 'envvar'.
The name 'envvar' can be application-specific, e.g.
MY_VERY_SPECIAL_PLAYER_PORTS, or
general, e.g. JACK_STEREO_PLAYBACK_PORTS, JACK_5DOT1_PLAYBACK_PORTS, etc.
*/
extern int jack_autoconnect (jack_client_t *client, int nport, jack_port_t
**ports, const char *envvar);
#ifdef __cplusplus
}
#endif
#endif
--- jack_autoconnect.c
#include
#include
#include
#define BUFFSIZE 4096
int jack_autoconnect (jack_client_t *client, int nport, jack_port_t **ports,
const char *envvar)
{
int n, r;
char*t;
const char *p, *q;
charbuff [BUFFSIZE];
p = getenv (envvar);
if (p == 0) return -1;
strncpy (buff, p, BUFFSIZE);
buff [BUFFSIZE - 1] = 0;
p = buff;
for (n = 0; n < nport; n++)
{
if ((p == 0) || (ports [n] == 0)) return n;
t = strchr (p, ',');
if (t) *t = 0;
q = jack_port_name (ports [n]);
if (jack_port_flags (ports [n]) & JackPortIsInput)
{
r = jack_connect (client, p, q);
}
else
{
r = jack_connect (client, q, p);
}
if (r) return n;
p = t ? (t + 1) : 0;
}
return n;
}
--- end of code
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 2008-02-04 at 16:56 +0100, Fons Adriaensen wrote: > On Mon, Feb 04, 2008 at 03:40:12PM +, Bob Ham wrote: > > On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen wrote: > > > > In other words, ** you could write this function today **. > > > The functionality you want does not require any changes > > > to jack. > > > > The problem is, you're still going to get client authors who say "Well, > > I have to implement insanely-annoying-automatic-port-connection because > > I have to cater for the people who don't use $your_system" By bringing > > autoconnection into JACK itself, there's a standardised, authorised, > > proven, approved method. > > It's none of those, and it's crippled. > > People who think that calling one (1, uno) function is a problem > should not be writing any form of applications Well, in fact there would be no need to call any function to implement generalised autoconnecting. All that is necessary is a daemon that pays attention to the creation of new ports and connects them to hardware ports. The problem is that, whatever system you use that isn't JACK, is another layer and some authors won't want to rely on it in order to provide autoconnection functionality. > I will respect the opinions, tastes, and personal preferences of anyone > who demonstrates a minimal amount of engagement, but _not_ of someone who > is so blatantly lazy as you suggest (I don't mean you, but the people you > refer to) Those authors that I'm referring to are the ones who would implement their own autoconnecting functionality rather than making one function call. Laziness is not the issue. The issue is the additional dependency needed to provide autoconnection functionality. Bob -- Bob Ham <[EMAIL PROTECTED]> ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection (fwd)
Jonatan Liljedahl: >> >> >> Thanks for clearing up. But I'm pretty sure your idea is too >> simple. We also need a way to create ports which are not >> autoconnected. >> >> The ideal way, if we follow this thread of thinking, would >> be to add another type of jack_port_register function, which >> does not autoconnect: >> >> jack_port_register_no_autoconnect(client,...); >> >> However, this new API will break a lot of current programs >> which are using the old jack_port_register function instead. >> Infact I don't think there is any (sane) way to make your >> proposal work without creating lots of mess with ports >> in old programs who are autoconnecting when it shouldn't. > > I think my proposal with a JackPortAutoConnect bit in JackPortFlags is > sane, it would not break old applications; they would continue to > function exactly as they are now. but updated code can get rid of their > own autoconnection and use this autoconnect bit in the flags to > jack_port_register() instead. > Yes, as long as JackPortAutoConnect is false by default, that's definietely a sane solution. Its basically the same kind of proposal I made, just using a flag to jack_port_register instead of a new function. But there is one problem with it: jack_client_t *client=... jack_port_t *out_port[0]=jack_port_register(client,...JackPortAutoConnect); jack_port_t *out_port[1]=jack_port_register(client,...JackPortAutoConnect); jack_port_t *new_out_port[0]=jack_port_register(client,...JackPortAutoConnect); jack_port_t *new_out_port[1]=jack_port_register(client,...JackPortAutoConnect); The problem is that new_out_port[0] and new_out_port[1] will connect to physical port number 2 and 3 instead of 0 and 1. How do you fix this problem without adding a new function to jacklib? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 4 Feb 2008, Bob Ham wrote: > On Mon, 2008-02-04 at 16:25 +0100, Kjetil S. Matheussen wrote: >> On Mon, 4 Feb 2008, Bob Ham wrote: >>> On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote: On Mon, 4 Feb 2008, Bob Ham wrote: > >>> What I am suggesting is not to toggle autoconnecting for individual >>> clients, but to toggle autoconnecting for *all* clients, globally. > >> Thanks for clearing up. But I'm pretty sure your idea is too >> simple. We also need a way to create ports which are not >> autoconnected. > > As Jonatan Liljedahl noted, a new bit in JackPortFlags would suffice. > No, as I wrote later, (I have problems with my smtp-server), it won't. (fons' jack_autoconnect function would though, I think thats a good one) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 2008-02-04 at 16:25 +0100, Kjetil S. Matheussen wrote: > On Mon, 4 Feb 2008, Bob Ham wrote: > > On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote: > >> On Mon, 4 Feb 2008, Bob Ham wrote: > > What I am suggesting is not to toggle autoconnecting for individual > > clients, but to toggle autoconnecting for *all* clients, globally. > Thanks for clearing up. But I'm pretty sure your idea is too > simple. We also need a way to create ports which are not > autoconnected. As Jonatan Liljedahl noted, a new bit in JackPortFlags would suffice. > Infact I don't think there is any (sane) way to make your > proposal work without creating lots of mess with ports > in old programs who are autoconnecting when it shouldn't. Backward compatibility (*mumble*) would be maintained by making ports' default autoconnect bit negative; ie, having to set JackPortAutoconnect to enable autoconnecting rather than set JackPortNoAutoconnect to disable. Alas, this means the client author once again has to do something. Bob -- Bob Ham <[EMAIL PROTECTED]> ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 3
Fons Adriaensen wrote: > On Sat, Feb 02, 2008 at 08:22:20PM +0200, Juuso Alasuutari wrote: > >> 1) Switch to using the JACK D-Bus interface for lashd<->jackd communication. > > Paul D. has already replied to this... > >> 2) Add a D-Bus control interface to LASH, which is supposed to >> eventually replace the current liblash server interface API. > >> 3) Change the liblash client interface's internals to use D-Bus for >> communication with lashd. > > I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP. > Last time I looked at the lash sources, the protocol was really > just one small step away from OSC - it would have taken an hour > or two to do the conversion. The core issue is abstracting the interfaces involved. As long as it serves to free LASH from being a libjack client, and the LASH control apps from being liblash clients, I'm OK with whatever acronym finally slips in. That being said, I still do favor D-Bus over OSC. IMHO it's the best suited candidate for these kind of desktop purposes (autolaunching being a definite plus as Nedko pointed out). A D-Bus interface would guarantee less painful integration with all sorts of frontends and wizards. (Surely you'd like to manage your sessions through a KDE4 plasmoid using neat composite effects? :)) Adding an internal, generic generic control interface to LASH would probably be a good idea anyway. Nedko is already working on an internal interface for JACK which allows different external control interface implementations to co-exist. This kind of solution would effectively keep LASH from being hijacked by any particular protocol implementation. > Other consideration: any form of session management for the > systems I'm using would have to be at least a two-layer affair. > > There is a first layer of 'system' apss talking to jack and > creating a working environment - this is all monitoring and > rendering stuff. > > The second level is user sessions, also consisting of several > apps talking to jack. They *use* this existing environment but > should not be allowed to modify it. > > For anything like lash to be useful here it would need to support > this layering. Can you give specific examples of what you mean by this layering concept? Juuso ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, Feb 04, 2008 at 03:40:12PM +, Bob Ham wrote: > On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen wrote: > > In other words, ** you could write this function today **. > > The functionality you want does not require any changes > > to jack. > > The problem is, you're still going to get client authors who say "Well, > I have to implement insanely-annoying-automatic-port-connection because > I have to cater for the people who don't use $your_system" By bringing > autoconnection into JACK itself, there's a standardised, authorised, > proven, approved method. It's none of those, and it's crippled. People who think that calling one (1, uno) function is a problem should not be writing any form of applications, because they won't get very far. Typically you need tens, hundreds, thousands. Raising sheep may be a better occupation for them. I will respect the opinions, tastes, and personal preferences of anyone who demonstrates a minimal amount of engagement, but _not_ of someone who is so blatantly lazy as you suggest (I don't mean you, but the people you refer to), and stupid enough to admit it. Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 2008-02-04 at 15:32 +0100, Fons Adriaensen wrote: > Or this one: > > jack_client_t *client=... > jack_port_t *out_port[0]=jack_port_register(client,...); > jack_port_t *out_port[1]=jack_port_register(client,...); > connected = jack_autoconnect (2, out_port); > In other words, ** you could write this function today **. > The functionality you want does not require any changes > to jack. The problem is, you're still going to get client authors who say "Well, I have to implement insanely-annoying-automatic-port-connection because I have to cater for the people who don't use $your_system" By bringing autoconnection into JACK itself, there's a standardised, authorised, proven, approved method. Bob -- Bob Ham <[EMAIL PROTECTED]> ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 4 Feb 2008, Bob Ham wrote: > On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote: >> On Mon, 4 Feb 2008, Bob Ham wrote: > >>> Even less hassle is for clients to do nothing at all and leave the whole >>> business entirely for jackd. I suggest the following function instead: >>> >>> int jack_set_autoconnect(jack_client_t *, int autoconnect); >>> >>> This enables a control interface that can present the user with a simple >>> system-wide toggle switch that would dictate whether or not ports are >>> automatically connected. >>> >> >> I'm not sure what you mean by the last sentence. >> Is the "autoconnect" variable either 0 or 1? > > Yes, sorry. The "int autoconnect" parameter would be a boolean > indicator; 1 to enable autoconnecting, 0 to disable it. It would > probably be sensible to have a complementary jack_get_autoconnect() > function to return the value as well. > >> But how do libjack know the order of ports? By just >> using creation order? Well, I guess that will work. > > Indeed. This is how most client-side autoconnecting seems to work at > the moment. Clients simply get "a list" of hardware ports from the > server and connect them in sequence against the client's own ports. > >> How about this interface then? >> >> void jack_enable_autoconnect(jack_client_t *); >> void jack_disable_autoconnect(jack_client_t *); >> >> And then a typical playback client would work like this: >> >> jack_client_t *client=... >> jack_enable_autoconnect(client); >> jack_port_t *out_port[0]=jack_port_register(client,...); >> jack_port_t *out_port[1]=jack_port_register(client,...); >> jack_disable_autoconnect(client); > > Sorry; I obviously wasn't specific enough about the semantics of the > toggle function. > > What I am suggesting is not to toggle autoconnecting for individual > clients, but to toggle autoconnecting for *all* clients, globally. The > flag that gets toggled would be a property of the engine, not the > client. > > In terms of autoconnecting, clients would do quite literally nothing at > all. The above code would be rewritten as follows: > > jack_client_t *client=... > jack_port_t *out_port[0]=jack_port_register(client,...); > jack_port_t *out_port[1]=jack_port_register(client,...); > > Clients would never call the new function unless they were control > interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some > gnome-jack-autoconnect-switch applet. > > This removes from client authors the burden of implementing > autoconnection, and enables a convenient interface for controlling > autoconnect behaviour. > Thanks for clearing up. But I'm pretty sure your idea is too simple. We also need a way to create ports which are not autoconnected. The ideal way, if we follow this thread of thinking, would be to add another type of jack_port_register function, which does not autoconnect: jack_port_register_no_autoconnect(client,...); However, this new API will break a lot of current programs which are using the old jack_port_register function instead. Infact I don't think there is any (sane) way to make your proposal work without creating lots of mess with ports in old programs who are autoconnecting when it shouldn't. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 3
Fons Adriaensen <[EMAIL PROTECTED]> writes: > I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP. > Last time I looked at the lash sources, the protocol was really > just one small step away from OSC - it would have taken an hour > or two to do the conversion. The advantage is D-Bus autolaunching of the "server" and better integration with "desktop". > Other consideration: any form of session management for the > systems I'm using would have to be at least a two-layer affair. > > There is a first layer of 'system' apss talking to jack and > creating a working environment - this is all monitoring and > rendering stuff. > > The second level is user sessions, also consisting of several > apps talking to jack. They *use* this existing environment but > should not be allowed to modify it. > > For anything like lash to be useful here it would need to support > this layering. This will be hard without proper integration with a desktop (window manager) session handler. Something very similar can be achieved using the "import subsessions" feature that I proposed earlier. I.e. have system session [auto]loaded and then import (without replace) of user session[s]. -- Nedko Arnaudov pgpFiehZ0f5ZI.pgp Description: PGP signature ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 2008-02-04 at 15:14 +0100, Kjetil S. Matheussen wrote: > On Mon, 4 Feb 2008, Bob Ham wrote: > > Even less hassle is for clients to do nothing at all and leave the whole > > business entirely for jackd. I suggest the following function instead: > > > > int jack_set_autoconnect(jack_client_t *, int autoconnect); > > > > This enables a control interface that can present the user with a simple > > system-wide toggle switch that would dictate whether or not ports are > > automatically connected. > > > > I'm not sure what you mean by the last sentence. > Is the "autoconnect" variable either 0 or 1? Yes, sorry. The "int autoconnect" parameter would be a boolean indicator; 1 to enable autoconnecting, 0 to disable it. It would probably be sensible to have a complementary jack_get_autoconnect() function to return the value as well. > But how do libjack know the order of ports? By just > using creation order? Well, I guess that will work. Indeed. This is how most client-side autoconnecting seems to work at the moment. Clients simply get "a list" of hardware ports from the server and connect them in sequence against the client's own ports. > How about this interface then? > > void jack_enable_autoconnect(jack_client_t *); > void jack_disable_autoconnect(jack_client_t *); > > And then a typical playback client would work like this: > > jack_client_t *client=... > jack_enable_autoconnect(client); > jack_port_t *out_port[0]=jack_port_register(client,...); > jack_port_t *out_port[1]=jack_port_register(client,...); > jack_disable_autoconnect(client); Sorry; I obviously wasn't specific enough about the semantics of the toggle function. What I am suggesting is not to toggle autoconnecting for individual clients, but to toggle autoconnecting for *all* clients, globally. The flag that gets toggled would be a property of the engine, not the client. In terms of autoconnecting, clients would do quite literally nothing at all. The above code would be rewritten as follows: jack_client_t *client=... jack_port_t *out_port[0]=jack_port_register(client,...); jack_port_t *out_port[1]=jack_port_register(client,...); Clients would never call the new function unless they were control interfaces, eg. QJackCtl, a jack_autoconnect CLI program, or some gnome-jack-autoconnect-switch applet. This removes from client authors the burden of implementing autoconnection, and enables a convenient interface for controlling autoconnect behaviour. Bob -- Bob Ham <[EMAIL PROTECTED]> ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
Bob Ham wrote: > Even less hassle is for clients to do nothing at all and leave the whole > business entirely for jackd. I suggest the following function instead: > int jack_set_autoconnect(jack_client_t *, int autoconnect); This is fine for simple clients that have two outputs that are always connected to default playback ports, and two inputs that are always connected to default capture ports. However, it is of little use in the more complex cases, where ports come and go, some ports may be mono, there may be 8 synth output ports and 8 soundcard playback ports. What I could propose is API like this: int jack_port_add_tag(jack_port_t *, const char *tag, int priority); void jack_port_remove_tag(jack_port_t *, const char *tag); const char **jack_port_get_tags((jack_port_t *); jack_port_t **jack_get_ports_by_tag(jack_client_t *, const char *tag); void jack_port_tags_free(const char **); void jack_port_list_free(jack_port_t **); and perhaps: typedef void (*PortTagListUpdateCallback)(jack_port_t *t, void *data, const char *tag, int was_added); void jack_set_tag_callback(PortTagListUpdateCallback, void *data); Example tags (some are for physical ports, some are for application ports): - related to channels: mono, stereo, stereo-left, stereo-right, 5.1, 5.1-left-front, 5.1-right-front, 5.1-left-rear, 5.1-right-rear, 5.1-center-front, 5.1-surround (so a left stereo channel would have "stereo" and "stereo-left") - related to purpose: default-out (system:playback_1/2 or first unconnected mixer input, a mixer will specify the higher priority), physical-out (physical soundcard), physical-out-2, physical-out-3, reverb (inputs and outputs of reverb effect), chorus, fx-1, fx-2 (for global fx) - related to port purpose: midi-in, kbd (and kbd-2 etc.), drums, ctlsurface, guitar (for audio capture for guitar), mic (audio capture for mic), synth (for synth application's midi port AND audio output), drummachine (for drum machine's midi port and audio output) - related to relationship to other ports - audio-output-for:system:midi_capture_1 etc. - related to application name (name:hydrogen) Then a definable, prioritized set of JACK-wide rules (provided by default, but configurable via some sort of GUI) could make reasonable autoconnection possible. I guess the autoconnection mechanism could be separate from JACK itself, as there may be some uses for both simple autoconnection mechanisms (which only deal with things like connecting instrument outputs to audio out, and instrument inputs to one predefined MIDI port) as complex auto-patchbay systems (where you could juggle between 4 different drum machines, 3 synths and 5 main mixers and have everything working :) ). And the complex systems might be written at some time in the future or not at all. The patchbay system (with automatic connection based on tags) might be a part of session handling as well. Okay, the system looks very complex so perhaps it is a bit scary. Still, it's just 6-7 functions in the API, and the only one to be used by most non-patchbay clients is jack_port_add_tag. Not THAT scary. On the other hand, perhaps 99.9% of audio application users have at most 2 inputs, 2 outputs and 1 MIDI, and building a complex tagging system for 2 people total is pointless. Krzysztof ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, Feb 04, 2008 at 03:14:54PM +0100, Kjetil S. Matheussen wrote: > How about this interface then? > > void jack_enable_autoconnect(jack_client_t *); > void jack_disable_autoconnect(jack_client_t *); > > And then a typical playback client would work like this: > > jack_client_t *client=... > jack_enable_autoconnect(client); > jack_port_t *out_port[0]=jack_port_register(client,...); > jack_port_t *out_port[1]=jack_port_register(client,...); > jack_disable_autoconnect(client); Or this one: jack_client_t *client=... jack_port_t *out_port[0]=jack_port_register(client,...); jack_port_t *out_port[1]=jack_port_register(client,...); connected = jack_autoconnect (2, out_port); (one less call !!!) Where jack_autoconnect() would use environment variables, read .rc files, invoke the Buddha, or consult Paul Davis or the oracle of Delphi to find out which ports to use, but without requiring any special support from jackd itself. In other words, ** you could write this function today **. The functionality you want does not require any changes to jack. It may end up one day in libjack or in some other place from where it can be reused. -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Mon, 4 Feb 2008, Bob Ham wrote: > On Fri, 2008-02-01 at 19:34 +0100, Kjetil S. Matheussen wrote: > >> int jack_autoconnect_playback (jack_client_t *, >> int portnum, >> const char *source_port); >> int jack_autoconnect_record (jack_client_t *, >>int portnum, >>const char *destination_port); >> >> The reason is that this API will make it easier >> for programs to make autoconnection configurabe. >> Autoconnecting the old way (which includes finding >> the physical ports and/or checking environment variables >> for ports to connect to, etc.) is a lot more >> hassle than just calling the functions above. > > Even less hassle is for clients to do nothing at all and leave the whole > business entirely for jackd. I suggest the following function instead: > > int jack_set_autoconnect(jack_client_t *, int autoconnect); > > This enables a control interface that can present the user with a simple > system-wide toggle switch that would dictate whether or not ports are > automatically connected. > I'm not sure what you mean by the last sentence. Is the "autoconnect" variable either 0 or 1? But how do libjack know the order of ports? By just using creation order? Well, I guess that will work. How about this interface then? void jack_enable_autoconnect(jack_client_t *); void jack_disable_autoconnect(jack_client_t *); And then a typical playback client would work like this: jack_client_t *client=... jack_enable_autoconnect(client); jack_port_t *out_port[0]=jack_port_register(client,...); jack_port_t *out_port[1]=jack_port_register(client,...); jack_disable_autoconnect(client); ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Fri, 2008-02-01 at 19:34 +0100, Kjetil S. Matheussen wrote: > int jack_autoconnect_playback (jack_client_t *, > int portnum, > const char *source_port); > int jack_autoconnect_record (jack_client_t *, >int portnum, >const char *destination_port); > > The reason is that this API will make it easier > for programs to make autoconnection configurabe. > Autoconnecting the old way (which includes finding > the physical ports and/or checking environment variables > for ports to connect to, etc.) is a lot more > hassle than just calling the functions above. Even less hassle is for clients to do nothing at all and leave the whole business entirely for jackd. I suggest the following function instead: int jack_set_autoconnect(jack_client_t *, int autoconnect); This enables a control interface that can present the user with a simple system-wide toggle switch that would dictate whether or not ports are automatically connected. Bob -- Bob Ham <[EMAIL PROTECTED]> ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Summercode 2008: LASH, pt. 3
On Sat, Feb 02, 2008 at 08:22:20PM +0200, Juuso Alasuutari wrote: > 1) Switch to using the JACK D-Bus interface for lashd<->jackd communication. Paul D. has already replied to this... > 2) Add a D-Bus control interface to LASH, which is supposed to > eventually replace the current liblash server interface API. > 3) Change the liblash client interface's internals to use D-Bus for > communication with lashd. I fail the see the advantage of D-Bus over e.g. OSC via UDP or TCP. Last time I looked at the lash sources, the protocol was really just one small step away from OSC - it would have taken an hour or two to do the conversion. Other consideration: any form of session management for the systems I'm using would have to be at least a two-layer affair. There is a first layer of 'system' apss talking to jack and creating a working environment - this is all monitoring and rendering stuff. The second level is user sessions, also consisting of several apps talking to jack. They *use* this existing environment but should not be allowed to modify it. For anything like lash to be useful here it would need to support this layering. -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
[LAD] ALSA & daemon
Is there any reason why raw ALSA MIDI streams would stop working if the process that opened them switches to daemon mode ? (see mand daemon(3)) Ciao, -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [OT] an ogg vorbis player for Java ME mobile phones?
On Feb 3, 2008 4:24 PM, Guillaume Pellerin <[EMAIL PROTECTED]> wrote: > I agree ! It is time now to have some OGG players inside our phones ! I would be interested in hearing why having a OGG player (or anything else) on a phone would need java. Most linux (non-java) applications run out of the box on a GTA01 for instance. Gui might need a bit of work/resizing, but that's about all. There's an on going discussion on the Openmoko lists about adding java/mono to the platform. Another ongoing thread is about the severe limitation of the GTA01 concerning power management. Sounds a lot like a paradox to me. If the choice of java is motivated only by programming comfort, one should probably do that on a device that has a power cord. __ Marc-Olivier Barre, MarcO'Chapeau. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] jack client autoconnection
On Fri, Feb 01, 2008 at 04:08:32PM -0500, Paul Davis wrote: > Please STOP all this discussion of coupling DBUS to JACK. JACK is a > cross-platform tool. It is currently dependent on nothing but ANSI C and > POSIX, though on OS X and Windows it does have to work aroudn the fact > that those platforms' POSIX support isn't 100% usable for the same > purposes as on Linux. That isn't go to change. I agree. If and when jack gets a 'remote control' interface I very much hope it will be OSC over UDP and/or TCP. It's an audio tool after all. -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
