21 Jan
2008
21 Jan
'08
10:12 a.m.
Now that the list traffic seems to have calmed down a bit I'd like to draw
attention to another, less controversial (hah!) subject... LASH. Please bear
with me the mandatory introduction:
The Finnish Centre for Open Source Solutions [0] along with a number of
Finnish companies (yes, Nokia's in) is hosting an annual event called
Summercode [1] this year for the third time. As you probably guessed it's a
lot like Google's Summer of Code, but I've understood that it's meant solely
for university students.
The students file applications detailing the project they wish to work on and
the goals they aim to reach. The winning applicants are granted three months
of paid (about 1800 euros/month) development time beginning from June.
For me, this represents an opportunity to get the mostest perfectest summer
job I can possibly imagine. I'm planning on submitting an application for
re-implementing LASH as a D-Bus service (it's Hip, Cool and Popular), and I'm
hoping I'll get lots and lots of feedback from the lot of you for carving out
my application.
Below are the goals in descending order which I believe matter the most. (I'm
in debt to Dave Robillard for sorting out the priorities to me.)
- Turn LASH into a D-Bus service daemon.
- Unify the client and server APIs
- New features, API changes, etc.
The last one is bound to be flammable, and I'm hoping that the feedback I get
will help me concentrate my efforts on what the developers and users think is
most important. Can't do everything in 3 months' time anyway.
The deadline for applications is February 20th, and I want mine to capture the
essence of creative cross-functional combinations of community synergies and
foresight for stimulating innovation.
Thanks,
Juuso
[0] http://www.coss.fi/web/coss/about
[1] http://www.coss.fi/web/coss/developers/summercode/faq
22 Jan
22 Jan
9:39 a.m.
Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
- Turn LASH into a D-Bus service daemon.
Do you mean lashd becoming a D-Bus service? If so, do you imagine
having logfile like of jackdbus?
I think it is quite important what will be changes for users of
LASH. The things you mentioned are changes either to internal
implementation or API. IMHO, all changes should be driven by desire to
solve current problems that LASH user have (as human using the whole
thing, not as API user). Thus problems that people have with LASH should
be taken into account. Here are my problems with LASH:
* auto-launching without logfile means no proper handling of lashified
apps stdout/stderr. It should have logfile, with prefixing output of
apps.
* lash is of mercy of libjack and crashing jackd often causes lashd
kill. This is just wrong. lash should be able to restart jack, tell
jack apps that jack server is started again so they can reconnect to
jack server and finally lash can restore jack connections.
* lash should preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
* there is no export/import "tarball" (single file) functionality, to
be used for backup of sessions and transfering them between machines
* lash apps should be allowed to do "light save", with app session
referecencing files/resources external to lash. This means for
example that such lash light save should not copy ardour wav files
that are linked (not copied) to lash directory.
* lash should be able to manage not lashified apps at least to extent
of launching them and connecting their ports.
* there is no good GUI for controlling lash. probably [wm]glashctl
fixes this. lash_panel use is PITA. Usable GUI should be part of the
lash tarball. Also, X11-less operations should be still possible
(command-line or ncurses).
* lash does not preserve X11 related properties of apps, like on what
screen (dual-head) they were.
* when opening/importing session, lash should be able to either replace
current session or merge it, to allow combining several simpler
sessions into more complex ones
Things that I'm not personally interested on (I don't think they worth
but there is nothing wrong if support for them is there, unless this
makes implementation much more complicated and thus bug-prone):
* Supporting connections for things other than JACK (read ALSA seq)
* Supporting multi machine sessions (several machines in a network used
in common session).
* Creating "universal" fit-all solution that works for every single app
on every single OS and thus, not being able to it at all using
available resources. This does not mean that support for other OS-es
should be avoided intentionally. Still, I need *Linux* Audio Session
Handler, not LASH Audio Session Handler.
I plan to donate my time to fixing LASH, after I (with Juuso's and
Marc's help) finish with jackdbus (patchbay and transport control
interfaces are still mising). I'd like everybody who has problems with
current state of LASH to write them in this thread.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
12:56 p.m.
On Tuesday 22 January 2008 15:39:20 Nedko Arnaudov wrote:
Juuso Alasuutari <juuso.alasuutari(a)gmail.com>
writes:
I didn't quite understand what you mean by this until I read onward. Are you
referring to capturing clients' output, like you mention below?
- Turn LASH into a D-Bus service daemon.
Do you mean lashd becoming a D-Bus service? If so, do you imagine
having logfile like of jackdbus? I think it is quite important what will be changes for
users of
LASH. The things you mentioned are changes either to internal
implementation or API. IMHO, all changes should be driven by desire to
solve current problems that LASH user have (as human using the whole
thing, not as API user). Thus problems that people have with LASH should
be taken into account. Here are my problems with LASH:
* auto-launching without logfile means no proper handling of lashified
apps stdout/stderr. It should have logfile, with prefixing output of
apps.
Capturing the clients' debug messages would indeed be helpful. How do you
think it should be handled?
One option would be to add a logging method to the API that the clients should
use. But as with most other client requirements, there's no way to control
that they actually behave correctly (think of loading and saving files
correctly). And even if they do, then what about other messages than those
deliberately put into the code, like e.g. GLib errors?
Idiot-proof capturing of stdout/err could probably only work if the client
process was executed from a wrapper. It could be accomplished with the D-Bus
service file, though. If all clients' service files would be mandated to
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then...
Umm, at least we could redirect the streams _somewhere_ -- but what to do
from thereon, I'm not sure.
* lash is of mercy of libjack and crashing jackd
often causes lashd
kill. This is just wrong. lash should be able to restart jack, tell
jack apps that jack server is started again so they can reconnect to
jack server and finally lash can restore jack connections.
* lash should preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is where I believe we both agree that turning LASH into a D-Bus service
will help. The session handler shouldn't be a JACK client; instead, the audio
server should be a D-Bus client of the session handler, although a Very
Special one. And that's something that the JACK D-Bus control interface will
enable.
* there is no export/import "tarball"
(single file) functionality, to
be used for backup of sessions and transfering them between machines
* lash apps should be allowed to do "light save", with app session
referecencing files/resources external to lash. This means for
example that such lash light save should not copy ardour wav files
that are linked (not copied) to lash directory.
These sound like they could be useful features. However, I feel that we should
settle on the more basic issues first.
* lash should be able to manage not lashified apps at
least to extent
of launching them and connecting their ports.
I'd say this sounds OK.
* there is no good GUI for controlling lash. probably
[wm]glashctl
fixes this. lash_panel use is PITA. Usable GUI should be part of the
lash tarball. Also, X11-less operations should be still possible
(command-line or ncurses).
None of my business... :) (On the other hand, it's important to distinguish
between features which only concern the UI and those that affect API design.)
* lash does not preserve X11 related properties of
apps, like on what
screen (dual-head) they were.
Are you really sure that this one is worth the effort? Sounds to me like an
awful long detour from managing audio sessions.
* when opening/importing session, lash should be able
to either replace
current session or merge it, to allow combining several simpler
sessions into more complex ones
This is high tech, and as such it sounds tempting. Too tempting to be
considered at this point.
Things that I'm not personally interested on (I
don't think they worth
but there is nothing wrong if support for them is there, unless this
makes implementation much more complicated and thus bug-prone):
* Supporting connections for things other than JACK (read ALSA seq)
The current LASH already handles ALSA Seq connections, and I think it's fair
that the D-Bus implementation would, too.
* Supporting multi machine sessions (several machines
in a network used
in common session).
* Creating "universal" fit-all solution that works for every single app
on every single OS and thus, not being able to it at all using
available resources. This does not mean that support for other OS-es
should be avoided intentionally. Still, I need *Linux* Audio Session
Handler, not LASH Audio Session Handler.
Please, you're confusing me. ;)
I plan to donate my time to fixing LASH, after I (with
Juuso's and
Marc's help) finish with jackdbus (patchbay and transport control
interfaces are still mising). I'd like everybody who has problems with
current state of LASH to write them in this thread.
I plan to continue working on jackdbus which is an important part of this
whole scenario. But until the winning applications are announced I'll refrain
from any actual LASH coding; I need to know the level of commitment I can
afford to make before I take on a task this big. I will need to hash things
out on a conceptual level beforehand though, as it's hard to pull a realistic
and credible development plan solely out of one's back pocket.
At this point I believe it would help to categorize the different sub-goals.
What issues are purely in the domain of API design, what are the things that
the daemon must handle, etc. I'll start sketching these and getting familiar
with what we have now, then post some sort of rough draft. In the meantime
I'll be happy if anyone wants to comment on the questions above.
Juuso
1:13 p.m.
Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
I was thinking about "sending" client stdout/stderror to log file (with
prefixing). I dont think we need to require registering of one dbus
service per lashified client (autolaunching). Also IMHO there is nothing
wrong with just capturing stdout/stderr of launched clients. Of course,
liblash (dbus version) will start lash service to provide "callbacks" for
the lash API.
Yes, except that I was thinking about not trating JACK server as LASH
client. Instead LASH should directly support and have special handling
of JACK server.
What are they? :)
*
auto-launching without logfile means no proper handling of lashified
apps stdout/stderr. It should have logfile, with prefixing output of
apps.
Capturing the clients' debug messages would indeed be helpful. How do you
think it should be handled?
One option would be to add a logging method to the API that the clients should
use. But as with most other client requirements, there's no way to control
that they actually behave correctly (think of loading and saving files
correctly). And even if they do, then what about other messages than those
deliberately put into the code, like e.g. GLib errors?
Idiot-proof capturing of stdout/err could probably only work if the client
process was executed from a wrapper. It could be accomplished with the D-Bus
service file, though. If all clients' service files would be mandated to
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then...
Umm, at least we could redirect the streams _somewhere_ -- but what to do
from thereon, I'm not sure. * lash is of
mercy of libjack and crashing jackd often causes lashd
kill. This is just wrong. lash should be able to restart jack, tell
jack apps that jack server is started again so they can reconnect to
jack server and finally lash can restore jack connections.
* lash should preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is where I believe we both agree that turning LASH into a D-Bus service
will help. The session handler shouldn't be a JACK client; instead, the audio
server should be a D-Bus client of the session handler, although a Very
Special one. And that's something that the JACK D-Bus control interface will
enable. * there is no
export/import "tarball" (single file) functionality, to
be used for backup of sessions and transfering them between machines
* lash apps should be allowed to do "light save", with app session
referecencing files/resources external to lash. This means for
example that such lash light save should not copy ardour wav files
that are linked (not copied) to lash directory.
These sound like they could be useful features. However, I feel that we should
settle on the more basic issues first. At this point I believe it would help to categorize
the different sub-goals.
What issues are purely in the domain of API design, what are the things that
the daemon must handle, etc. I'll start sketching these and getting familiar
with what we have now, then post some sort of rough draft. In the meantime
I'll be happy if anyone wants to comment on the questions above.
If you are talking about the liblash API, I'm oposed to breaking
it. OTOH, I think we could extend it or provide alternative API. We dont
need to kill lash pupil apps, right? :)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
2:40 p.m.
On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov wrote:
Hmm, I think I went too far with ideas about clients being auto-launched by
D-Bus. It would add complexity, demand that the clients register as services,
etc. And what a horrible mess it would be to try to launch more than one
instance of a client...
So if we don't have to change the way autolaunching happens now, things are as
simple as Bob Ham put it in his reply: just point stdout/err to a log file
after fork()'ing. That would be accomplished with a rather simple patch.
Yes, except that I was thinking about not trating JACK server as LASH
client. Instead LASH should directly support and have special handling
of JACK server.
I didn't mean that JACK would be just another ordinary client for LASH; lashd
would naturally have special handling for it. Lashd would communicate with
jackd using the D-Bus interface that we're working on now. What I did mean
was that lashd shouldn't be a "JACK client" in the usual sense of the word
anymore, i.e. no libjack dependency. I believe this is what you meant also?
(I can see now as I'm writing this that Bob Ham is expressing a different
opinion on the list, maybe he'd like to comment on this further?)
What are they? :)
We're discussing them now. :)
Right. But introducing D-Bus and all that it entails into the soup will
complicate things if the first priority is to keep the API identical.
For instance, a client which communicates LASH events via D-Bus will need a
D-Bus event loop. Let's say we implement a completely transparent D-Bus event
loop into liblash which is launched by lashdriver_init(). Now, if the client
wants to manage other various D-Bus connections on its own, there will be two
event loops running within the same process.
If a client wants to handle its LASH events using QtDBus or DBus-GLib then
lashdriver_init() shouldn't try to handle everything. And on the other hand,
I'd be happy to use a library which provides a D-Bus event loop and event
handling for LASH clients, instead of having to write one from scratch.
Juuso
Juuso Alasuutari <juuso.alasuutari(a)gmail.com>
writes:
<snip>
Idiot-proof
capturing of stdout/err could probably only work if the
client process was executed from a wrapper. It could be accomplished with
the D-Bus service file, though. If all clients' service files would be
mandated to include something like "Exec=/usr/bin/lash_exec
/usr/bin/foobar", then... Umm, at least we could redirect the streams
_somewhere_ -- but what to do from thereon, I'm not sure.
I was thinking about "sending" client stdout/stderror to log file (with
prefixing). I dont think we need to require registering of one dbus
service per lashified client (autolaunching). Also IMHO there is nothing
wrong with just capturing stdout/stderr of launched clients. Of course,
liblash (dbus version) will start lash service to provide "callbacks" for
the lash API. * lash is of mercy of libjack and crashing jackd
often causes lashd
kill. This is just wrong. lash should be able to restart jack, tell
jack apps that jack server is started again so they can reconnect to
jack server and finally lash can restore jack connections.
* lash should preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is where I believe we both agree that turning LASH into a D-Bus
service will help. The session handler shouldn't be a JACK client;
instead, the audio server should be a D-Bus client of the session
handler, although a Very Special one. And that's something that the JACK
D-Bus control interface will enable. * there is no export/import "tarball"
(single file) functionality, to
be used for backup of sessions and transfering them between machines
* lash apps should be allowed to do "light save", with app session
referecencing files/resources external to lash. This means for
example that such lash light save should not copy ardour wav files
that are linked (not copied) to lash directory.
These sound like they could be useful features. However, I feel that we
should settle on the more basic issues first. At this point
I believe it would help to categorize the different
sub-goals. What issues are purely in the domain of API design, what are
the things that the daemon must handle, etc. I'll start sketching these
and getting familiar with what we have now, then post some sort of rough
draft. In the meantime I'll be happy if anyone wants to comment on the
questions above.
If you are talking about the liblash API, I'm oposed to breaking
it. OTOH, I think we could extend it or provide alternative API. We dont
need to kill lash pupil apps, right? :) 
5:27 p.m.
On Tue, 2008-01-22 at 20:40 +0200, Juuso Alasuutari wrote:
Indeed, LASH already does have special handling of the JACK server. Too
much special handling, in fact, as some API functions have the word
"jack" in them, which is just bad.
The only thing that JACK-DBus changes from LASH's perspective is that it
would need to make different calls to create port connections and to
register its interest in graph changes. This isn't a big problem.
Bob
--
Bob Ham <rah(a)bash.sh>
On Tuesday 22 January 2008 19:18:10 Nedko Arnaudov
wrote:
> Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
> > This is where I believe we both agree that
turning LASH into a D-Bus
> > service will help. The session handler shouldn't be a JACK client;
> > instead, the audio server should be a D-Bus client of the session
> > handler, although a Very Special one. And that's something that the JACK
> > D-Bus control interface will enable.
I don't think this is necessary, or the right way to do it. All LASH
needs is a way to determine which JACK (or ALSA seq, etc) client
corresponds to which LASH client, how they are interconnected, and a way
to connect different clients together. These APIs exist already,
they're well defined and many applications use them. It's also a little
presumptuous to assume that LASH will be the only program that would
require such functionality.
So I'm not sure what benefit adding LASH support to jackd et al would
have. The best way to have the patch connection system as a D-Bus LASH
client would be to implement a bridge that interfaces with the existing
patch system APIs on one side and the LASH server on the other. In
which case, why bother with a bridge at all? You end up back with LASH
supporting the patch connection system, instead of the other way round.
Yes, except
that I was thinking about not trating JACK server as LASH
client. Instead LASH should directly support and have special handling
of JACK server.
I didn't mean that JACK would be just another ordinary client for LASH; lashd
would naturally have special handling for it. Lashd would communicate with
jackd using the D-Bus interface that we're working on now. What I did mean
was that lashd shouldn't be a "JACK client" in the usual sense of the word
anymore, i.e. no libjack dependency. I believe this is what you meant also?
(I can see now as I'm writing this that Bob Ham is expressing a different
opinion on the list, maybe he'd like to comment on this further?)
1:30 p.m.
On Tue, 2008-01-22 at 18:56 +0200, Juuso Alasuutari wrote:
On Tuesday 22 January 2008 15:39:20 Nedko Arnaudov
wrote:
Capturing the clients' debug messages would indeed
be helpful. How do you
think it should be handled?
Idiot-proof capturing of stdout/err could probably
only work if the client
process was executed from a wrapper. It could be accomplished with the D-Bus
service file, though. If all clients' service files would be mandated to
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then...
Umm, at least we could redirect the streams _somewhere_ -- but what to do
from thereon, I'm not sure.
Applications are already launched from a wrapper within lashd (what it
terms the "loader".) It calls fork() and exec(). The only thing that
needs to be done is to change stdout and stderr to point to a log file
after calling fork() and before calling exec(). The appropriate place
for the file would be the application's directory under the project
directory.
Bob
--
Bob Ham <rah(a)bash.sh>
2:58 p.m.
Bob Ham <rah(a)bash.sh> writes:
On Tue, 2008-01-22 at 18:56 +0200, Juuso Alasuutari
wrote:
Not just that, I want to know what app outputed what. If their out goes
to common log file, we need prefixing.
This log file is not bound just to session, lashd itself does output.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Tuesday 22 January 2008 15:39:20 Nedko
Arnaudov wrote:
Capturing the clients' debug messages would
indeed be helpful. How do you
think it should be handled?
Idiot-proof capturing of stdout/err could
probably only work if the client
process was executed from a wrapper. It could be accomplished with the D-Bus
service file, though. If all clients' service files would be mandated to
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then...
Umm, at least we could redirect the streams _somewhere_ -- but what to do
from thereon, I'm not sure.
Applications are already launched from a wrapper within lashd (what it
terms the "loader".) It calls fork() and exec(). The only thing that
needs to be done is to change stdout and stderr to point to a log file
after calling fork() and before calling exec(). The appropriate place
for the file would be the application's directory under the project
directory.
3:10 p.m.
On Tue, 2008-01-22 at 20:58 +0200, Nedko Arnaudov wrote:
Bob Ham <rah(a)bash.sh> writes:
Each connected LASH client has its own directory under the main LASH
project directory. By redirecting each client's output to a file in its
client-specific directory, there would be no common log file.
Bob
--
Bob Ham <rah(a)bash.sh>
On Tue, 2008-01-22 at 18:56 +0200, Juuso
Alasuutari wrote:
Not just that, I want to know what app outputed what. If their out goes
to common log file, we need prefixing. On Tuesday 22 January 2008 15:39:20 Nedko
Arnaudov wrote:
Capturing the clients' debug messages would
indeed be helpful. How do you
think it should be handled?
Idiot-proof capturing of stdout/err could
probably only work if the client
process was executed from a wrapper. It could be accomplished with the D-Bus
service file, though. If all clients' service files would be mandated to
include something like "Exec=/usr/bin/lash_exec /usr/bin/foobar", then...
Umm, at least we could redirect the streams _somewhere_ -- but what to do
from thereon, I'm not sure.
Applications are already launched from a wrapper within lashd (what it
terms the "loader".) It calls fork() and exec(). The only thing that
needs to be done is to change stdout and stderr to point to a log file
after calling fork() and before calling exec(). The appropriate place
for the file would be the application's directory under the project
directory.
3:21 p.m.
On Tuesday 22 January 2008 21:10:55 Bob Ham wrote:
Each connected LASH client has its own directory under the main LASH
project directory. By redirecting each client's output to a file in its
client-specific directory, there would be no common log file.
There's always the distant possibility that the log file's name matches the
client's data file's name, and if they're in the same directory things break.
What about "$project_root/$unique_client_id.log" instead of the client's
directory?
Juuso
On Tue, 2008-01-22 at 20:58 +0200, Nedko Arnaudov
wrote:
> Bob Ham <rah(a)bash.sh> writes:
<snip>
Applications are already launched from a wrapper
within lashd (what it
terms the "loader".) It calls fork() and exec(). The only thing that
needs to be done is to change stdout and stderr to point to a log file
after calling fork() and before calling exec(). The appropriate place
for the file would be the application's directory under the project
directory.
Not just that, I want to know what app outputed what. If their out goes
to common log file, we need prefixing.
3:26 p.m.
Juuso Alasuutari <juuso.alasuutari(a)gmail.com> writes:
On Tuesday 22 January 2008 21:10:55 Bob Ham wrote:
Each connected LASH client has its own directory under the main LASH
project directory. By redirecting each client's output to a file in its
client-specific directory, there would be no common log file.
There's always the distant possibility that the log file's name matches the
client's data file's name, and if they're in the same directory things break.
What about "$project_root/$unique_client_id.log" instead of the client's
directory?
IMHO normal, global and single lashd log file will serve us better.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Tue, 2008-01-22 at 20:58 +0200, Nedko Arnaudov
wrote:
> Bob Ham <rah(a)bash.sh> writes:
<snip>
Applications are already launched from a wrapper
within lashd (what it
terms the "loader".) It calls fork() and exec(). The only thing that
needs to be done is to change stdout and stderr to point to a log file
after calling fork() and before calling exec(). The appropriate place
for the file would be the application's directory under the project
directory.
Not just that, I want to know what app outputed what. If their out goes
to common log file, we need prefixing.
6:34 p.m.
On Tue, 2008-01-22 at 21:21 +0200, Juuso Alasuutari wrote:
On Tuesday 22 January 2008 21:10:55 Bob Ham wrote:
Each connected LASH client has its own directory under the main LASH
project directory. By redirecting each client's output to a file in its
client-specific directory, there would be no common log file.
There's always the distant possibility that the log file's name matches the
client's data file's name, and if they're in the same directory things break.
What about "$project_root/$unique_client_id.log" instead of the client's
directory?
This is already an issue; there is a ".config" directory that stores the
client's config data. Probably the best solution is to push the
client's data into a further subdirectory. You would then have a
structure like this:
$client_dir/
$client_dir/client-files/saved-file.xml
$client_dir/client-files/saved-file-2.xml
$client_dir/config-data/foo
$client_dir/config-data/bar
$client_dir/log.txt
rather than
$client_dir/
$client_dir/saved-file.xml
$client_dir/saved-file-2.xml
$client_dir/.config/foo
$client_dir/.config/bar
$client_dir/.log.txt
Bob
--
Bob Ham <rah(a)bash.sh>
On Tue, 2008-01-22 at 20:58 +0200, Nedko Arnaudov
wrote:
> Bob Ham <rah(a)bash.sh> writes:
<snip>
Applications are already launched from a wrapper
within lashd (what it
terms the "loader".) It calls fork() and exec(). The only thing that
needs to be done is to change stdout and stderr to point to a log file
after calling fork() and before calling exec(). The appropriate place
for the file would be the application's directory under the project
directory.
Not just that, I want to know what app outputed what. If their out goes
to common log file, we need prefixing.
2:23 p.m.
On Tue, 2008-01-22 at 15:39 +0200, Nedko Arnaudov wrote:
* lash is of mercy of libjack and crashing jackd
often causes lashd
kill. This is just wrong.
You're right, but it shouldn't be worked around. If energy is going to
be expended on this problem, it should be expended on fixing jackd such
that it doesn't crash in the first place.
If you start working around problems with JACK, I can envision a
situation where there is little motivation to fix bugs in JACK because
the cost of its crashing is so low.
More generally, LASH isn't a frontend for JACK. LASH (when controlling
JACK clients) relies on services that JACK provides. This isn't a bad
thing. The focus shouldn't be on taking control of jackd through LASH
but in making jackd more server-like, such that you don't need another
server just to control it.
* lash should preserve at least basic properties of
currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is outside the scope of LASH. Applications themselves should cope
with JACK parameters that don't match their saved state. They need to
cope with that regardless of LASH.
* lash should be able to manage not lashified apps at
least to extent
of launching them and connecting their ports.
The problem here is that there's no way to know which ports belong to
the app.
* lash does not preserve X11 related properties of
apps, like on what
screen (dual-head) they were.
Nor should it. The X11 system is nothing whatsoever to do with LASH,
intentionally. From LASH's perspective, anything to do with X11 is
entirely the client's responsibility. Adding X11-specific functionality
into the protocol, the server and the library should not happen.
Providing convenience functions to clients is a solution, eg
lash_x11_get_state_configs() and that returns a set of LASH configs
containing the state of the X11 system. And, of course, functions to
restore the state. But it should be separate from LASH itself, eg, in
some liblash-x11.
* Supporting connections for things other than JACK
(read ALSA seq)
LASH already does support ALSA seq. Future support would be connecting
via netjack, or firewire, or $next_big_thing.
Bob
--
Bob Ham <rah(a)bash.sh>
3:11 p.m.
Bob Ham <rah(a)bash.sh> writes:
Unless LASH is a frontend to JACK ;) Apps can cope, but should not be
forced to.
JACK *will* be improved (at least its dbus-interface) to fix this issue.
No, X11 display is managed by app launcher. I guess you already know
what DISPLAY environment variable is for.
Yes and also it already fails for almost everyone to do simple things. ;)
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
On Tue, 2008-01-22 at 15:39 +0200, Nedko Arnaudov
wrote:
What about the jack watchdog? What does get killed by it?
And actually, in my vision, LASH *should* be frontend to JACK.
In the same way some good all-in-one apps to that. LASH should behave
like all-in-one app in the perspective of connecting to audio hardware,
managing "projects", etc. all-in-one multi-process modlar app (system).
* lash is of mercy of libjack and crashing jackd
often causes lashd
kill. This is just wrong.
You're right, but it shouldn't be worked around. If energy is going to
be expended on this problem, it should be expended on fixing jackd such
that it doesn't crash in the first place.
If you start working around problems with JACK, I can envision a
situation where there is little motivation to fix bugs in JACK because
the cost of its crashing is so low.
More generally, LASH isn't a frontend for JACK. LASH (when controlling
JACK clients) relies on services that JACK provides. This isn't a bad
thing. The focus shouldn't be on taking control of jackd through LASH
but in making jackd more server-like, such that you don't need another
server just to control it. * lash should
preserve at least basic properties of currently started
JACK server, such as sample rate and availability of hardware
ports. When loading session whose JACK parameters dont match, user
should be given options what to do.
This is outside the scope of LASH. Applications themselves should cope
with JACK parameters that don't match their saved state. They need to
cope with that regardless of LASH. * lash should
be able to manage not lashified apps at least to extent
of launching them and connecting their ports.
The problem here is that there's no way to know which ports belong to
the app. * lash does
not preserve X11 related properties of apps, like on what
screen (dual-head) they were.
Nor should it. The X11 system is nothing whatsoever to do with LASH,
intentionally. From LASH's perspective, anything to do with X11 is
entirely the client's responsibility. Adding X11-specific functionality
into the protocol, the server and the library should not happen.
Providing convenience functions to clients is a solution, eg
lash_x11_get_state_configs() and that returns a set of LASH configs
containing the state of the X11 system. And, of course, functions to
restore the state. But it should be separate from LASH itself, eg, in
some liblash-x11. * Supporting
connections for things other than JACK (read ALSA seq)
LASH already does support ALSA seq. Future support would be connecting
via netjack, or firewire, or $next_big_thing.
6:18 p.m.
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
JACK *will* be improved (at least its dbus-interface) to fix this issue.
Just out of curiousity, how?
Bob
--
Bob Ham <rah(a)bash.sh>
Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up?
More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it? And actually, in my vision, LASH *should* be frontend
to JACK.
What you're talking about here isn't really a frontend for JACK, but an
abstraction layer. A layer that abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
To view LASH as the centre of a linux audio system is to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.
Patchage was always the intended style of interface for managing LASH
sessions and the audio system as a whole. LASH implements the
infrastructure necessary for such a system, but it doesn't implement the
system itself. It doesn't provide a patch-connection abstraction; it
doesn't try to start and stop jackd.
It seems that what you want is Patchage++. Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
Applications themselves should cope
with JACK parameters that don't match their saved state. They need to
cope with that regardless of LASH.
Unless LASH is a frontend to JACK ;) Apps can cope, but should not be
forced to. * lash should be able to manage not lashified apps at
least to extent
of launching them and connecting their ports.
The problem here is that there's no way to know which ports belong to
the app.
23 Jan
23 Jan
1:44 p.m.
I'm getting the feeling that there have been some misunderstandings in this
discussion. Let's see if I can help with them, or if I'll just end up
confusing things more. :)
On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
I don't think Nedko's proposal is motivated by a desire to work around
existing bugs. Sure, abstracting the LASH <-> JACK interface with D-Bus may
result in a less crash-prone lashd (i.e. if jackd goes down it won't take
lashd with it), but this is hardly the point. And I don't think that it would
cause the users to develop an indifferent attitude towards sound server
crashes. (For that we'd have to write an autorestart-on-crash feature that
would prevent any hiccups in the sound stream. :))
Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it? A layer that abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
If such a layer could be beneficial (which is my belief also), why do you
think that it's outside the scope of LASH planned improvements?
To view LASH as the centre of a linux audio system is
to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.
I personally don't see LASH as the centre of the audio system, and I'm not
sure that Nedko meant to say that either.
Patchage was always the intended style of interface
for managing LASH
sessions and the audio system as a whole. LASH implements the
infrastructure necessary for such a system, but it doesn't implement the
system itself. It doesn't provide a patch-connection abstraction; it
doesn't try to start and stop jackd.
I think we all agree on that. LASH isn't the controller application, it's
something that a controller application needs to fulfill its purpose.
It seems that what you want is Patchage++.
Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
Yes, at least I would like to see the day when one application can manage
everything that the concept of an "audio session" includes (Patchage is
probably pretty good already). But you've misunderstood the purpose of this
discussion. We're not out to turn LASH into a super daemon/application of the
sort that you're worried about. What we are trying to do is to think of how
the interfaces and features of LASH could better help support a controller
application's operation.
Juuso
5:21 p.m.
On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari wrote:
There's no reason to add a system-specific API layer to LASH itself.
The abstraction could be done by a separate library entirely, eg
libeasyjack.
I must have been thrown off by Nedko's words "LASH should behave like
all-in-one app" ;-)
The thing is, a lot of the problems that have been highlighted as
capable of being solved by LASH aren't really anything in LASH's domain
and *shouldn't* be solved by it.
For example, yes, you could add support for maintaining the specific
settings of the patch system (I'm referring not just to JACK here) but
that's not what LASH is concerned with. It only cares about patch
configurations and client state. If it's the case that LASH *has* to
control the settings of the patch system just to provide a usable
system, then it points to a problem with the patch system. If the user
wants to change settings on the fly then the patch system itself should
enable that.
IMHO, there is a lot of work to be done to properly provide the kind of
support that LASH is *trying* to provide, without going on and thinking
about what else it might be able to do. Here is the list of future LASH
work from a while back:
1.0
Client priorities
Track naming
Guaranteed save directory availability
I'm getting the feeling that there have been some
misunderstandings in this
discussion. Let's see if I can help with them, or if I'll just end up
confusing things more. :)
On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
It sounded suspiciously to me as though that was exactly what Nedko's
proposal was :-) As I understand it, the issue is that jackd crashes,
and when it does it tends to bring down the whole audio session which is
a nightmare from a usability perspective. Nedko's proposal is to create
some system outside of jackd that can account for those crashes and
maintain the audio session in spite of them.
I think this is wrong. It's saying "OK, jackd isn't robust and we're
going to take account of that in our JACK-dependent system" when what
should be said is "OK, jackd isn't robust so we're going to make it
robust."
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
I don't think Nedko's proposal is motivated by a desire to work around
existing bugs. Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it? A layer that
abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
If such a layer could be beneficial (which is my belief also), why do you
think that it's outside the scope of LASH planned improvements? To view LASH
as the centre of a linux audio system is to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.
I personally don't see LASH as the centre of the audio system, and I'm not
sure that Nedko meant to say that either. It seems that
what you want is Patchage++. Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
Yes, at least I would like to see the day when one application can manage
everything that the concept of an "audio session" includes (Patchage is
probably pretty good already). But you've misunderstood the purpose of this
discussion. We're not out to turn LASH into a super daemon/application of the
sort that you're worried about. What we are trying to do is to think of how
the interfaces and features of LASH could better help support a controller
application's operation. 1.0
Graded saves
Networked audio
User interface standard
Automatic client installation
And I would add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Use OSC
Rework API
Genericify patch-system specifics
Provide more useful event system (callbacks, etc)
Rewrite client library in gobject
Rewrite server in C++
Bob
--
Bob Ham <rah(a)bash.sh>
11:33 p.m.
Bob Ham <rah(a)bash.sh> writes:
There's no reason to add a system-specific API layer to LASH itself.
The abstraction could be done by a separate library entirely, eg
libeasyjack.
We are talking different dialects here.
I must have been thrown off by Nedko's words "LASH should behave like
all-in-one app" ;-)
From user perspective, yes. lash + patchage like app. Again, this is how
it *can* be shown to user. I perfectly know how LASH approach is different
From a real all-in-one app. And I personally want separate control
app. I.e. patchage for patchbay app, wmglashctl for control app. But I'm
sure most WIMP addicted ppl will like Patchage to behave as lash control
app. And IMHO, this it is a good feature to include in Patchage.
On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari
wrote:
IMHO, jack watchdog is feature, not bug. And yes, LASH needs a way to
handle it.
I'm getting the feeling that there have been
some misunderstandings in this
discussion. Let's see if I can help with them, or if I'll just end up
confusing things more. :)
On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
It sounded suspiciously to me as though that was exactly what Nedko's
proposal was :-) As I understand it, the issue is that jackd crashes,
and when it does it tends to bring down the whole audio session which is
a nightmare from a usability perspective. Nedko's proposal is to create
some system outside of jackd that can account for those crashes and
maintain the audio session in spite of them.
I think this is wrong. It's saying "OK, jackd isn't robust and we're
going to take account of that in our JACK-dependent system" when what
should be said is "OK, jackd isn't robust so we're going to make it
robust." On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
I don't think Nedko's proposal is motivated by a desire to work around
existing bugs. Bob Ham <rah(a)bash.sh> writes:
> More generally, LASH isn't a frontend for JACK.
What about the jack watchdog? What does get killed by it?
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? A layer that abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
If such a layer could be beneficial (which is my belief also), why do you
think that it's outside the scope of LASH planned improvements? To view LASH as the centre of a linux audio system is
to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.
I personally don't see LASH as the centre of the audio system, and I'm not
sure that Nedko meant to say that either. > > It seems that what you want is Patchage++.
Unfortunately, LASH isn't
> > that and I think you're likely to run into problems if you try and turn
> > it into that.
>
> Yes, at least I would like to see the day when one application can manage
> everything that the concept of an "audio session" includes (Patchage is
> probably pretty good already). But you've misunderstood the purpose of this
> discussion. We're not out to turn LASH into a super daemon/application of the
> sort that you're worried about. What we are trying to do is to think of how
> the interfaces and features of LASH could better help support a controller
> application's operation.
yes, no super-daemon, but just LASH serving better. How? We are
discussing that.
The thing is, a lot of the problems that have been
highlighted as
capable of being solved by LASH aren't really anything in LASH's domain
and *shouldn't* be solved by it.
For example, yes, you could add support for maintaining the specific
settings of the patch system (I'm referring not just to JACK here) but
that's not what LASH is concerned with. It only cares about patch
configurations and client state. If it's the case that LASH *has* to
control the settings of the patch system just to provide a usable
system, then it points to a problem with the patch system. If the user
wants to change settings on the fly then the patch system itself should
enable that.
IMHO, there is a lot of work to be done to properly provide the kind of
support that LASH is *trying* to provide, without going on and thinking
about what else it might be able to do. Here is the list of future LASH
work from a while back:
1.0
Client priorities
Track naming
Guaranteed save directory availability
It is quite obvious that we have different plans for "LASH". As for used
technologies, IMHO, this should be driven by people acutally commited to
writing and maintaing the code (ATM this means almost nobody). If it me
to decide, I'd probably use python dbus service as replacement for lashd.
Some thoughts regarding your 0.6 wishes:
UDP OSC is one of the evils of current implementation. It fails to work
if networking is not properly set. If you dont beleive me - ask
users. OTOH I'm probably one who strives for dbus lash (as lash app -
lash "daemon protocol) at smallest degree (Dave, Juuso). D-Bus is quite
useful, especially its service autolaunching feature, high level of
object interface abstraction and easy integration with high level
scripting languages like Python.
certificates? encryption? really? For 0.6? o.0
Overengeneering?
Probably has to do with your conquer the network plans. I'm not oposed
(network), but I dont think this is that much important ATM.
I dont think using gobject is good thing in this case, because of the
KDE/GNOME schism. It is a political issue - IMHO using gnome component
will restrict KDE adoption. I dislike the schism but unless we get
freedesktop.org object model, we are fscked to reimplement things from
scratch for things like jack, lash and slv2.
I do agree about "Provide more useful event system (callbacks,
etc)". However, it is important not to break current API, but extend it
or provide alternative API. I also agree with Juuso, that fixing the API
can (and probably will) be made after we fix the more important things.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
1.0
Graded saves
Networked audio
User interface standard
Automatic client installation
And I would add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Use OSC
Rework API
Genericify patch-system specifics
Provide more useful event system (callbacks, etc)
Rewrite client library in gobject
Rewrite server in C++
24 Jan
24 Jan
5:28 a.m.
On Thu, 2008-01-24 at 05:33 +0200, Nedko Arnaudov wrote:
I must have been thrown off by Nedko's words "LASH should behave like
all-in-one app" ;-)
From user perspective, yes. lash + patchage like app.
Well, more accurately it would be patchage-like-app + lash + jack + alsa
+ x11 and, if you're going to get networking in on the game, + ssh. You
can see that lash is just a small part of such a system. The key issue
becomes the patchage-like-app.
Bob Ham <rah(a)bash.sh> writes:
> On Wed, 2008-01-23 at 19:44 +0200, Juuso Alasuutari wrote:
>> I'm getting the feeling that there have been some misunderstandings in this
>> discussion. Let's see if I can help with them, or if I'll just end up
>> confusing things more. :)
>>
>> On Wednesday 23 January 2008 00:18:48 Bob Ham wrote:
>> > On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov wrote:
>> > > Bob Ham <rah(a)bash.sh> writes:
>> > > > More generally, LASH isn't a frontend for JACK.
>> > >
>> > > What about the jack watchdog? What does get killed by it?
>> > To try and work around a crash in jackd and present a system to the user
>> > where crashes make no difference is to
invite more problems. If you
>> > can't get jackd to stay up, what makes you think you can get your new
>> > system to stay up?
>>
>> I don't think Nedko's proposal is motivated by a desire to work around
>> existing bugs.
>
> It sounded suspiciously to me as though that was exactly what Nedko's
> proposal was :-)
IMHO, jack watchdog is feature, not bug. And yes, LASH
needs a way to
handle it.
Of course it needs to handle it. It needs to cleanly shut down due to
the catastrophic failure. That's very different from creating a layer
betwen JACK and the LASH clients where the catastrophic failure is
glossed over.
To view LASH
as the centre of a linux audio system is to misunderstand
its purpose. It might be able to *facilitate* a unified system, along
with JACK and other APIs, but it isn't the unified system itself. Such
a role is intended for the much-loathed "server interface" distinguished
in the LASH API.
I personally don't see LASH as the centre of the audio system, and I'm not
sure that Nedko meant to say that either. > IMHO, there is a lot of work to be done to
properly provide the kind of
> support that LASH is *trying* to provide, without going on and thinking
> about what else it might be able to do.
> 0.6
> Redesign client/server communication
> Certificate based security/encryption
> Use OSC
> Rework API
> Genericify patch-system specifics
> Provide more useful event system (callbacks, etc)
> Rewrite client library in gobject
> Rewrite server in C++
Some thoughts regarding your 0.6 wishes:
UDP OSC is one of the evils of current implementation.
Current implementation of what? Regardless, the transport that's used
isn't particularly important; you can just use TCP if UDP is an issue.
Or fix the UDP transport.
certificates? encryption? really? For 0.6? o.0
Overengeneering?
Possibly. However, I think it's a good idea to have it included at the
start of any redesign of the communication system.
I dont think using gobject is good thing in this case,
because of the
KDE/GNOME schism.
Just because the library is written using gobject, doesn't mean clients
have to be. It's now trivial to run a QT main loop and glib main loop
together:
http://developer.kde.org/documentation/tutorials/qtgtk/main.html
I do agree about "Provide more useful event
system (callbacks,
etc)". However, it is important not to break current API, but extend it
or provide alternative API. I also agree with Juuso, that fixing the API
can (and probably will) be made after we fix the more important things.
I think it's important *to* break the current API due to its many
issues. Why do you think that backwards compatibility with the current
API is important?
Bob
--
Bob Ham <rah(a)bash.sh>
6:26 a.m.
Bob Ham wrote:
Of course it needs to handle it. It needs to cleanly
shut down due to
the catastrophic failure.
You'd want that during live performance? :)
In a debug version, it could be desirable, but for "production" use
(sorry for webspeak) it is unacceptable. It should be as fault-tolerant
as possible in those situations.
Perhaps it should be handled via a configuration option (live
performance mode checkbox).
I think it's important *to* break the current API
due to its many
issues. Why do you think that backwards compatibility with the current
API is important?
LASH adoption was slow enough to start with. Several projects exist that
use current LASH, some are quite useful (Hydrogen, Specimen), do you
want to personally update each and every of those (including the
abandoned ones) and make the updates into each distribution? It just
won't work. Be realistic.
Krzysztof
7:09 a.m.
On Thu, 2008-01-24 at 10:25 +0000, Krzysztof Foltman wrote:
The issue here is the advancement of Linux Audio in general. Changing
APIs is a short-term issue. IMHO, the long-term benefits of a better
engineered API far outweigh the short-term costs of breaking
compatibility.
Not only that, but the number of applications that support the current
API is very small. And I would indeed personally update the
applications I use. I did it before, LADCCAifying various applications,
from scratch. You may recall that a set of patches were included in
LADCCA releases.
If people wanted to use the current API, they can carry on doing so.
There's no reason they have to update to a newer API; nobody is going to
go into lash-0.5.4.tar.gz on nongnu.org and change the files in it.
Bob
--
Bob Ham <rah(a)bash.sh>
Bob Ham wrote:
No. But I wouldn't try to automate dealing with it, unless it happened
a lot. But then, if it happened a lot, I'd fix the bug instead.
Of course it needs to handle it. It needs to
cleanly shut down due to
the catastrophic failure.
You'd want that during live performance? :) In a debug version, it could be desirable, but for
"production" use
(sorry for webspeak) it is unacceptable. It should be as fault-tolerant
as possible in those situations.
Yes, you're right, JACK should be as fault tolerant as possible :-)
I think
it's important *to* break the current API due to its many
issues. Why do you think that backwards compatibility with the current
API is important?
LASH adoption was slow enough to start with. Several projects exist that
use current LASH, some are quite useful (Hydrogen, Specimen), do you
want to personally update each and every of those
25 Jan
25 Jan
8:11 a.m.
On Thursday 24 January 2008 13:09:55 Bob Ham wrote:
I believe everyone on this list agrees on that. Would you have any ideas for
improving the current situation? I have the impression that JACK should be
able to produce a lot more debug on demand than it currently does; maybe this
could ease the bug hunting?
Juuso
In a debug
version, it could be desirable, but for "production" use
(sorry for webspeak) it is unacceptable. It should be as fault-tolerant
as possible in those situations.
Yes, you're right, JACK should be as fault tolerant as possible :-)
1:29 p.m.
On Fri, 2008-01-25 at 14:11 +0200, Juuso Alasuutari wrote:
On Thursday 24 January 2008 13:09:55 Bob Ham wrote:
I believe everyone on this list agrees on that. Would you have any ideas for
improving the current situation? I have the impression that JACK should be
able to produce a lot more debug on demand than it currently does; maybe this
could ease the bug hunting?
I'd point out that it's been a while since I did any work on jackd, so
things could have changed. I get the impression, just from using it,
that they haven't but I've not been into the code so I don't know.
Also, I'm seeing things through the fog of time so my view may be
blurred.
Having said that, JACK should be very much more dynamic. You should be
able to suspend the engine loop, change any setting, even change the
driver, and resume graph processing without any hiccups. If any
operation breaks real-time safety, clients should be able to register
callbacks to be notified of when real-time operation stops and when it
resumes (assuming all graph-execution is real-time.)
It was the case that the engine and driver were pretty immutable. If
the server was up and running, it meant a driver was loaded and the
engine loop was executing. If a driver was unloaded or the engine loop
stopped, it generally meant that the system was exiting (or crashing :-)
Clients were either running in real-time, or the system was checking
them out.
I think this shouldn't be the case. There should be an intermediate
state where there is a client graph but no driver. There should be a
state where there is no client graph and no driver and if there is an
empty client graph for whatever amount of time, the system should revert
to this state automatically, thus releasing audio hardware. More
importantly, there should be no problem changing from one state to
another, and staying in any state indefinitely.
The somewhat monolithic "jackd" should be broken into distinct parts,
which cleanly and robustly go up and down: server-as-a-whole, engine,
driver, graph, etc. If their existence is independant of one another,
they should go up and down independantly.
Like a car with a running motor, waiting for the driver to release the
clutch and the gears to mesh, jackd should be happy to sit there doing
nothing until enough of its parts are brought up for the system to burn
some rubber. Moreover, it should be able to cope with the user pushing
the clutch in, changing gears and releasing the clutch again.
That's all I have to say about that.
Bob
--
Bob Ham <rah(a)bash.sh>
In a
debug version, it could be desirable, but for "production" use
(sorry for webspeak) it is unacceptable. It should be as fault-tolerant
as possible in those situations.
Yes, you're right, JACK should be as fault tolerant as possible :-) 
1:51 p.m.
On Fri, 2008-01-25 at 17:29 +0000, Bob Ham wrote:
Having said that, JACK should be very much more dynamic. You should be
able to suspend the engine loop, change any setting, even change the
driver, and resume graph processing without any hiccups. If any
operation breaks real-time safety, clients should be able to register
callbacks to be notified of when real-time operation stops and when it
resumes (assuming all graph-execution is real-time.)
making jackd/jackdmp do this is easy.
the reason JACK doesn't do this (at present) is because of the burden it
represents to clients. one of the main reasons JACK has been widely
adopted is that it is simple and it hides almost of all aspects of the
h/w from clients, including sample rate.
if the model changes to one in which clients have to deal with arbitrary
changes in sample rate, presence of absence of h/w ports and more, its
not that it cannot work, but it presents a more challenging API for many
complex clients.
its has almost no impact on jack itself. so, before pushing for this
kind of thing so enthusiastically, i suggest we first consider how many
clients want to live in a processing graph that is truly this dynamic.
--p
3:47 p.m.
On Fri, 2008-01-25 at 12:51 -0500, Paul Davis wrote:
On Fri, 2008-01-25 at 17:29 +0000, Bob Ham wrote:
Well, I'm surprised to see jack_set_sample_rate_callback in the docs
then :-) I appreciate your point, though; very few clients implement
that callback.
JACK Rack pays attention to the sample rate when it saves and loads
files; it will recalculate plugin control values if they're sample
rate-dependant and the current rate is different to the rate when the
file was saved. However, it *doesn't* implement a callback to do the
same; that was always on the TODO list.
Having said that, JACK should be very much more dynamic. You should be
able to suspend the engine loop, change any setting, even change the
driver, and resume graph processing without any hiccups. If any
operation breaks real-time safety, clients should be able to register
callbacks to be notified of when real-time operation stops and when it
resumes (assuming all graph-execution is real-time.)
making jackd/jackdmp do this is easy.
the reason JACK doesn't do this (at present) is because of the burden it
represents to clients. one of the main reasons JACK has been widely
adopted is that it is simple and it hides almost of all aspects of the
h/w from clients, including sample rate. if the model changes to one in which clients have to
deal with arbitrary
changes in sample rate, presence of absence of h/w ports and more, its
not that it cannot work, but it presents a more challenging API for many
complex clients.
its has almost no impact on jack itself. so, before pushing for this
kind of thing so enthusiastically, i suggest we first consider how many
clients want to live in a processing graph that is truly this dynamic.
Indeed. JACK Rack implements file-based sample rate changes because
there is the issue of taking a save file to a different setup. It
doesn't implement a JACK callback because a sample rate callback is such
a rare event as to be a non-issue.*
Regardless, what I'm pointing to really is an ideal. There's a scale of
dynamicity. At one end is a system where each bit of the server is
behind an abstracted interface and implemented through dynamically
loaded and unloaded modules, where these parts communicate through
well-defined tubes, where every change of state has its appropriate
client-side callbacks, every client implements those callbacks, world
peace prevails, etc, etc.
At the other end is a jackd with just one big main() function.
As it is, jackd is somewhere in between. What I'm proposing is a shift
up the scale a little, towards world peace. There will be a limit where
the costs in terms of client-side complexity outweigh the benefits. I
think, though, that quite a lot could be done to improve the situation
before hitting that limit.
Bob
* I seem to recall we've had this exact discussion before :-)
--
Bob Ham <rah(a)bash.sh>
8:07 a.m.
On Thursday 24 January 2008 12:25:15 Krzysztof Foltman wrote:
Bob Ham wrote:
I volunteer for updating existing programs once a new and improved LASH API is
out the door! :)
I do also feel that the API could be much better. But at the same time I don't
think we should start by rewriting it. One step at a time...
Juuso
I think it's important *to* break the current
API due to its many
issues. Why do you think that backwards compatibility with the current
API is important?
LASH adoption was slow enough to start with. Several projects exist that
use current LASH, some are quite useful (Hydrogen, Specimen), do you
want to personally update each and every of those (including the
abandoned ones) and make the updates into each distribution? It just
won't work. Be realistic.
8:04 a.m.
On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
There's no reason to add a system-specific API layer to LASH itself.
The abstraction could be done by a separate library entirely, eg
libeasyjack.
By "system-specific API layer" do you mean D-Bus? And do you
say "system-specific" as opposed to "also connects between networked
computers"?
To me, it seems like overengineering to design the LASH <-> client protocol
with networks in mind. The lashd daemon can use D-Bus to communicate with
clients, but that doesn't mean that several LASH daemons running on different
computers couldn't communicate session events and data between eachother. The
idea would be that all LASH <-> client connections would be local, but one
session could be composed of several local LASH environments.
The thing is, a lot of the problems that have been highlighted as
capable of being solved by LASH aren't really anything in LASH's domain
and *shouldn't* be solved by it.
For example, yes, you could add support for maintaining the specific
settings of the patch system (I'm referring not just to JACK here) but
that's not what LASH is concerned with. It only cares about patch
configurations and client state. If it's the case that LASH *has* to
control the settings of the patch system just to provide a usable
system, then it points to a problem with the patch system. If the user
wants to change settings on the fly then the patch system itself should
enable that.
Yes, I suppose that the patch system settings for a session could be handled
by a dedicated patch system controller (e.g. QJackCtl), which would itself
just be a normal LASH client within the session. And when you would load a
saved session, the patch system controller would fire up and adjust the patch
system settings. LASH wouldn't care about its doings.
But then again, why should LASH even be concerned with the connections between
clients in the first place? Why doesn't LASH just start the clients, tell
them to load their settings, and leave the other stuff to a patch system
controller?
You probably noticed that the question was rhetorical. My point is: Where is
it precisely defined what LASH's domain is? Where does this reasoning and
concept model come from? I've gotten the feeling that this distinction that
you maintain between LASH and the rest of the system is nothing but a
tradition.
Extending LASH's domain to include not only the client state and their mutual
connections, but also the sound server configuration, is not conceptually
invalid although it may not be what LASH was originally _thought_ as. It may
not be a requirement for a usable system, but it does make things more
convenient for the users (and probably for the developers as well).
Can you explain this?
A layer that abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
If such a layer could be beneficial (which is my belief also), why do you
think that it's outside the scope of LASH planned improvements? It seems that what you want is Patchage++.
Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
Yes, at least I would like to see the day when one application can manage
everything that the concept of an "audio session" includes (Patchage is
probably pretty good already). But you've misunderstood the purpose of
this discussion. We're not out to turn LASH into a super
daemon/application of the sort that you're worried about. What we are
trying to do is to think of how the interfaces and features of LASH could
better help support a controller application's operation. IMHO, there is a lot of work to be done to properly
provide the kind of
support that LASH is *trying* to provide, without going on and thinking
about what else it might be able to do. Here is the list of future LASH
work from a while back:
I'm afraid I don't understand all of the things you mention below, probably
because there's hardly any descriptions there.
1.0
Client priorities
Can you explain what you mean by this?
Track naming
And this?
Guaranteed save directory availability
Does this simply mean that lashd will somehow make extra sure that the
directory exists, and that the client can write there? If so, it sounds good.
1.0
Graded saves Networked audio
And this?
User interface standard
And this?
Automatic client installation
This sounds an awful lot like stepping on the toes of packagers and package
managers. Unless you mean something completely different, of course.
And I would add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Why would managing an audio session demand that the connections be certified
and encrypted? Unless you're thinking network-wise (i.e. sessions that span
several networked computers).
By the way, did you know that D-Bus allows security policies?
Use OSC
Rework API
Genericify patch-system specifics
Provide more useful event system (callbacks, etc)
I think that an API overhaul would be welcome, and especially using callbacks
would be an improvement. But it's not first priority (thought not the lowest
either).
Rewrite client library in gobject
Rewrite server in C++
These sent a cold shiver down my spine... mostly because I don't know C++ and
I'm unwilling to learn it right now. :)
I've looked at the LASH code, and I must say it looks very well written.
You've done a great job. I don't see any reason why the current codebase
would need an overhaul. How do you feel that a rewrite in C++ would help LASH
as a project?
And about GObject... well, why bother? I understood from your reply to Nedko
that you're not suggesting that GObject be enforced into the actual LASH API,
which is a relief. I fail to see any benefit in GObject-ifying the internals,
either.
Juuso
8:34 a.m.
Juuso Alasuutari wrote:
And about GObject... well, why bother? I understood
from your reply to Nedko
that you're not suggesting that GObject be enforced into the actual LASH API,
which is a relief. I fail to see any benefit in GObject-ifying the internals,
either.
Yes, pretty please with sugar on top: please don't introduce the GObject
madness where it's not necessary.
I mean, GObject has its uses in GTK or other frameworks that are very
complex to start with. But please don't introduce complex, unintuitive,
wrist-damaging tools where a plain C-based[*] API could work just as well.
[*] Yes, I know GObject is C-based, but it's a whole layer of a huge
complex type system on top of C type system. It's also very far from
convenient, especially as far as introducing new types goes.
Chris
1:41 p.m.
On Fri, 2008-01-25 at 12:32 +0000, Krzysztof Foltman wrote:
I mean, GObject has its uses in GTK or other
frameworks that are very
complex to start with. But please don't introduce complex, unintuitive,
wrist-damaging tools where a plain C-based[*] API could work just as well.
The issue isn't really the API but its implementation. I'm not
proposing to mandate the use of GSignals for clients to register
callbacks, or sub-classing a GObject in order to implement a client.
But that doesn't mean liblash can't use GSignals and client classes
internally. Of course, in addition, you could then expose GSignals and
GObjects for those that *do* want to use them. And "easily" create C++
classes, and python classes, etc, etc.
Bob
--
Bob Ham <rah(a)bash.sh>
12:27 p.m.
On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari wrote:
That's pretty much it's raison d'etre :-) See the following, and note
the file name:
http://teasel.6gnip.net/~rah/why-ladcca.png
What you were talking about before; dependencies in running order of
clients. Priority is one (simple) way to solve that. Referential
dependencies are a lot trickier. Regardless, the issue needs to be
looked at and that's what this point was referring to.
Often there are chains of programs that operate on a single "track" (ie,
stereo audio stream.) Eg,
Drums: Hydrogen -> JACK Rack -> Ecasound
Bass: ZynAddSubFx -> Freqtweak -> JACK Rack -> Ecasound
Lead: QSynth -> Ecasound
In the above, each instance of JACK Rack has to have a separate JACK
client name. Most clients append the PID. JACK Rack (and, I assume
others) will let you set the JACK client name from the command-line. So
if you were constructing the about setup, you might execute the JACK
Rack instances like so:
$ jack-rack --string-name Drums &
$ jack-rack --string-name Bass
Which will create two JACK clients named "jack_rack_Drums" and
"jack_rack_Bass".
The purpose of "Track naming" in LASH would be to automate this and
present a convenient interface for setting track names.
Pretty much. At present, in a save operation, clients get told "Save in
$directory" and then the client responds "OK, I've saved there." With
this kind of protocol, the LASH system isn't providing any guarantee
that the directory will stay there. With programs like Ardour, which
need presistent directories, this a problem.
The solution is to have clients tell the server "I want a persistent
directory" when they start up. The server then tells them, "OK, use
$directory." Then, if the project is moved or closed or whatever, the
server tells the client "Stop using $directory." After the operation is
completed, the client can then be told again "OK, use
$possibly_different_directory."
LASH would only "make sure" that it exists within the LASH system
itself. There are, of course, issues of how to deal with things like
the directory being moved by errant user fiddling, or whatever. FAM may
be able to help with that.
Can you explain this?
"Save big-ass 50M wav file" vs "Save view settings" :-)
What's meant is: if you load a session and it includes a client that
isn't installed on the system, then make it such that it is installed
and the session can be loaded. This is no small thing. There are a few
options:
1. Create a system which abstracts package management for different
distros
2. Try and create an automatic compilation environment, similar to
ports on Freebsd or portage on Gentoo (lol)
3. Use autopackage
From the client side, this would be very simple: the programmer just
provides a URL to some meta-information that describes the packages
needed for that LASH client. I think this is pretty doable now that
number 3 exists.
I'm thinking network-wise.
The API is pretty central, considering that both clients and the server
share most of it. It is that from which all else comes. Hence, IMHO,
pretty high priority.
I appreciate the compliment, but with hindsight there are a lot of
things that could have been done much better. In general, the whole
thing would benefit greatly from object orientation.
Given this and the desire to present a C API, there are few options.
You could write the library and server both in C++ and provide a C
wrapper API/ABI. However, wrapping gobject APIs for C++ (and python,
and perl, and Java, and C#, etc, etc) has already been done a gazillion
times before. I know there are tools to help automate C++ wrapping
(which gtkmm et al use.) The weight is all leaning in gobject's
direction.
I'd use C++ for the server because a) C++ rocks, 2) the server doesn't
need to provide an external C ABI, and d) C++ rocks, and that's what I'd
want to use :-)
On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
There's no reason to add a system-specific API layer to LASH itself.
The abstraction could be done by a separate library entirely, eg
libeasyjack.
By "system-specific API layer" do you mean D-Bus?
No, I mean JACK or ALSA or raw1394 or whatever. I'm talking about
something like
lash_easy_jack_client_t *
lash_easy_jack_client(char *client_name,
char *input_port_names[],
char *output_port_names[],
jack_callback_t *cb);
In this case, there's no reason at all to have "lash_" in there.
A layer that abstracts away the incidental
obligations of being a JACK client would be good but that is very far
from the domain that LASH is intended to help with.
If such a layer could be beneficial (which is my belief also), why do you
think that it's outside the scope of LASH planned improvements? To me, it seems like overengineering to design the
LASH <-> client protocol
with networks in mind. The lashd daemon can use D-Bus to communicate with
clients, but that doesn't mean that several LASH daemons running on different
computers couldn't communicate session events and data between eachother. The
idea would be that all LASH <-> client connections would be local, but one
session could be composed of several local LASH environments.
The problem here is you then have two communication protocols; one for
local D-Bus communication, and one for inter-host lashd communication.
They're going to be communicating much the same information; client
properties, port names, etc. To have two protocols would be unwieldy.
For example,
yes, you could add support for maintaining the specific
settings of the patch system (I'm referring not just to JACK here) but
that's not what LASH is concerned with. It only cares about patch
configurations and client state. If it's the case that LASH *has* to
control the settings of the patch system just to provide a usable
system, then it points to a problem with the patch system. If the user
wants to change settings on the fly then the patch system itself should
enable that.
Yes, I suppose that the patch system settings for a session could be handled
by a dedicated patch system controller (e.g. QJackCtl), which would itself
just be a normal LASH client within the session. And when you would load a
saved session, the patch system controller would fire up and adjust the patch
system settings. LASH wouldn't care about its doings.
But then again, why should LASH even be concerned with the connections between
clients in the first place? 
Why doesn't LASH just start the clients, tell
them to load their settings, and leave the other stuff to a patch system
controller?
You probably noticed that the question was rhetorical.
My point is: Where is
it precisely defined what LASH's domain is? Where does this reasoning and
concept model come from? I've gotten the feeling that this distinction that
you maintain between LASH and the rest of the system is nothing but a
tradition.
There's three different ideas that could be surmised by "patch system
controller" (at least that I can think of.) There's something like
QJackCtl, which lets users adjust the settings of the patch system like
the sample rate, period size, etc (and we're talking about something
which does it on-the-fly, which doesn't exist yet.) Then there's LASH,
which monitors port connections and manages their automatic reconnection
when a session is restored. Then there's a patch bay, which allows the
user to adjust the connections while a session is active.
There are no inter-dependencies. They all provide distinct sets of
functionality and hence should be separate programs.
LASH is actually two separate sets of functionality in one system:
automatic port reconnection, and non-X11 session management. So, LASH
*does* leave "the other stuff" to a patch system; it leaves it to the
other functionality in itself :-)
It could be the case that the two sets of functionality in LASH can be
separated into different systems but off the top of my head I'm not sure
how inter-dependant they are. Specifically, I'm not sure whether
session management is completely independant of port reconnection, at
least in order to provide LASH functionality.
IMHO, there is
a lot of work to be done to properly provide the kind of
support that LASH is *trying* to provide, without going on and thinking
about what else it might be able to do. Here is the list of future LASH
work from a while back:
I'm afraid I don't understand all of the things you mention below, probably
because there's hardly any descriptions there.
1.0
Client priorities
Can you explain what you mean by this? Track naming
And this? Guaranteed
save directory availability
Does this simply mean that lashd will somehow make extra sure that the
directory exists, and that the client can write there? If so, it sounds good. 1.0
Graded saves > Networked audio
Handle sessions involving clients on different hosts who communicate
with each other over ports that require reconnecting. Eg, JACK clients
connected using firewire/netjack.
> User interface standard
Promote a standard to LASH clients in order to present a consistent user
interface. This would be like the GNOME HIG but audio-specific, eg,
specifying knob widget appearance and behaviour, recommending audio
widget toolkits, etc.
Automatic
client installation
This sounds an awful lot like stepping on the toes of packagers and package
managers. Unless you mean something completely different, of course. And I would
add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Why would managing an audio session demand that the connections be certified
and encrypted? Unless you're thinking network-wise (i.e. sessions that span
several networked computers). Rework API
Genericify patch-system specifics
Provide more useful event system (callbacks, etc)
I think that an API overhaul would be welcome, and especially using callbacks
would be an improvement. But it's not first priority (thought not the lowest
either). Rewrite client library in gobject
Rewrite server in C++
These sent a cold shiver down my spine... mostly because I don't know C++ and
I'm unwilling to learn it right now. :)
I've looked at the LASH code, and I must say it looks very well written.
You've done a great job. I don't see any reason why the current codebase
would need an overhaul. How do you feel that a rewrite in C++ would help LASH
as a project? And about GObject... well, why bother? I understood
from your reply to Nedko
that you're not suggesting that GObject be enforced into the actual LASH API,
which is a relief. I fail to see any benefit in GObject-ifying the internals,
either.
Object orientation. Events and configs in the communication system
share a lot of functionality. The patch system-specific functionality
could and should be generalised. In the server, the JACK- and
ALSA-specific functionality provide almost identical interfaces. When
writing it, I actually cut-and-pasted a lot of the function prototypes,
just changing "jack" to "alsa". A lot of the function bodies were
also
identical algorithms, only using the different JACK- and ALSA-specific
interfaces for the data. There's a lot of code in a lot of places that
could be made a lot better using objects.
Bob
--
Bob Ham <rah(a)bash.sh>
26 Jan
26 Jan
4:25 p.m.
On Friday 25 January 2008 18:27:10 Bob Ham wrote:
For domain separation this makes sense. Why add weight to the the LASH <->
client protocol with things such as encryption which most users will never
need?
Don't get me wrong; inter-host communication is a great idea (for future
implementation). But I think a local session protocol should be minimally
burdened by the needs of a minority. Yet this is not the only reason I'm
against a "lashd <-> the entire world" client protocol. Consider the
following:
If your session is spread across multiple networked computers, how will you be
able to auto-launch all the clients if there are no per-host daemons
involved? In other words, your master lashd can launch all the clients on the
master host, but if you also want to launch remote clients you will need some
kind of launcher daemon running on the remote computers.
If there's a lashd running on each computer, the master lashd can tell the
slave lashds to auto-launch their clients. It seems to me that adding this
lashd-to-lashd layer between local domains is both friendlier for clients in
terms of protocol complexity and also enables better control.
OK, I see. :)
What you were talking about before; dependencies in running order of
clients. Priority is one (simple) way to solve that. Referential
dependencies are a lot trickier. Regardless, the issue needs to be
looked at and that's what this point was referring to.
Good idea, I agree.
Often there are chains of programs that operate on a single "track" (ie,
stereo audio stream.) Eg,
Drums: Hydrogen -> JACK Rack -> Ecasound
Bass: ZynAddSubFx -> Freqtweak -> JACK Rack -> Ecasound
Lead: QSynth -> Ecasound
In the above, each instance of JACK Rack has to have a separate JACK
client name. Most clients append the PID. JACK Rack (and, I assume
others) will let you set the JACK client name from the command-line. So
if you were constructing the about setup, you might execute the JACK
Rack instances like so:
$ jack-rack --string-name Drums &
$ jack-rack --string-name Bass
Which will create two JACK clients named "jack_rack_Drums" and
"jack_rack_Bass".
The purpose of "Track naming" in LASH would be to automate this and
present a convenient interface for setting track names.
I'm not sure that this level of session management is necessary for LASH. But
it may very well be that I'm still not getting the point.
Pretty much. At present, in a save operation, clients get told "Save in
$directory" and then the client responds "OK, I've saved there."
With
this kind of protocol, the LASH system isn't providing any guarantee
that the directory will stay there. With programs like Ardour, which
need presistent directories, this a problem.
The solution is to have clients tell the server "I want a persistent
directory" when they start up. The server then tells them, "OK, use
$directory." Then, if the project is moved or closed or whatever, the
server tells the client "Stop using $directory." After the operation is
completed, the client can then be told again "OK, use
$possibly_different_directory."
LASH would only "make sure" that it exists within the LASH system
itself. There are, of course, issues of how to deal with things like
the directory being moved by errant user fiddling, or whatever. FAM may
be able to help with that.
Perhaps lashd could monitor the current save dir via FAM and at least produce
a warning if it gets deleted. But that's more of a tweak than a feature.
How about if a guaranteed directory would be the default? The clients would
receive a directory name (and could also ask for it later if they have a
short memory or something), and it would be guaranteed to exist unless a
special "directory has changed" message has arrived.
Therefore the usual save command wouldn't be "save to $dir", but rather
"save
to the dir that i gave you during init". Only special save commands
like "export all data to $outside_dir" would include the dir name with the
command itself.
Can you explain this?
"Save big-ass 50M wav file" vs "Save view settings" :-)
I don't get this. But sounds like what's been talked about on #lad: Different
save types like "normal save", "light save", "export"...
OK, sounds like a reasonable long-term goal.
You're treading on flammable ground here. I wouldn't want LASH to have the
slightest authority over what toolkits and/or widgets the clients are coded
with. And I don't see any reason why LASH should even care; LASH isn't a
plugin host. I should be able to include an Ncurses-based drum machine with
my session if I please.
What's meant is: if you load a session and it includes a client that
isn't installed on the system, then make it such that it is installed
and the session can be loaded. This is no small thing. There are a few
options:
1. Create a system which abstracts package management for different
distros
2. Try and create an automatic compilation environment, similar to
ports on Freebsd or portage on Gentoo (lol)
3. Use autopackage
From the client side, this would be very simple: the programmer just
provides a URL to some meta-information that describes the packages
needed for that LASH client. I think this is pretty doable now that
number 3 exists.
Yes, you are stepping on packagers' toes here -- heavily.
Abstracting package management for distros is an insanely huge task, and not
likely to work in practice. Creating an automatic compilation environment --
well, I assume you're joking, because this would equal writing your own
source-based package manager. Using autopackage is out of the question,
because you simply can't fulfill the needs of all distros even with such a
system. (No, rpm and deb aren't the entire universe.)
If a session manager would take on package management like this -- which it
definitely _shouldn't_ in the first place -- it would have to work absolutely
_perfectly_ on _all_ possible distros. Either that, or nothing.
I'm a packager myself, for a smallish source-based distro called Source Mage.
The way our package manager works is likely to be incompatible with any other
system. I wouldn't want autopackage messing around with my box -- I want
packages installed the way they normally are with Source Mage.
Considering how you've been defending LASH from features that you deem outside
of its domain, I'm surprised that you would come up with this idea.
There is something I could think of, though. Maybe LASH clients could register
a homepage URL or equivalent piece of information which would help the user
to hunt down the missing program in case he/she needs to? That's about as far
as I'd go along that path.
I'm thinking network-wise.
As I've said before, I don't believe it's a good idea to add this stuff to the
client protocol. Inter-host communication is a different thing.
The API is pretty central, considering that both clients and the server
share most of it. It is that from which all else comes. Hence, IMHO,
pretty high priority.
I can understand your point. It may well be that fixing the API takes
precedence over much of the other changes.
I appreciate the compliment, but with hindsight there are a lot of
things that could have been done much better. In general, the whole
thing would benefit greatly from object orientation.
Given this and the desire to present a C API, there are few options.
You could write the library and server both in C++ and provide a C
wrapper API/ABI. However, wrapping gobject APIs for C++ (and python,
and perl, and Java, and C#, etc, etc) has already been done a gazillion
times before. I know there are tools to help automate C++ wrapping
(which gtkmm et al use.) The weight is all leaning in gobject's
direction.
I'd use C++ for the server because a) C++ rocks, 2) the server doesn't
need to provide an external C ABI, and d) C++ rocks, and that's what I'd
want to use :-)
Yes, personal preference, we meet again. :)
Well, whoever writes the code gets to decide I guess.
Juuso
On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari
wrote:
Why bother with a long-reaching workaround like that? I understood this
hypothetical "libeasyjack" to be something that would enable a program to be
a JACK (libjack) client without actually having to fulfill the requirement of
running with RT priority. But for our needs (setting connections, getting
connection info, etc.) it's simply backwards to stubbornly hold on to keeping
LASH a JACK client. There's a conceptually saner solution around the corner.
The goal of jackdbus has never been to shield applications from JACK's bugs,
and I regret that this conversation has revolved around that side effect for
so long. Jackdbus allows more flexible controlling of JACK settings in a
desktop environment, by desktop applications. Implementing this kind of
interface makes sense for more than one reason.
It's not about "adding a system-specific API layer to LASH", it's about
making
use of an API layer in LASH because it fits the purpose well.
On Wednesday 23 January 2008 23:21:21 Bob Ham
wrote:
No, I mean JACK or ALSA or raw1394 or whatever. I'm talking about
something like
lash_easy_jack_client_t *
lash_easy_jack_client(char *client_name,
char *input_port_names[],
char *output_port_names[],
jack_callback_t *cb);
In this case, there's no reason at all to have "lash_" in there. There's no reason to add a system-specific
API layer to LASH itself.
The abstraction could be done by a separate library entirely, eg
libeasyjack.
By "system-specific API layer" do you mean D-Bus? To me, it
seems like overengineering to design the LASH <-> client
protocol with networks in mind. The lashd daemon can use D-Bus to
communicate with clients, but that doesn't mean that several LASH daemons
running on different computers couldn't communicate session events and
data between eachother. The idea would be that all LASH <-> client
connections would be local, but one session could be composed of several
local LASH environments.
The problem here is you then have two communication protocols; one for
local D-Bus communication, and one for inter-host lashd communication.
They're going to be communicating much the same information; client
properties, port names, etc. To have two protocols would be unwieldy. But then
again, why should LASH even be concerned with the connections
between clients in the first place?
That's pretty much it's raison d'etre :-) See the following, and note
the file name:
http://teasel.6gnip.net/~rah/why-ladcca.png There's three different ideas that could be
surmised by "patch system
controller" (at least that I can think of.) There's something like
QJackCtl, which lets users adjust the settings of the patch system like
the sample rate, period size, etc (and we're talking about something
which does it on-the-fly, which doesn't exist yet.) Then there's LASH,
which monitors port connections and manages their automatic reconnection
when a session is restored. Then there's a patch bay, which allows the
user to adjust the connections while a session is active.
There are no inter-dependencies. They all provide distinct sets of
functionality and hence should be separate programs.
LASH is actually two separate sets of functionality in one system:
automatic port reconnection, and non-X11 session management. So, LASH
*does* leave "the other stuff" to a patch system; it leaves it to the
other functionality in itself :-)
It could be the case that the two sets of functionality in LASH can be
separated into different systems but off the top of my head I'm not sure
how inter-dependant they are. Specifically, I'm not sure whether
session management is completely independant of port reconnection, at
least in order to provide LASH functionality.
That reasoning seems solid, thanks for taking the time to explain.
I can imagine how the session could be comprised of:
- LASH which only manages client settings and connections,
- normal LASH clients, and
- a JACK controller, which is basically a normal LASH client.
And I can imagine how the session loading could happen approximately like
this:
- LASH launches the JACK controller app,
- the JACK controller app modifies JACK settings and possibly restarts JACK if
necessary,
- LASH launches the rest of the clients,
- LASH connects the ports between the clients.
I'm still not sure that this would be the most convenient solution for
everyone involved. Would it mean significantly more work for control
application/frontend coders? Would it be more confusing for the users? I'm
hoping that someone could comment on this.
Now imagine the above scenario, but imagine that the JACK controller app
doesn't get launched first. It will potentially wreck the session if it
restarts JACK after other clients have loaded. If controlling JACK settings
is done by one of the session clients, should that client be able to register
to LASH with a special flag which indicates that it should launch first?
Client priorities
Can you explain what you mean by this? Track
naming
And this? Guaranteed save directory availability
Does this simply mean that lashd will somehow make extra sure that the
directory exists, and that the client can write there? If so, it sounds
good. 1.0
Graded saves >
Networked audio
Handle sessions involving clients on different hosts who communicate
with each other over ports that require reconnecting. Eg, JACK clients
connected using firewire/netjack. > User
interface standard
Promote a standard to LASH clients in order to present a consistent user
interface. This would be like the GNOME HIG but audio-specific, eg,
specifying knob widget appearance and behaviour, recommending audio
widget toolkits, etc. Automatic client installation
This sounds an awful lot like stepping on the toes of packagers and
package managers. Unless you mean something completely different, of
course. And I would add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Why would managing an audio session demand that the connections be
certified and encrypted? Unless you're thinking network-wise (i.e.
sessions that span several networked computers). Rework API
Genericify patch-system specifics
Provide more useful event system (callbacks, etc)
I think that an API overhaul would be welcome, and especially using
callbacks would be an improvement. But it's not first priority (thought
not the lowest either). Rewrite client library in gobject
Rewrite server in C++
These sent a cold shiver down my spine... mostly because I don't know C++
and I'm unwilling to learn it right now. :)
I've looked at the LASH code, and I must say it looks very well written.
You've done a great job. I don't see any reason why the current codebase
would need an overhaul. How do you feel that a rewrite in C++ would help
LASH as a project? And about
GObject... well, why bother? I understood from your reply to
Nedko that you're not suggesting that GObject be enforced into the actual
LASH API, which is a relief. I fail to see any benefit in GObject-ifying
the internals, either.
Object orientation. Events and configs in the communication system
share a lot of functionality. The patch system-specific functionality
could and should be generalised. In the server, the JACK- and
ALSA-specific functionality provide almost identical interfaces. When
writing it, I actually cut-and-pasted a lot of the function prototypes,
just changing "jack" to "alsa". A lot of the function bodies were
also
identical algorithms, only using the different JACK- and ALSA-specific
interfaces for the data. There's a lot of code in a lot of places that
could be made a lot better using objects.
6:39 p.m.
On Sat, 2008-01-26 at 22:25 +0200, Juuso Alasuutari wrote:
You're treading on flammable ground here. I wouldn't want LASH to have the
slightest authority over what toolkits and/or widgets the clients are coded
with. And I don't see any reason why LASH should even care; LASH isn't a
plugin host. I should be able to include an Ncurses-based drum machine with
my session if I please.
The GNOME HIG isn't enforced. Nor, I believe, is there any way to
enforce it. It's simply a document to communicate to developers of
GNOME applications the expectations that any application has on it when
taking part in a GNOME desktop.
Similarly, the user interface standard for LASH would simply be a
document to communicate to developers of LASH clients the expectations,
in terms of user interface harmony, that any client has on it when
taking part in a LASH session.
What's meant is: if you load a session and it includes a client that
isn't installed on the system, then make it such that it is installed
and the session can be loaded. This is no small thing. There are a few
options:
1. Create a system which abstracts package management for different
distros
2. Try and create an automatic compilation environment, similar to
ports on Freebsd or portage on Gentoo (lol)
3. Use autopackage
From the client side, this would be very simple: the programmer just
provides a URL to some meta-information that describes the packages
needed for that LASH client. I think this is pretty doable now that
number 3 exists.
Yes, you are stepping on packagers' toes here -- heavily.
Why do you think packagers' toes are being stepped on? I can't see any
conflict between package developers and a LASH package installer.
I'm thinking network-wise.
As I've said before, I don't believe it's a good idea to add this stuff to
the
client protocol. Inter-host communication is a different thing.
There's an assumption here that lashd<->lashd and lashd<->client
protocols aren't the same thing. They would be communicating very
similar information. Having two protocols would be unwieldy.
Bob
--
Bob Ham <rah(a)bash.sh>
On Friday 25 January 2008 18:27:10 Bob Ham wrote:
> On Fri, 2008-01-25 at 14:04 +0200, Juuso Alasuutari wrote:
> > On Wednesday 23 January 2008 23:21:21 Bob Ham wrote:
And I can imagine how the session loading could happen
approximately like
this:
- LASH launches the JACK controller app,
- the JACK controller app modifies JACK settings and possibly restarts JACK if
necessary,
- LASH launches the rest of the clients,
- LASH connects the ports between the clients.
Now imagine the above scenario, but imagine that the
JACK controller app
doesn't get launched first. It will potentially wreck the session if it
restarts JACK after other clients have loaded. If controlling JACK settings
is done by one of the session clients, should that client be able to register
to LASH with a special flag which indicates that it should launch first?
This would be dealt with by client priorities (or dependencies.)
> User interface standard
Promote a standard to LASH clients in order to present a consistent user
interface. This would be like the GNOME HIG but audio-specific, eg,
specifying knob widget appearance and behaviour, recommending audio
widget toolkits, etc. Automatic
client installation
This sounds an awful lot like stepping on the toes of packagers and
package managers. Unless you mean something completely different, of
course. Abstracting package management for distros is an
insanely huge task
Note the phrase "this is no small thing" above.
, and not
likely to work in practice.
Possibly
Creating an automatic compilation environment --
well, I assume you're joking
Nope
because this would equal writing your own
source-based package manager
Yep
Using autopackage is out of the question,
because you simply can't fulfill the needs of all distros
Autopackage exists. It works. It doesn't seem to be out of the
question. The issue isn't fulfilling the needs of the distro but
fulfilling the needs of the user.
If a session manager would take on package management
like this -- which it
definitely _shouldn't_ in the first place
Why not?
-- it would have to work absolutely
_perfectly_ on _all_ possible distros. Either that, or nothing.
Why would reverting to normal, not-as-astonishingly-cool behaviour on
some distros be bad?
I wouldn't want autopackage messing around with my
box -- I want
packages installed the way they normally are with Source Mage.
Then don't use the automatic LASH client installer :-) Or you could
implement the distro-specific functionality for your distro. That would
allow you to have your packages installed the way they normally are with
Source Mage.
Considering how you've been defending LASH from
features that you deem outside
of its domain, I'm surprised that you would come up with this idea.
Session loading is within the domain of LASH.
And I would
add to that now:
0.6
Redesign client/server communication
Certificate based security/encryption
Why would managing an audio session demand that the connections be
certified and encrypted? Unless you're thinking network-wise (i.e.
sessions that span several networked computers).
23 Jan
23 Jan
10:54 p.m.
Bob Ham <rah(a)bash.sh> writes:
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
static void *
jack_watchdog_thread (void *arg)
{
jack_engine_t *engine = (jack_engine_t *) arg;
engine->watchdog_check = 0;
while (1) {
usleep (1000 * JACKD_WATCHDOG_TIMEOUT);
if (!engine->freewheeling && engine->watchdog_check == 0) {
jack_error ("jackd watchdog: timeout - killing jackd");
/* Kill the current client (guilt by association). */
if (engine->current_client) {
kill (engine->current_client->
control->pid, SIGKILL);
}
/* kill our process group, try to get a dump */
kill (-getpgrp(), SIGABRT);
/*NOTREACHED*/
exit (1);
}
engine->watchdog_check = 0;
}
}
Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it? It seems that what you want is Patchage++.
Unfortunately, LASH isn't
that and I think you're likely to run into problems if you try and turn
it into that.
JACK *will* be improved (at least its dbus-interface) to fix this issue.
Just out of curiousity, how?
I'm not completely sure yet, but even the jack code posted above
shows that jack server engine knows what is the pid of each client.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
* lash should be able to manage not lashified apps at
least to extent
of launching them and connecting their ports.
The problem here is that there's no way to know which ports belong to
the app.
24 Jan
24 Jan
4:34 a.m.
On Thu, 2008-01-24 at 04:54 +0200, Nedko Arnaudov wrote:
Bob Ham <rah(a)bash.sh> writes:
I'm not sure what the point of posting this function is. It doesn't
contradict anything I said.
Bob
--
Bob Ham <rah(a)bash.sh>
On Tue, 2008-01-22 at 21:11 +0200, Nedko Arnaudov
wrote:
static void *
jack_watchdog_thread (void *arg)
{ Bob Ham <rah(a)bash.sh> writes:
A good example. What does the watchdog do, exactly? It isn't a
frontend. I doesn't try to work around jackd's crashing. It just
ensures that if something bad does happen, the computer as a whole isn't
brought down. This is massively different from what you're proposing.
To try and work around a crash in jackd and present a system to the user
where crashes make no difference is to invite more problems. If you
can't get jackd to stay up, what makes you think you can get your new
system to stay up? More generally, LASH isn't a frontend for
JACK.
What about the jack watchdog? What does get killed by it?
22 Jan
22 Jan
3:32 p.m.
Bob Ham <rah(a)bash.sh> writes:
Oh, sure, LASH should support network multimachine sessions but it has
nothing to do with X11? I find this funny :)
You want to use firewire for what exactly?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
* lash does
not preserve X11 related properties of apps, like on what
screen (dual-head) they were.
Nor should it. The X11 system is nothing whatsoever to do with LASH,
intentionally. From LASH's perspective, anything to do with X11 is
entirely the client's responsibility. Adding X11-specific functionality
into the protocol, the server and the library should not happen.
Providing convenience functions to clients is a solution, eg
lash_x11_get_state_configs() and that returns a set of LASH configs
containing the state of the X11 system. And, of course, functions to
restore the state. But it should be separate from LASH itself, eg, in
some liblash-x11.
* Supporting connections for things other than
JACK (read ALSA seq)
LASH already does support ALSA seq. Future support would be connecting
via netjack, or firewire, or $next_big_thing.
6:22 p.m.
On Tue, 2008-01-22 at 21:32 +0200, Nedko Arnaudov wrote:
Bob Ham <rah(a)bash.sh> writes:
Oh, sure, LASH should support network multimachine sessions but it has
nothing to do with X11? I find this funny :)
Why do you find it funny?
* lash
does not preserve X11 related properties of apps, like on what
screen (dual-head) they were.
Nor should it. The X11 system is nothing whatsoever to do with LASH,
intentionally. From LASH's perspective, anything to do with X11 is
entirely the client's responsibility. Adding X11-specific functionality
into the protocol, the server and the library should not happen.
Providing convenience functions to clients is a solution, eg
lash_x11_get_state_configs() and that returns a set of LASH configs
containing the state of the X11 system. And, of course, functions to
restore the state. But it should be separate from LASH itself, eg, in
some liblash-x11.
* Supporting connections for things other than
JACK (read ALSA seq)
LASH already does support ALSA seq. Future support would be connecting
via netjack, or firewire, or $next_big_thing. You want to use firewire for what exactly?
Taking audio from JACK client A on host 1 to JACK client B on host 2.
Bob
--
Bob Ham <rah(a)bash.sh>
23 Jan
23 Jan
12:19 p.m.
On Tue, Jan 22, 2008 at 06:23:32PM +0000, Bob Ham wrote:
More generally, LASH isn't a frontend for JACK.
LASH (when controlling
JACK clients) relies on services that JACK provides. This isn't a bad
thing. The focus shouldn't be on taking control of jackd through LASH
but in making jackd more server-like, such that you don't need another
server just to control it.
Having plans for some audio session managament system I've been
lurking on this thread.
- LASH, or whatever session manager, will have to give
special status to JACK, it can't be just another client.
In my case, it shouldn't even try to run, stop or configure
JACK as some of the things JACK will be used for will be
and should remain outside the control of the session manager.
- The most practical setup I can imagine (for my use, YMMV)
is something that integrates the functionalities of e.g.
patchage and a session manager.
- It would have to support saving/loading a complete setup
much in the same way as you would load/save a patch in
a soft synth, but without ever touching those things that
it didn't start itself (unless told to).
- Managing JACK connections can be hard, partly because most
clients behave in a way that isn't really supportive.
Autoconnection can easily lead to circular dependencies,
it blindly assumes that you 'own' the connection and should
be allowed to control it while the other side doesn't, and
for these reasons alone it's a bad idea.
Even worse, those clients that do autoconnect from the their
own session data will fail if the 'other side' is not yet
running (or has not yet created its ports) and they will
typically not try again later. So you end up with a result
that is generally unpredictable unless carefully controlled
in terms of order of starting, and even timing.
Ideally all clients should support a mode in which they
will not try to make any external connections, and only
rely on the session manager or user to do this. It will
be a long time before this is generally supported. I'd
like to see some way to prevent clients to autoconnect,
if necessary by JACK only accepting external connection
requests from a single configurable source.
- Ideally such a system should be able to distribute clients
it starts over different workspaces. The same ones they
were on when the configuration was saved. Probably hard.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
1:30 p.m.
On Wednesday 23 January 2008 17:58:05 Fons Adriaensen wrote:
Having plans for some audio session managament system
I've been
lurking on this thread.
- LASH, or whatever session manager, will have to give
special status to JACK, it can't be just another client.
In my case, it shouldn't even try to run, stop or configure
JACK as some of the things JACK will be used for will be
and should remain outside the control of the session manager.
Well, JACK never was a LASH client, and it's always had special status in LASH
(lashd has a dedicated JACK manager thread). How LASH currently works is that
lashd is actually a JACK client, which I don't think is an optimal solution
(at least on a conceptual level).
In my opinion, the concept of "audio session" should _optionally_ include JACK
server settings. The user should be able to save and load his/her preferred
JACK settings along with a session (which would sometimes mean that the
session handler app would kickstart jackd with the new settings). And equally
important would be that the user could explicitly forbid the session manager
from altering any JACK settings.
- The most practical setup I can imagine (for my use,
YMMV)
is something that integrates the functionalities of e.g.
patchage and a session manager.
I agree, and I am hoping that in the future Patchage and/or QJackCtl would be
able to act as such a control application. But this doesn't mean that the
control app should have to be a frontend to some all-in-one super daemon
(like Bob Ham seems to interpret the discussion -- please correct me if I'm
wrong though).
In my opinion, the control application should control both JACK and LASH
through abstracted D-Bus interfaces. It should neither be a JACK client like
QJackCtl nor a LASH client like lash_panel.
- It would have to support saving/loading a complete
setup
much in the same way as you would load/save a patch in
a soft synth, but without ever touching those things that
it didn't start itself (unless told to).
Agreed. I believe this is the purpose of LASH in the first place.
- Managing JACK connections can be hard, partly
because most
clients behave in a way that isn't really supportive.
Autoconnection can easily lead to circular dependencies,
it blindly assumes that you 'own' the connection and should
be allowed to control it while the other side doesn't, and
for these reasons alone it's a bad idea.
Even worse, those clients that do autoconnect from the their
own session data will fail if the 'other side' is not yet
running (or has not yet created its ports) and they will
typically not try again later. So you end up with a result
that is generally unpredictable unless carefully controlled
in terms of order of starting, and even timing.
This is something I've been thinking also, I'm glad I'm not the only one. IMHO
the LASH API should be extended to make it mandatory for clients to report
when they have completed the requested operation. This would apply for
start-up and settings load/save, so that the LASH server would know when it's
safe to connect the clients' ports, etc.
Also, the session data should include the starting order of clients, as well
as a way to control "dependencies". Like so:
<start id="sampler">/usr/bin/sampler</start>
<start id="synth">/usr/bin/synth</start>
<start wait_for="sampler,synth"
id="sequencer">/usr/bin/sequencer</start>
<start wait_for_all="yes" id="daw">/usr/bin/daw</start>
This would result in the sampler and the synth being started simultaneously,
the sequencer after those two have loaded, and then finally the DAW.
Ideally all clients should support a mode in which
they
will not try to make any external connections, and only
rely on the session manager or user to do this. It will
be a long time before this is generally supported. I'd
like to see some way to prevent clients to autoconnect,
if necessary by JACK only accepting external connection
requests from a single configurable source.
I also think that when in "LASH mode", clients should refrain from making
external connections. But instead of adding new features to JACK I think the
clients should simply behave. LASH as a whole is very dependent on clients
doing what they're expected to; if we start monitoring and enforcing correct
client behavior then there will be no end to that.
- Ideally such a system should be able to distribute
clients
it starts over different workspaces. The same ones they
were on when the configuration was saved. Probably hard.
This is kind of what Nedko suggested about saving some X11 settings, no? This
is indeed probably beyond the scope of any current plans.
Juuso
3:52 p.m.
On Wed, 2008-01-23 at 19:30 +0200, Juuso Alasuutari wrote:
On Wednesday 23 January 2008 17:58:05 Fons Adriaensen
wrote:
> Having plans for some audio session managament system I've been
> lurking on this thread.
>
> - LASH, or whatever session manager, will have to give
> special status to JACK, it can't be just another client.
> In my case, it shouldn't even try to run, stop or configure
> JACK as some of the things JACK will be used for will be
> and should remain outside the control of the session manager.
In my opinion, the concept of "audio
session" should _optionally_ include JACK
server settings. The user should be able to save and load his/her preferred
JACK settings along with a session
This can be done without any specific support in LASH. You would only
need a JACK-settings LASH client that saves settings with the session
and then loads them again when it's restored. Of course, "loads them
again" would be non-trivial at present.
What's really needed to support this kind of operation is a more dynamic
jackd that can have settings changed arbitrarily and, where possible,
without damage to the client graph. The driver switching patch (from a
long time ago) was intended to be a movement in this direction.
Bob
--
Bob Ham <rah(a)bash.sh>
4:58 p.m.
On Jan 23, 2008 8:51 PM, Bob Ham <rah(a)bash.sh> wrote:
"loading again" is trivial with jackdbus. Saving will be when jackdbus
has some sort of preset management (it is planned)
In my opinion,
the concept of "audio session" should _optionally_ include JACK
server settings. The user should be able to save and load his/her preferred
JACK settings along with a session
This can be done without any specific support in LASH. You would only
need a JACK-settings LASH client that saves settings with the session
and then loads them again when it's restored. Of course, "loads them
again" would be non-trivial at present. What's really needed to support this kind of
operation is a more dynamic
jackd that can have settings changed arbitrarily and, where possible,
without damage to the client graph. The driver switching patch (from a
long time ago) was intended to be a movement in this direction.
I imagine this is a lot tougher, and I'm not sure there's any urgency
in doing that.
Now to add my two cents to the debate, I would also say that having
some gigantic daemon on top of everything is certainly not a good
idea. But having a control application that can handle jack and lash
would be very convenient IMHO...
Maybe my pyjackctl thingy needs to be renamed something else to also
integrate lash support when some dbus interface is also available to
control it :-)
__________________
Marc-Olivier Barre,
MarcO'Chapeau.
11:50 p.m.
Fons Adriaensen <fons(a)kokkinizita.net> writes:
On Tue, Jan 22, 2008 at 06:23:32PM +0000, Bob Ham
wrote:
I do agree that JACK should have special status to JACK. And we can
probably avoid starting/stopping/reconfiguring JACK, but I think we will
make things easier for public if it does.
Btw, Fons, have you tried jackdbus patches / pyjackctl suite? If so,
what you think about the initiative?
http://sharesource.org/project/jack
http://marcochapeau.org/node/4
http://nedko.arnaudov.name/wiki/moin.cgi/JackDesktopInitiative
More generally, LASH isn't a frontend for
JACK. LASH (when controlling
JACK clients) relies on services that JACK provides. This isn't a bad
thing. The focus shouldn't be on taking control of jackd through LASH
but in making jackd more server-like, such that you don't need another
server just to control it.
Having plans for some audio session managament system I've been
lurking on this thread.
- LASH, or whatever session manager, will have to give
special status to JACK, it can't be just another client.
In my case, it shouldn't even try to run, stop or configure
JACK as some of the things JACK will be used for will be
and should remain outside the control of the session manager. - The most practical setup I can imagine (for my use,
YMMV)
is something that integrates the functionalities of e.g.
patchage and a session manager.
I agree that this will be the most practical setup for most users. And
thus is very important to be taken into account. OTOH, I'm not generally
against separate server (control) and client (normal app) interfaces. As
far as both can be used in a single app. Dave, can you share your thougs
on this please?
- It would have to support saving/loading a complete
setup
much in the same way as you would load/save a patch in
a soft synth, but without ever touching those things that
it didn't start itself (unless told to).
I do agree.
- Managing JACK connections can be hard, partly
because most
clients behave in a way that isn't really supportive.
Autoconnection can easily lead to circular dependencies,
it blindly assumes that you 'own' the connection and should
be allowed to control it while the other side doesn't, and
for these reasons alone it's a bad idea.
Even worse, those clients that do autoconnect from the their
own session data will fail if the 'other side' is not yet
running (or has not yet created its ports) and they will
typically not try again later. So you end up with a result
that is generally unpredictable unless carefully controlled
in terms of order of starting, and even timing.
Ideally all clients should support a mode in which they
will not try to make any external connections, and only
rely on the session manager or user to do this. It will
be a long time before this is generally supported. I'd
like to see some way to prevent clients to autoconnect,
if necessary by JACK only accepting external connection
requests from a single configurable source.
Kasper Sandberg made a patch (jack_port_connection_acl-v9.diff) that
does add acl to manage who can do connections. I'd like to put it as
part of jackpatches, converted to use the real configuration file. And
of course I hope both jackdbus and connect acl functionality will get
into jack trunk at some point.
- Ideally such a system should be able to distribute
clients
it starts over different workspaces. The same ones they
were on when the configuration was saved. Probably hard.
Can you please explain what you mean by workspaces? The ones a modern
X11 Window Manager typically provides?
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
24 Jan
24 Jan
8:16 a.m.
On Thu, Jan 24, 2008 at 05:50:35AM +0200, Nedko Arnaudov wrote:
Can you please explain what you mean by workspaces?
The ones a modern
X11 Window Manager typically provides?
Yes. The typical session I'm using for some of my work here
would use 4 or 5 workspaces. It's quite impossible to fit
all of it on a single screen, not even on the super nice
Apple 30" cinema display I have on one of the machines.
It also involves running things on headless networked
computers (currently via ssh) and configuring external
devices, an RME MADI Bridge and up to five ADI648.
These are remotable by MIDI.
Ciao,
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.
25 Jan
25 Jan
8:13 a.m.
On Thursday 24 January 2008 14:01:17 Fons Adriaensen wrote:
On Thu, Jan 24, 2008 at 05:50:35AM +0200, Nedko
Arnaudov wrote:
Just out of curiosity: Do you know how a program can query for X11 programs'
window positions and workspaces? Just point me to an API doc or something if
you're not feeling talkative. :)
Juuso
Can you please explain what you mean by
workspaces? The ones a modern
X11 Window Manager typically provides?
Yes. The typical session I'm using for some of my work here
would use 4 or 5 workspaces. It's quite impossible to fit
all of it on a single screen, not even on the super nice
Apple 30" cinema display I have on one of the machines.
It also involves running things on headless networked
computers (currently via ssh) and configuring external
devices, an RME MADI Bridge and up to five ADI648.
These are remotable by MIDI.
6093
days inactive
6098
days old
linux-audio-dev@lists.linuxaudio.org
42 comments
7 participants
participants (7)
-
Bob Ham -
Fons Adriaensen -
Juuso Alasuutari -
Krzysztof Foltman -
Marc-Olivier Barre -
Nedko Arnaudov -
Paul Davis