On Tuesday 19 May 2009 15:39:12 Fons Adriaensen wrote:
> It's also just bad design, comparable to using a $3000
> precision programmable voltage source in a circuit where
> a 10 cent zener diode would do. Or replacing a fixed
> cable by a switch matrix. Or talking to your wife via
> a lawyer.
thou
On Wed, May 20, 2009 at 04:43:33PM -0500, Jack O'Quin wrote:
> Don't forget a timeout in case the fork/exec fails and there is no message.
>> On Wed, May 20, 2009 at 2:38 PM, Fons Adriaensen
>> wrote:
>
> The fork/exec is done by jackcontrol, if it fails then
> jackcontrol reports this and the e
On Wed, May 20, 2009 at 04:43:33PM -0500, Jack O'Quin wrote:
> On Wed, May 20, 2009 at 2:38 PM, Fons Adriaensen wrote:
>
> > You don't need this jackd. If all the IPC is in libjack, an
> > autostart request can be passed directly to jackcontrol without
> > creating a transient process.
> >
> > 1.
On Wed, May 20, 2009 at 2:38 PM, Fons Adriaensen wrote:
> On Tue, May 19, 2009 at 04:23:30PM +0200, Stéphane Letz wrote:
>> A picture to try summary what I understand about we would like :
>>
>
>> - "jackcontrol" is an *always" running deamon that defined an entry IPC
>> point. jackcontrol get
On Tue, May 19, 2009 at 04:23:30PM +0200, Stéphane Letz wrote:
> A picture to try summary what I understand about we would like :
>
> - "jackcontrol" is an *always" running deamon that defined an entry IPC
> point. jackcontrol get requests from control applications. "jackcontrol"
> can start
the existence of ~/.jackdrc is fine and using it in the future for legacy
reasons is also a good thing. Its format, on the other hand, is questionable. I
don't find it a good practice to call a server configuration file something
that is more some sort of shell script, because the current ~/.ja
Hi all,
Here is an updated version that add a new (to be defined) "config" API
in libjack.so. The idea is to provide a way to *share* multiple server
configurations in a unique place for all control application. The
important point are:
- we are not allowed to break legacy use of ~/.jackd
Le 20 mai 09 à 13:55, Krzysztof Foltman a écrit :
> Stéphane Letz wrote:
>
>> Not really, the existing IPC server/client scheme just need to be
>> extended with new "calls".
>
> Okay.
>
> Then, if you're keeping the "fork and exec" method of starting the
> server, will it in any way be guaranteed
Stéphane Letz wrote:
> Not really, the existing IPC server/client scheme just need to be
> extended with new "calls".
Okay.
Then, if you're keeping the "fork and exec" method of starting the
server, will it in any way be guaranteed than all control clients will
have the same functionality as the
On Tuesday 19 May 2009 23:05:51 Danni Coy wrote:
> Learning new ways of doing things takes time and effort.
Outside of this discussion, I think this is an important thing to keep in
mind. Let me explain it this way:
It irks me when people change things gratuitously and force me to spend my
time
Le 20 mai 09 à 12:20, Krzysztof Foltman a écrit :
> Stéphane Letz wrote:
>
>> This scheme seems to hopefully solve most of the problems we had, and
>> requires only a bit of change for the "jackdbus" front-end to
>> continue
>> working, but not much.
>
> One obvious problem is that it will be n
Stéphane Letz wrote:
> This scheme seems to hopefully solve most of the problems we had, and
> requires only a bit of change for the "jackdbus" front-end to continue
> working, but not much.
One obvious problem is that it will be necessary to create yet another
IPC protocol for control communicat
On Wed, May 20, 2009 10:32, Stéphane Letz wrote:
> Hi all,
>
>
> New much simplified proposal, should be "Fons compatible", hopefully
> "Nedko compatible" (with little work), "Paul one package only
> compatible", others "keep it simple compatible"...
>
> The first "big" conceptual change compared
Hi all,
New much simplified proposal, should be "Fons compatible", hopefully
"Nedko compatible" (with little work), "Paul one package only
compatible", others "keep it simple compatible"...
The first "big" conceptual change compared to the current SVN state is
this new "control IPC" schem
alex stone wrote:
> Perhaps someone who knows could explain briefly how reliable the dbus
> daemon is in terms of frequency of calls made in and out, and the
> timing involved.
It is quite high latency, mostly due to single-process userspace switch
point. It performs reasonably well as long as ove
15 matches
Mail list logo
