Re: [LAD] [PATCH] jack dbus and logs improvement

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

Re: [LAD] [PATCH] jack dbus and logs improvement

Marc-Olivier Barre-2
On Dec 9, 2007 9:35 PM, Nedko Arnaudov <[hidden email]> wrote:
> D-Bus patch requires logs patch. As currently exported it also requires
> midi-alsa-munge patch, but this is not real requirement.
>
> So patch apply order is (against latest svn, tested with r1070):
>  * jackd-midi-alsa-munge-r1051.patch (p0)
>  * jack-logs-20071209-r1070.patch (p1)
>  * jack-dbus-20071209-r1070.patch (p1)

And here comes the ebuild for those adventurous gentoo users out there
who want to try this baby out ! :-)

Right now it does not respect dependencies though, use with caution
and uninstall the regular jack package by hand first.

Now for some comment on these patches, I've been playing a bit with
that jack_control thingy. Configuring and starting jack has never been
so easy...

Enjoy,
__________________
Marc-Olivier Barre,
MarcO'Chapeau.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

jack-audio-connection-kit-dbus-9999.ebuild (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Paul Davis
On Mon, 2007-12-10 at 12:03 -0500, Dave Robillard wrote:
> On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov wrote:
> > Attached are two patches:
> >  * The logs patch replaces various calls to fprintf(),printf() and
> >    fputs() with calls to jack_error() and newly appeared jack_info()
> >    functionality. It also fixes some obvious error/info log mismatches
> >    in current code.
>
> I proposed this ages ago and Paul called it 'bloat' :)

see what happens when you ask nicely? :))



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
In reply to this post by Marc-Olivier Barre-2
Dave Robillard <[hidden email]> writes:

> On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov wrote:
>> Attached are two patches:
>>  * The logs patch replaces various calls to fprintf(),printf() and
>>    fputs() with calls to jack_error() and newly appeared jack_info()
>>    functionality. It also fixes some obvious error/info log mismatches
>>    in current code.
>
> I proposed this ages ago and Paul called it 'bloat' :)

logs patch has taken some direct directions from Paul that I followed
with fate that this will ease its way to jack trunk (pre 1.0).

Paul and others in charge, what you think?

>> Multiconfig functionality is provided by separate object to be reused by
>> control apps like patchage and qjackctl.
>
> I don't understand what this means in concrete terms.  Simple example?

Apps like patchage and qjackctl access the multiconfig object with
interface (quick draft):
 * get_presets() - return available presets names
 * new_preset() - add new preset
 * remove_preset() - remove existing preset
 * set/get of preset settings: engine options, selected driver, driver
   options of selected driver

That object will presist its settings in XML configuration file. I've
made example one available here:

http://nedko.arnaudov.name/soft/jack/jack.xml

or here:

http://triton.atia.com/nedko/soft/jack/jack.xml

This file is not acessed by control apps directly. Object methods are
used instead (see above).

Also either autosave mode (settings persistence) and manual save may be
viable. What will get implemented will probably be shaped by people in
charge of existing control apps (qjackctl,patchage). So put your
opinions please.

>> All of them will reuse jack
>> presets and user will get transparent workflow.
>> If they adapt it. Dave, Rui?
>
> Hm.. if the connection and new client/port callbacks are mapped to dbus
> messages (jack-dbus -> client) it would be possible to implement things
> like qjackctl/patchage/lash without a dependency on libjack at all.
> Nice...

This is the plan. We will need that for lash on dbus too (I want lash
to control jack server not vice versa). libjack interface is still
available as alternative method (dbus is not available on MacOSX by
default).

Speaking of MacOSX, I saw that there is fink package for D-Bus. It may
be worth for someone with Tiger/Leopard JACK audio setup to check how
well fink dbus package works with jackdbus.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Rui Nuno Capela
Nedko Arnaudov wrote:

> Dave Robillard <[hidden email]> writes:
>
>> On Sun, 2007-12-09 at 22:35 +0200, Nedko Arnaudov wrote:
>>> Attached are two patches:
>>>  * The logs patch replaces various calls to fprintf(),printf() and
>>>    fputs() with calls to jack_error() and newly appeared jack_info()
>>>    functionality. It also fixes some obvious error/info log mismatches
>>>    in current code.
>> I proposed this ages ago and Paul called it 'bloat' :)
>
> logs patch has taken some direct directions from Paul that I followed
> with fate that this will ease its way to jack trunk (pre 1.0).
>
> Paul and others in charge, what you think?
>
>>> Multiconfig functionality is provided by separate object to be reused by
>>> control apps like patchage and qjackctl.
>> I don't understand what this means in concrete terms.  Simple example?
>
> Apps like patchage and qjackctl access the multiconfig object with
> interface (quick draft):
>  * get_presets() - return available presets names
>  * new_preset() - add new preset
>  * remove_preset() - remove existing preset
>  * set/get of preset settings: engine options, selected driver, driver
>    options of selected driver
>
> That object will presist its settings in XML configuration file. I've
> made example one available here:
>
> http://nedko.arnaudov.name/soft/jack/jack.xml
>
> or here:
>
> http://triton.atia.com/nedko/soft/jack/jack.xml
>
> This file is not acessed by control apps directly. Object methods are
> used instead (see above).
>
> Also either autosave mode (settings persistence) and manual save may be
> viable. What will get implemented will probably be shaped by people in
> charge of existing control apps (qjackctl,patchage). So put your
> opinions please.
>
>>> All of them will reuse jack
>>> presets and user will get transparent workflow.
>>> If they adapt it. Dave, Rui?

eh... right, now that qjackctl is having a free ride on windows we can
put it back where it belongs :)

this d-bus interface seems a good idea nevertheless, and now that kde4
is almost on the brink, it sounds logical to push it as duct tape for
phonon and jack, eh?

cheers
--
rncbc aka Rui Nuno Capela
[hidden email]

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

David Robillard-3
In reply to this post by Marc-Olivier Barre-2
Hi all,

Attached is a big patch of nedko's logs, midi, and dbus changes with
modifications.  I removed the (IMO confusing and unnecessary) split of
jackd (nuking some redundant code) and made the single jackd executable
work as it always has, or in dbus control mode when run as jackd --dbus

Example:

$ ps aux | grep jack
dave     19064  0.0  0.0   3920   572 pts/2    S+   20:56   0:00
        grep jack


$ jack_control start
--- start


$ ps aux | grep jack
dave     19067  0.5  0.2  74992  5804 ?        Ssl  20:56 0:00
        /usr/local/bin/jackd --dbus
dave     19073  0.0  0.0   3916   568 pts/2    S+   20:56   0:00
        grep jack


$ jack_control stop
--- stop

$ ps aux | grep jack
dave     19076  0.0  0.0   3920   572 pts/2    S+   20:56   0:00
        grep jack

(All other jackd args and functionality remain completely unchanged).

Also fixed quite a few warnings and doxygen errors.

Remote controllable jackd is nice, but first thing's first:  It would
REALLY be nice to have nedko's jackd-midi-alsa-munge and jack-logs
patches applied to trunk to kill the intolerably awful midi port naming
problem and shrink the size of this behemoth patch.  Both are
straightforward, fix things that need fixing, and break nothing.

PLEASE? :)

Attached patch is against most recent SVN, R1070

Cheers,

-DR-

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

jack-midinames-logs-dbus-1.patch (81K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
Dave Robillard <[hidden email]> writes:

> Hi all,
>
> Attached is a big patch of nedko's logs, midi, and dbus changes with
> modifications.  I removed the (IMO confusing and unnecessary) split of
> jackd (nuking some redundant code) and made the single jackd executable
> work as it always has, or in dbus control mode when run as jackd --dbus
>
> Example:
>
> $ ps aux | grep jack
> dave     19064  0.0  0.0   3920   572 pts/2    S+   20:56   0:00
> grep jack
>
>
> $ jack_control start
> --- start
>
>
> $ ps aux | grep jack
> dave     19067  0.5  0.2  74992  5804 ?        Ssl  20:56 0:00
> /usr/local/bin/jackd --dbus
> dave     19073  0.0  0.0   3916   568 pts/2    S+   20:56   0:00
> grep jack
>
>
> $ jack_control stop
> --- stop
>
> $ ps aux | grep jack
> dave     19076  0.0  0.0   3920   572 pts/2    S+   20:56   0:00
> grep jack
>
> (All other jackd args and functionality remain completely unchanged).
I'd like to hear what other ppl think about this. It works for me both
ways. If most ppl like to have two modes merged in one executable just
to see jackd is running not jackdbus, so be it, I'll merge those changes
into dbus patch.

> Also fixed quite a few warnings and doxygen errors.

Having those as separate patches for review and commit in trunk would be
great.

> Remote controllable jackd is nice, but first thing's first:  It would
> REALLY be nice to have nedko's jackd-midi-alsa-munge and jack-logs
> patches applied to trunk to kill the intolerably awful midi port naming
> problem and shrink the size of this behemoth patch.  Both are
> straightforward, fix things that need fixing, and break nothing.
>
> PLEASE? :)

PLEASE? :)

> Attached patch is against most recent SVN, R1070

It is not usable directly. At least it misses some files introduced by
the dbus patch:
jackd.c:43:22: error: jackdbus.h: No such file or directory

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
Krzysztof Foltman <[hidden email]> writes:

> Nedko Arnaudov wrote:
>
>> I'd like to hear what other ppl think about this. It works for me both
>> ways. If most ppl like to have two modes merged in one executable just
>> to see jackd is running not jackdbus, so be it, I'll merge those changes
>> into dbus patch.
>
> I'm definitely in favour of the merge. The previous solution (old jackd,
>  new jackdbus) was definitely confusing to me. While I understand the
> distinction now, it wasn't obvious at first.
So having jackd behave in orthagonal way is not confusing? Like, jackd
process is running, why my apps cannot connect?!?!?

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
Lars Luthman <[hidden email]> writes:

> On Tue, 2007-12-18 at 16:56 +0200, Nedko Arnaudov wrote:
>> Krzysztof Foltman <[hidden email]> writes:
>>
>> > Nedko Arnaudov wrote:
>> >
>> >> I'd like to hear what other ppl think about this. It works for me both
>> >> ways. If most ppl like to have two modes merged in one executable just
>> >> to see jackd is running not jackdbus, so be it, I'll merge those changes
>> >> into dbus patch.
>> >
>> > I'm definitely in favour of the merge. The previous solution (old jackd,
>> >  new jackdbus) was definitely confusing to me. While I understand the
>> > distinction now, it wasn't obvious at first.
>>
>> So having jackd behave in orthagonal way is not confusing? Like, jackd
>> process is running, why my apps cannot connect?!?!?
>
> libjack needs to start the server automatically just like it does now.
> How does that work with the D-Bus control thing?
If libjack is compiled with dbus support it will first try to start jack
server through dbus. if it fails, it will fall back to the old
behaviour (reading ~/.jackdrc) and try to start jackd through it.

Starting it through dbus means activating the dbus object if not already
activated and strting the server. Calling any method of the dbus object,
"server start" in this case, autoactivates the object.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
In reply to this post by Nedko Arnaudov
Krzysztof Foltman <[hidden email]> writes:

> Nedko Arnaudov wrote:
>
>> So having jackd behave in orthagonal way is not confusing? Like, jackd
>> process is running, why my apps cannot connect?!?!?
>
> In normal situations, this jackd process (the launcher) would be only
> short-lived (less than a second). It might hang for some reason, because
> of faulty driver or something else, but then it would be a rare
> exception, not a rule. Plus, it's no worse than what would happen in
> non-dbus jack (where jackd would be present in process list, but would
> not respond).
>
> If the "jackd in engine mode" (jackd started with --dbus) is running,
> applications are able to connect, aren't they?
From what i've understood of Dave's patch, it enables jackd executable
to start jackdbus thing (same executable). I.e. no separate launcher
executable.

> Or maybe you should describe your "jackd process running, apps can't
> connect" scenario in more detail, in case I got it wrong? Basically,
> what turn of events results in jackd running but not responding to events?

jack controller dbus object is... controller, not server. it allows you
to mange jack server. This includes starting stopping jack server and
also configureing it.

Some terms explained:
 * jack server is the what is seen by jack clients (audio/midi, through
   libjack).
 * jack controller is a dbus object that can start jack server
 * jackd is the name of the executable starting jack server and parsing
   commandline arguments to configure both engine and driver
 * jackdbus is the name of the executable providing jack controller dbus
   object. it can start jack server, amoung other things it can do.

Discalimer: this is how it works now, not how Dave made it work.

You can have jackdbus process running and server stopped. And this
happens when you have jack controller dbus object activated but server
not started.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
In reply to this post by Nedko Arnaudov
Krzysztof Foltman <[hidden email]> writes:

> Krzysztof Foltman wrote:
>
>>> So having jackd behave in orthagonal way is not confusing? Like, jackd
>>> process is running, why my apps cannot connect?!?!?
>> In normal situations, this jackd process (the launcher) would be only
>> short-lived (less than a second).
>
> Looks like I was wrong - you're assuming that starting jackd manually
> would case that starter process to wait until it's manually stopped,
> like jackd did before?
There is no such thing as starter process implemented. By me - for
sure. From what I've understood from Dave's patch - by him too.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
In reply to this post by Nedko Arnaudov
Krzysztof Foltman <[hidden email]> writes:

> Nedko Arnaudov wrote:
>
>>> If the "jackd in engine mode" (jackd started with --dbus) is running,
>>> applications are able to connect, aren't they?
>> From what i've understood of Dave's patch, it enables jackd executable
>> to start jackdbus thing (same executable). I.e. no separate launcher
>> executable.
>
> Looks like a good approach. But, then, I'm still not sure I understand
> what you wrote previously:
>
> "So having jackd behave in orthagonal way is not confusing? Like, jackd
> process is running, why my apps cannot connect?!?!?"
>
> Did you mean a situation when Dave's jackd process is running and
> handling DBUS requests, but the server itself (as in, the thingy that
> JACK clients are connecting to) is not running?
yes, this is what i mean

> If that's really the case, the jack controller can detect the fact it
> has just turned the server off, and rename its process to jackd
> (inactive) or jack-dbus-controller or something in this fashion. Then,
> when the server is started, it renames itself back to jackd. Of course,
> I mean, renames the process, not the actual executable (that'd be insane!)

will work

> It's not exactly a typical behaviour, but it should eliminate the
> problems with interpretation of process list. I don't see any particular
> disadvantages (apart from "it's extra work").

no particular disadavantages, i agree.

Some more thoughts:
 - this seems like trying to push something square into round hole. But
   if that will help, then it may be worth to implement it
 - non-technically competent users should not use process list and
   assume things they dont understand by definition.
 - technically competent users should *read* how things are working.
 - i bet that most techincally competent users will get confused by
   changing process name on the fly
 - dbus is there to simplify things not complicate them. users should
   determine if server is working by using their control/monitor
   app. this means looking at tray icon by Marc, or dockapp by me, or
   calling jack_control status and examining the result (it has return
   value tha can be checked too).
 - Using process list is poor man approach when things are not working
   as expected. This implies techically competent user anyway.
 - this is a political issue that i personally think should be handled
   by distro packagers (power users, super technically competent).

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Marc-Olivier Barre-2
On Dec 18, 2007 6:09 PM, Nedko Arnaudov <[hidden email]> wrote:
>  - dbus is there to simplify things not complicate them. users should
>    determine if server is working by using their control/monitor
>    app. this means looking at tray icon by Marc, or dockapp by me, or
>    calling jack_control status and examining the result (it has return
>    value tha can be checked too).

Alpha release comming soon I hope. I also hope (and that's why I'm
working hard on this) that trying Nedko's patch with these applets
will make it clearer for everyone how cool a feature a dbus control
interface can be.

Although I like very much (and use) Rui's qjackctl, the simplycity
brought by dbus cannot be ignored. The new logfile feature is also
very interesting in my opinion.

cheers ;-)
__________________
Marc-Olivier Barre,
MarcO'Chapeau.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

David Robillard-3
In reply to this post by Nedko Arnaudov
On Tue, 2007-12-18 at 15:07 +0200, Nedko Arnaudov wrote:
> Dave Robillard <[hidden email]> writes:
> > Also fixed quite a few warnings and doxygen errors.
>
> Having those as separate patches for review and commit in trunk would be
> great.

It's not worth the effort if jack is dead as it appears to be.

I will split it when the midi munge and logs patches get applied, or we
branch jack, or whatever

-DR-



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

David Robillard-3
In reply to this post by Nedko Arnaudov

On Tue, 2007-12-18 at 16:56 +0200, Nedko Arnaudov wrote:

> Krzysztof Foltman <[hidden email]> writes:
>
> > Nedko Arnaudov wrote:
> >
> >> I'd like to hear what other ppl think about this. It works for me both
> >> ways. If most ppl like to have two modes merged in one executable just
> >> to see jackd is running not jackdbus, so be it, I'll merge those changes
> >> into dbus patch.
> >
> > I'm definitely in favour of the merge. The previous solution (old jackd,
> >  new jackdbus) was definitely confusing to me. While I understand the
> > distinction now, it wasn't obvious at first.
>
> So having jackd behave in orthagonal way is not confusing? Like, jackd
> process is running, why my apps cannot connect?!?!?

?

If apps can't connect to a running jackd, then that is a bug with the
d-bus stuff regardless of what the executable is called.

-DR-



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

melanie-36
In reply to this post by David Robillard-3
Hi,

Dave Robillard wrote:
> It's not worth the effort if jack is dead as it appears to be.


Why do you say that jack is dead?

Melanie

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

David Robillard-3
In reply to this post by Nedko Arnaudov
On Tue, 2007-12-18 at 18:24 +0200, Nedko Arnaudov wrote:

> Krzysztof Foltman <[hidden email]> writes:
>
> > Nedko Arnaudov wrote:
> >
> >> So having jackd behave in orthagonal way is not confusing? Like, jackd
> >> process is running, why my apps cannot connect?!?!?
> >
> > In normal situations, this jackd process (the launcher) would be only
> > short-lived (less than a second). It might hang for some reason, because
> > of faulty driver or something else, but then it would be a rare
> > exception, not a rule. Plus, it's no worse than what would happen in
> > non-dbus jack (where jackd would be present in process list, but would
> > not respond).
> >
> > If the "jackd in engine mode" (jackd started with --dbus) is running,
> > applications are able to connect, aren't they?
>
> From what i've understood of Dave's patch, it enables jackd executable
> to start jackdbus thing (same executable). I.e. no separate launcher
> executable.

It just does whatever jackdbus did when run as jackd --dbus.

If that means it's running as some separate launcher thing that isn't in
fact jackd, then that'll need fixing.  It /appears/ to work as it should
anyway

I don't see why there is confusion or debate involved here to be honest.
This separate executable thing is just plain weird from the user
perspective.  Making everything more complicated and requiring users to
take a day course in weird d-bus lingo to start jack isn't progress:

jack_control start

If that doesn't start jackd, it doesn't do what it should.

That aside, everything else about the d-bus stuff looks pretty good

-DR-



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

David Robillard-3
In reply to this post by Nedko Arnaudov

On Tue, 2007-12-18 at 18:27 +0200, Nedko Arnaudov wrote:

> Krzysztof Foltman <[hidden email]> writes:
>
> > Krzysztof Foltman wrote:
> >
> >>> So having jackd behave in orthagonal way is not confusing? Like, jackd
> >>> process is running, why my apps cannot connect?!?!?
> >> In normal situations, this jackd process (the launcher) would be only
> >> short-lived (less than a second).
> >
> > Looks like I was wrong - you're assuming that starting jackd manually
> > would case that starter process to wait until it's manually stopped,
> > like jackd did before?
>
> There is no such thing as starter process implemented. By me - for
> sure. From what I've understood from Dave's patch - by him too.

OK, good - didn't think so (didn't add one myself, no.  quite the
opposite...)

-DR-



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

David Robillard-3
In reply to this post by Marc-Olivier Barre-2
On Tue, 2007-12-18 at 19:50 +0100, Marc-Olivier Barre wrote:

> On Dec 18, 2007 6:09 PM, Nedko Arnaudov <[hidden email]> wrote:
> >  - dbus is there to simplify things not complicate them. users should
> >    determine if server is working by using their control/monitor
> >    app. this means looking at tray icon by Marc, or dockapp by me, or
> >    calling jack_control status and examining the result (it has return
> >    value tha can be checked too).
>
> Alpha release comming soon I hope. I also hope (and that's why I'm
> working hard on this) that trying Nedko's patch with these applets
> will make it clearer for everyone how cool a feature a dbus control
> interface can be.

It should be clear 'n cool all the way down :)

-DR-



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
In reply to this post by Nedko Arnaudov
Fons Adriaensen <[hidden email]> writes:

> We have a nice app called jackd even if it doesn't really
> deserve the final 'd'. It works quite well. Please keep it
> that way.
>
> I'm all in favour of a control interface to jackd that is
> separated from the audio client interface.
>
> But so far I've failed to understand which useful features,
> if any, this dbus stuff would add to jackd. If it's 'desktop'
> related, please solve it at that level, but don't destroy a
> well working application.
So you failed to understand how it works, thus how jackdbus differes
From jackd, and yet you think it should work in some other way? :D Or
I've misunderstood you?

Exactly the reason to not destroy existing well working application
(jackd) is the main reason I made jackdbus separate app.

The useful feature is one you mentioned, to separate control
interface. It also adds the logfile thing. Also it adds settings
persistence on jack side, so you dont need to have cryptic ~/.jackdrc
file, edited either by hand or by control app that needs to know what
jackd options are (moving target, also depends on drivers used).

Actually I think both settings persistence and logfile can be used by
jackd too, but this will probably not happen anytime soon. At least for
settings persistence, Paul told me once that it is probably post 1.0
(guess when is that :D).

I we had server lib, to be reused by both jackd and jackdbus,
jackdbus could be made completely separate app, it will not need compile
time access to jack sources. Unfortunately, I dont think this can be
made easily and in non-intrusive way.

Can you explain what you mean by solving things at desktop level?

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [LAD] [PATCH] jack dbus and logs improvement

Nedko Arnaudov
In reply to this post by David Robillard-3
Dave Robillard <[hidden email]> writes:

>> So having jackd behave in orthagonal way is not confusing? Like, jackd
>> process is running, why my apps cannot connect?!?!?
>
> ?
>
> If apps can't connect to a running jackd, then that is a bug with the
> d-bus stuff regardless of what the executable is called.

It is not, it is a feature that allows you to change settings. This can
be (and is usually) done with stopped server.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

attachment0 (194 bytes) Download Attachment
123