Re: [Jack-Devel] [LAC08] The Future of Jack

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

Re: [Jack-Devel] [LAC08] The Future of Jack

Stéphane Letz
Thanks a lot Sampo for this clear and detailed report.


> Greetings earthlings,
>
>
> As you might have heard, there was a meeting titled "The Future of  
> Jack" at
> LAC 2008. I took the notes of that meeting and have finally been  
> able to
> write them down in an semi-understandable form.
>
> The following attended the meeting:
> Fons Adriaensen         (ambisonics/aeolus/jconv/tetraproc/etc.etc.)
> Dmitry Baikov           (jackd)
> Marc-Olivier Barre      (linuxaudio.org)
> Rui Nuno Capela         (qjackctl/etc.)
> Paul Davis              (ardour/jackd)
> Robin Gareus            (linuxaudio.org)
> Stéphane Letz           (jackdmp)
> Pieter Palmers          (ffado)
> Sampo Savolainen        (ardour)
> Richard Spindler        (open movie editor / upcoming open source  
> video
> editing software)
> Daniel Wagner           (ffado)
> .. and a few others whose names I am unable to remember. Sorry about  
> that.
>
>
> The point of the meeting was to figure out what to do next with  
> jack. The
> two main questions were: When do we get 1.0 out and what do we want  
> to do
> with 2.0? I think we got quite good results at the meeting, but feel  
> free to
> comment and criticize the content. Also please correct the  
> information in
> this post if I have something down wrong.
>
> I am sure there are people who would have wanted to be in the  
> meeting and
> are now feeling left out. Please don't take the matters presented by  
> these
> notes as an attempt to usurp you out of power - things can and will  
> always
> be discussed again. But I also ask you to recognize that the meeting  
> was
> open to everyone who were able to make it and the people who did are
> relative heavy-weights in the development of Jack, especially  
> Stéphane. Also
> note that everyone was in agreement over the matters discussed,  
> except for
> the control protocol (more on that later).
>
> Marc did a voice recording of the talks (with permission from  
> everyone) and
> I hope Marc gets it on the web soon so you can listen to the  
> discussion on
> these matters. The recording contains much more argumentation over the
> matters than what I have written down here.
>
>
> The big 1.0:
> ^^^^^^^^^^^^
>
> The first order of business was to figure what we still needed to  
> release
> 1.0. We have been very close to a release for a few years now, and  
> the point
> was to gather a list of what is still needed.
>
> Include NetJack
> ---------------
> Because so many people want to try it out, it would be a good idea to
> include NetJack with jackd. No further integration is planned  
> though, the
> current netjack would be bundled in as-it-is. Documentation wise we  
> might
> want to rename the slave/master nodes. This is to avoid confusion to  
> what
> each node does. One suggestion was compute-node and sound-node.
>
> Stéphane Letz has already started work on this.
>
> Wait/signal model
> -----------------
> This is what Stéphane Letz described more thoroughly in his patch  
> sent to
> jackit-devel on wednesday.
>
>
> Fix the evil crasher
> --------------------
> Current SVN jackd does not behave right and/or crashes with  
> pathological
> clients when more than one client is using jackd. There was some  
> progress
> made with this issue on sunday night but no real fix was found yet.  
> You can
> draw your own conclusions as to why no fix was found:
> http://www.rncbc.org/lac2008/dscn1867.jpg
>

I would suggest another point here, that was discussed a bit after the  
meeting. Right now switching between jackd and jackdmp (for testing  
purpose or whatever) is a bit of pain. Some month or years ago, a  
scheme was proposed to smooth this transition by allowing the jackd  
and jackdmp versions be installed together and having a special  
"libjackwrapper.so" library be able to dynamically switch between the  
2, and this improve "user experience" ((-: . So the user would do:

jackd -R -d alsa... and then all launched applications would see the  
jackd server running and connect to it or

jackdmp -R -d alsa.. and then all launched applications would see the  
jackdmp server running and connect to it.

In case the automatic server launch has to be used (client starting  
the server), then this libjackwrapper.so would have to choose one of  
jackd or jackdmp and this could simply be the one kept in the jackdrc  
configuration file.

Technically this would require:

- changing a bit jackd source tree compilation so that a libserver.so  
shared library would be defined containing the server side of the  
code. Then jackd and all backend would be linked against this  
libserver.so lib. (right now jackd has a link to libjackd.so which is  
a problem..)

- defining this libjackwrapper.so layer in jackdmp source tree (almost  
done) and have the jackdmp installation process establish this  
libjack.so ==>  libjackwrapper.so soft link.

>
>
> What do do next, in other words 2.0:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> There was a common understanding that jackdmp should become the base  
> for
> 2.0. This is because of its cleaner & more future-proof design and  
> threaded
> signal processing. A very important factor for the choice is also  
> that the
> development of jackdmp is much more active than the development of  
> jackd.
>
> Jack 2.0 should be only about the technical side of things, but also  
> about
> user experience. User experience in this context means focus on  
> making jack
> easier to use and configure. Especially to make the first time  
> experience
> better.
>
> The following list is not meant as a final or exhaustive list of  
> things to
> include. It is meant as a solid backbone of goals and a list of  
> agreed upon
> ways of reaching those goals.
>
>
> Startup & configuration
> -----------------------
>
> Jack should be able to check the basic requirements for proper use  
> and tell
> the user what is the problem and how should one go about fixing  
> them.  These
> requirements are: realtime priority rights, memlock size (please add  
> more if
> you can think of them).
>
> Also we probably should warn users about running jackd and all audio
> applications as root. Although better distro support (realtime  
> requirements
> enabled by default) might cure the actual cause for running jackd as  
> root.
>
>
> There should be a catalog of sensible defaults for certain  
> soundcards (for
> example usb devices, intel hda). Jack should also be able to auto-
> sense
> working parameters when no configuration is given. The auto-sense
> functionality should be part of backend modules.
>
>
> Currently there is no good way of providing error messages to jack  
> control
> applications like qjackctl. Because of this, the usability of control
> applications in error conditions (for example when jackd is unable  
> to start)
> is bad because it can't help the user to fix the issue.
>
>
> There should be a way of storing and retrieving multiple jackd
> configurations provided jack. Either via libjack or some other  
> mechanism
> provided by jack. This helps different control applications share
> configurations. Unique ID's for each soundcard per backend are  
> needed to be
> able to map configurations to specific devices.
>
>
> Netjack
> -------
> We might want to look into open standards for audio transmission  
> over the
> network to make jack 2.0 compatible with other network audio  
> software /
> hardware. An example of a suitable protocol is Wormhole, but it  
> seems it has
> been scrapped and all development halted.
>
> The ideal protocol would work over both LANs and WANs, it would do  
> auto
> discovery and clients would be symmetric instead of having to start  
> one
> client as a master and others as slaves.
>
> Jack trip seems like an interesting project and might provide  
> information
> and/or experience and/or code to help reach these goals.
>
>
> Desktop integration
> -------------------
> PulseAudio seems to be the way audio for "normal" applications is  
> going. We
> should not take this as a threat but as a good thing. Pulse is not  
> trying to
> replace jack, quite the opposite: Pulse has a jack backend which  
> gives the
> possibility of using jack applications and dekstop applications in  
> the same
> audio graph.
>
> What we need to do is make sure pulse and jack work good together.  
> The most
> important part is to allow a smooth transition from the normal pulse  
> backend
> to a jack backend and back. Storing complex configuration  
> information in the
> server should help with this.
>
> Autoconnecting applications when switching over is also something we  
> need to
> figure out. Hopefully pulse would tell jack which pieces of software  
> were
> connected to the soundcard but I may have my heads too high up in  
> the clouds.
>
>
> We discussed a potential server control protocol but the thoughts  
> about it
> are still too scattered to present here. There was no agreement on  
> what
> should be done, mostly because it wasn't clear what was proposed to  
> be done.
> I'll throw the ball over to Nedko, Marc & Juuso, but I will give a  
> short
> description of one problem which could be solved by this:
>
> Having applications autostart jackd is great, but the current  
> autostart
> model is problematic: There is no real control as to what  
> configuration of
> jackd should use and there is no way to get error messages from the
> autostarted process to a control application like qjackctl. I also  
> fear
> (haven't tested this recently) that the process is tied in with the  
> original
> client in a way which would tie the life spans of the two processes  
> together.
>
> While there has been talk of using D-Bus for this, we must remember  
> that
> jack is multi-platform and there is no D-Bus available on OS X or on
> Windows. So everything has to be de-coupled from the actual  
> implementation.
> Also, the use of the protocol should be designed to be optional so  
> that
> jackd will work without it.
>
>
>
> Internal design
> ---------------
> We want to allow multiple backends. This is to allow the use of  
> netjack
> together with a soundcard or just to make it easier to set up  
> multiple sound
> interfaces which are synced together. Backends should also be able  
> to appear
> and vanish from jack just like normal clients.
>
> To allow for this to happen jack needs to have a "time source". The  
> time
> source is what drives processing. Jack provides a single time source  
> to its'
> clients and all active backends. The time source in jack will be  
> driven by a
> selected time source provided by a backend.
>
> What this could allow us to do is to run an alsa and ffado backend  
> at the
> same time. The alsa backend would drive the jack clock source. The  
> jack
> clock source would then drive the clients and the ffado backend  
> which can
> then soft-sync the firewire device.
>
> Each backend would offers jack 0..x input ports, 0..y output ports  
> and 0..z
> time sources.
>
> To eliminate some corner cases it could be helpful to have a  
> "fallback"
> backend which provides 0 inputs, 0 outputs and 1 software time  
> source. This
> would be so that if all other backends fail, jack would have a  
> backend to
> get timings from. The fallback backend could potentially handle  
> freewheeling
> mode by hyping up the software clock.
>
>
> Client programming and API
> --------------------------
> People working on video editing software want to use jack for  
> transport
> control and some audio work. They did request however that jack  
> would supply
> them with supply clients with some extra information. Namely video  
> frame
> time in "audio frames / video frames" described with two integers,  
> drop
> frame information etc. We should ask for a complete list as their  
> and our
> work proceeds.
>
> There has been some interest in having a server library API which  
> would make
> it possible to link the server into an application. This was deemed  
> a good
> and useful idea. Patches are welcome - I think someone mentioned  
> having this
> working already.

This is already done in jackdmp tree where 2 shared libraries are  
defined: libjack(mp).so contains the client side of the code and  
libjackserver(mp).so contains the server side of the code, both  
libraries expose the entire jack API. jackdmp and backend link to  
libjackserver(mp).so. Client applications can either link the normal  
way to libjack(mp).so or possibly to libjackserver(mp).so. In the  
second case and using the "automatic start server" feature,  
jack_client_open will simply start the server inside the client  
process space.

>
>
> We also need to make sure client developers understand the  
> ramifications of
> appearing and disappearing backends. This is mostly a documentation  
> issue
> but automated testing frameworks might help if someone feels like  
> coming up
> with something like that.
>
>
> Things not discussed
> --------------------
> The discussion took quite a while and sadly we were not able to  
> discuss
> everything planned. I found two issues in my notes which were left  
> out. They
> were:
>
> Richard Spindler pointed out that it would be nice to have fast  
> forward /
> scrubbing ability with jack transport.
>
> Pieter Palmers mentioned generalizing the MIDI implementation to  
> something
> that would handle events in general.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] [LAC08] The Future of Jack

Sébastien THOMAS-2
Many thanks for this.
Could we add something here, like : 

making Jackd work on something else than Linux ? 

Ok, it is working on OSX and windows... but could it be compatible with Solaris (10) ?

I made 2 patches last year but still had troubles. I finaly went on a Linux box, having many other down side. 
I can't understand jackd is not stable on Solaris while using the dummy driver... or maybe it's just me ?

No need to talk about jackdmp, which is not working at all on Solaris :)


Le 7 mars 08 à 10:28, Stéphane Letz a écrit :

Thanks a lot Sampo for this clear and detailed report.


Greetings earthlings,


As you might have heard, there was a meeting titled "The Future of  
Jack" at
LAC 2008. I took the notes of that meeting and have finally been  
able to
write them down in an semi-understandable form.

The following attended the meeting:
Fons Adriaensen         (ambisonics/aeolus/jconv/tetraproc/etc.etc.)
Dmitry Baikov           (jackd)
Marc-Olivier Barre      (linuxaudio.org)
Rui Nuno Capela         (qjackctl/etc.)
Paul Davis              (ardour/jackd)
Robin Gareus            (linuxaudio.org)
Stéphane Letz           (jackdmp)
Pieter Palmers          (ffado)
Sampo Savolainen        (ardour)
Richard Spindler        (open movie editor / upcoming open source  
video
editing software)
Daniel Wagner           (ffado)
.. and a few others whose names I am unable to remember. Sorry about  
that.


The point of the meeting was to figure out what to do next with  
jack. The
two main questions were: When do we get 1.0 out and what do we want  
to do
with 2.0? I think we got quite good results at the meeting, but feel  
free to
comment and criticize the content. Also please correct the  
information in
this post if I have something down wrong.

I am sure there are people who would have wanted to be in the  
meeting and
are now feeling left out. Please don't take the matters presented by  
these
notes as an attempt to usurp you out of power - things can and will  
always
be discussed again. But I also ask you to recognize that the meeting  
was
open to everyone who were able to make it and the people who did are
relative heavy-weights in the development of Jack, especially  
Stéphane. Also
note that everyone was in agreement over the matters discussed,  
except for
the control protocol (more on that later).

Marc did a voice recording of the talks (with permission from  
everyone) and
I hope Marc gets it on the web soon so you can listen to the  
discussion on
these matters. The recording contains much more argumentation over the
matters than what I have written down here.


The big 1.0:
^^^^^^^^^^^^

The first order of business was to figure what we still needed to  
release
1.0. We have been very close to a release for a few years now, and  
the point
was to gather a list of what is still needed.

Include NetJack
---------------
Because so many people want to try it out, it would be a good idea to
include NetJack with jackd. No further integration is planned  
though, the
current netjack would be bundled in as-it-is. Documentation wise we  
might
want to rename the slave/master nodes. This is to avoid confusion to  
what
each node does. One suggestion was compute-node and sound-node.

Stéphane Letz has already started work on this.

Wait/signal model
-----------------
This is what Stéphane Letz described more thoroughly in his patch  
sent to
jackit-devel on wednesday.


Fix the evil crasher
--------------------
Current SVN jackd does not behave right and/or crashes with  
pathological
clients when more than one client is using jackd. There was some  
progress
made with this issue on sunday night but no real fix was found yet.  
You can
draw your own conclusions as to why no fix was found:


I would suggest another point here, that was discussed a bit after the  
meeting. Right now switching between jackd and jackdmp (for testing  
purpose or whatever) is a bit of pain. Some month or years ago, a  
scheme was proposed to smooth this transition by allowing the jackd  
and jackdmp versions be installed together and having a special  
"libjackwrapper.so" library be able to dynamically switch between the  
2, and this improve "user experience" ((-: . So the user would do:

jackd -R -d alsa... and then all launched applications would see the  
jackd server running and connect to it or

jackdmp -R -d alsa.. and then all launched applications would see the  
jackdmp server running and connect to it.

In case the automatic server launch has to be used (client starting  
the server), then this libjackwrapper.so would have to choose one of  
jackd or jackdmp and this could simply be the one kept in the jackdrc  
configuration file.

Technically this would require:

- changing a bit jackd source tree compilation so that a libserver.so  
shared library would be defined containing the server side of the  
code. Then jackd and all backend would be linked against this  
libserver.so lib. (right now jackd has a link to libjackd.so which is  
a problem..)

- defining this libjackwrapper.so layer in jackdmp source tree (almost  
done) and have the jackdmp installation process establish this  
libjack.so ==>  libjackwrapper.so soft link.


What do do next, in other words 2.0:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There was a common understanding that jackdmp should become the base  
for
2.0. This is because of its cleaner & more future-proof design and  
threaded
signal processing. A very important factor for the choice is also  
that the
development of jackdmp is much more active than the development of  
jackd.

Jack 2.0 should be only about the technical side of things, but also  
about
user experience. User experience in this context means focus on  
making jack
easier to use and configure. Especially to make the first time  
experience
better.

The following list is not meant as a final or exhaustive list of  
things to
include. It is meant as a solid backbone of goals and a list of  
agreed upon
ways of reaching those goals.


Startup & configuration
-----------------------

Jack should be able to check the basic requirements for proper use  
and tell
the user what is the problem and how should one go about fixing  
them.  These
requirements are: realtime priority rights, memlock size (please add  
more if
you can think of them).

Also we probably should warn users about running jackd and all audio
applications as root. Although better distro support (realtime  
requirements
enabled by default) might cure the actual cause for running jackd as  
root.


There should be a catalog of sensible defaults for certain  
soundcards (for
example usb devices, intel hda). Jack should also be able to auto- 
sense
working parameters when no configuration is given. The auto-sense
functionality should be part of backend modules.


Currently there is no good way of providing error messages to jack  
control
applications like qjackctl. Because of this, the usability of control
applications in error conditions (for example when jackd is unable  
to start)
is bad because it can't help the user to fix the issue.


There should be a way of storing and retrieving multiple jackd
configurations provided jack. Either via libjack or some other  
mechanism
provided by jack. This helps different control applications share
configurations. Unique ID's for each soundcard per backend are  
needed to be
able to map configurations to specific devices.


Netjack
-------
We might want to look into open standards for audio transmission  
over the
network to make jack 2.0 compatible with other network audio  
software /
hardware. An example of a suitable protocol is Wormhole, but it  
seems it has
been scrapped and all development halted.

The ideal protocol would work over both LANs and WANs, it would do  
auto
discovery and clients would be symmetric instead of having to start  
one
client as a master and others as slaves.

Jack trip seems like an interesting project and might provide  
information
and/or experience and/or code to help reach these goals.


Desktop integration
-------------------
PulseAudio seems to be the way audio for "normal" applications is  
going. We
should not take this as a threat but as a good thing. Pulse is not  
trying to
replace jack, quite the opposite: Pulse has a jack backend which  
gives the
possibility of using jack applications and dekstop applications in  
the same
audio graph.

What we need to do is make sure pulse and jack work good together.  
The most
important part is to allow a smooth transition from the normal pulse  
backend
to a jack backend and back. Storing complex configuration  
information in the
server should help with this.

Autoconnecting applications when switching over is also something we  
need to
figure out. Hopefully pulse would tell jack which pieces of software  
were
connected to the soundcard but I may have my heads too high up in  
the clouds.


We discussed a potential server control protocol but the thoughts  
about it
are still too scattered to present here. There was no agreement on  
what
should be done, mostly because it wasn't clear what was proposed to  
be done.
I'll throw the ball over to Nedko, Marc & Juuso, but I will give a  
short
description of one problem which could be solved by this:

Having applications autostart jackd is great, but the current  
autostart
model is problematic: There is no real control as to what  
configuration of
jackd should use and there is no way to get error messages from the
autostarted process to a control application like qjackctl. I also  
fear
(haven't tested this recently) that the process is tied in with the  
original
client in a way which would tie the life spans of the two processes  
together.

While there has been talk of using D-Bus for this, we must remember  
that
jack is multi-platform and there is no D-Bus available on OS X or on
Windows. So everything has to be de-coupled from the actual  
implementation.
Also, the use of the protocol should be designed to be optional so  
that
jackd will work without it.



Internal design
---------------
We want to allow multiple backends. This is to allow the use of  
netjack
together with a soundcard or just to make it easier to set up  
multiple sound
interfaces which are synced together. Backends should also be able  
to appear
and vanish from jack just like normal clients.

To allow for this to happen jack needs to have a "time source". The  
time
source is what drives processing. Jack provides a single time source  
to its'
clients and all active backends. The time source in jack will be  
driven by a
selected time source provided by a backend.

What this could allow us to do is to run an alsa and ffado backend  
at the
same time. The alsa backend would drive the jack clock source. The  
jack
clock source would then drive the clients and the ffado backend  
which can
then soft-sync the firewire device.

Each backend would offers jack 0..x input ports, 0..y output ports  
and 0..z
time sources.

To eliminate some corner cases it could be helpful to have a  
"fallback"
backend which provides 0 inputs, 0 outputs and 1 software time  
source. This
would be so that if all other backends fail, jack would have a  
backend to
get timings from. The fallback backend could potentially handle  
freewheeling
mode by hyping up the software clock.


Client programming and API
--------------------------
People working on video editing software want to use jack for  
transport
control and some audio work. They did request however that jack  
would supply
them with supply clients with some extra information. Namely video  
frame
time in "audio frames / video frames" described with two integers,  
drop
frame information etc. We should ask for a complete list as their  
and our
work proceeds.

There has been some interest in having a server library API which  
would make
it possible to link the server into an application. This was deemed  
a good
and useful idea. Patches are welcome - I think someone mentioned  
having this
working already.

This is already done in jackdmp tree where 2 shared libraries are  
defined: libjack(mp).so contains the client side of the code and  
libjackserver(mp).so contains the server side of the code, both  
libraries expose the entire jack API. jackdmp and backend link to  
libjackserver(mp).so. Client applications can either link the normal  
way to libjack(mp).so or possibly to libjackserver(mp).so. In the  
second case and using the "automatic start server" feature,  
jack_client_open will simply start the server inside the client  
process space.



We also need to make sure client developers understand the  
ramifications of
appearing and disappearing backends. This is mostly a documentation  
issue
but automated testing frameworks might help if someone feels like  
coming up
with something like that.


Things not discussed
--------------------
The discussion took quite a while and sadly we were not able to  
discuss
everything planned. I found two issues in my notes which were left  
out. They
were:

Richard Spindler pointed out that it would be nice to have fast  
forward /
scrubbing ability with jack transport.

Pieter Palmers mentioned generalizing the MIDI implementation to  
something
that would handle events in general.

Stephane 
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
_______________________________________________
Jackit-devel mailing list

--
Sébastien THOMAS - Ingénieur Systèmes
[hidden email] - tel : +33 (0) 1 40 70 42 81




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] [LAC08] The Future of Jack

Stéphane Letz

Le 7 mars 08 à 10:41, Sébastien THOMAS a écrit :

> Many thanks for this.
> Could we add something here, like :
>
> making Jackd work on something else than Linux ?
>
> Ok, it is working on OSX and windows... but could it be compatible  
> with Solaris (10) ?

If someone works on that why not?

>
> I made 2 patches last year but still had troubles. I finaly went on  
> a Linux box, having many other down side.
> I can't understand jackd is not stable on Solaris while using the  
> dummy driver... or maybe it's just me ?

Are you ready to try again?

>
> No need to talk about jackdmp, which is not working at all on  
> Solaris :)

?? any more info?

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] [LAC08] The Future of Jack

juuso.alasuutari (Bugzilla)
In reply to this post by Stéphane Letz
Thanks for the sum-up, Sampo! Everything relevant seems to be thoroughly
explained.

>> We discussed a potential server control protocol but the thoughts  
>> about it
>> are still too scattered to present here. There was no agreement on  
>> what
>> should be done, mostly because it wasn't clear what was proposed to  
>> be done.
>> I'll throw the ball over to Nedko, Marc & Juuso, but I will give a  
>> short
>> description of one problem which could be solved by this:
 >>
 >> Having applications autostart jackd is great, but the current
 >> autostart
 >> model is problematic: There is no real control as to what
 >> configuration of
 >> jackd should use and there is no way to get error messages from the
 >> autostarted process to a control application like qjackctl. I also
 >> fear
 >> (haven't tested this recently) that the process is tied in with the
 >> original
 >> client in a way which would tie the life spans of the two processes
 >> together.
 >>
 >> While there has been talk of using D-Bus for this, we must remember
 >> that
 >> jack is multi-platform and there is no D-Bus available on OS X or on
 >> Windows. So everything has to be de-coupled from the actual
 >> implementation.
 >> Also, the use of the protocol should be designed to be optional so
 >> that
 >> jackd will work without it.
<snip>
 >> There has been some interest in having a server library API which
 >> would make
 >> it possible to link the server into an application. This was deemed
 >> a good
 >> and useful idea. Patches are welcome - I think someone mentioned
 >> having this
 >> working already.

It wasn't until after the meeting that I realized that the server
control protocol issue is external to any actual JACK development.
Everyone agreed that the server library API separation is a good idea,
and this is all that we (the D-Bus crowd) really need.

The server library API will by necessity include everything needed for
controlling the server. It will be the standard, portable low-level JACK
control protocol (although not in the IPC sense of the word). This means
that we are free to implement JACK-as-D-Bus-service by simply linking
the JACK server library against some D-Bus service code. The same
approach could also be used to implement an OSC control interface, and
so on.

The JACK server library API will turn the control protocol debate into a
non-issue, because the IPC control protocol(s) will just be external
programs which utilize the standard server library. Unless we actually
want to go on implementing a standardized cross-platform IPC control
protocol for JACK, which is a can of long, hairy worms...

Juuso

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] [LAC08] The Future of Jack

Stéphane Letz

Le 7 mars 08 à 14:08, Juuso Alasuutari a écrit :

> Thanks for the sum-up, Sampo! Everything relevant seems to be  
> thoroughly
> explained.
>
>>> We discussed a potential server control protocol but the thoughts
>>> about it
>>> are still too scattered to present here. There was no agreement on
>>> what
>>> should be done, mostly because it wasn't clear what was proposed to
>>> be done.
>>> I'll throw the ball over to Nedko, Marc & Juuso, but I will give a
>>> short
>>> description of one problem which could be solved by this:
>>>
>>> Having applications autostart jackd is great, but the current
>>> autostart
>>> model is problematic: There is no real control as to what
>>> configuration of
>>> jackd should use and there is no way to get error messages from the
>>> autostarted process to a control application like qjackctl. I also
>>> fear
>>> (haven't tested this recently) that the process is tied in with the
>>> original
>>> client in a way which would tie the life spans of the two processes
>>> together.
>>>
>>> While there has been talk of using D-Bus for this, we must remember
>>> that
>>> jack is multi-platform and there is no D-Bus available on OS X or on
>>> Windows. So everything has to be de-coupled from the actual
>>> implementation.
>>> Also, the use of the protocol should be designed to be optional so
>>> that
>>> jackd will work without it.
> <snip>
>>> There has been some interest in having a server library API which
>>> would make
>>> it possible to link the server into an application. This was deemed
>>> a good
>>> and useful idea. Patches are welcome - I think someone mentioned
>>> having this
>>> working already.
>
> It wasn't until after the meeting that I realized that the server
> control protocol issue is external to any actual JACK development.
> Everyone agreed that the server library API separation is a good idea,
> and this is all that we (the D-Bus crowd) really need.
>
> The server library API will by necessity include everything needed for
> controlling the server. It will be the standard, portable low-level  
> JACK
> control protocol (although not in the IPC sense of the word). This  
> means
> that we are free to implement JACK-as-D-Bus-service by simply linking
> the JACK server library against some D-Bus service code. The same
> approach could also be used to implement an OSC control interface, and
> so on.
>
> The JACK server library API will turn the control protocol debate  
> into a
> non-issue, because the IPC control protocol(s) will just be external
> programs which utilize the standard server library. Unless we actually
> want to go on implementing a standardized cross-platform IPC control
> protocol for JACK, which is a can of long, hairy worms...
>
> Juuso
>

To refine on that, the big picture would be:

- have the server code inside a libjackserver(mp).so shared library

- have this library export the current jack API + a new API to control  
the server (Nekdo is working on that)

This way we can have:

- current jackd(mp) be rewritten a little to just link to this library  
and use the clean server control API to start the server

- new jackdbus just link to this library and use the clean server  
control API to start the server, and expose a D_BUS service, available  
to other control tools

- let clients link to this library and have the "server started in  
process space" feature.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] [LAC08] The Future of Jack

Jussi Laako-2
In reply to this post by Stéphane Letz
Stéphane Letz wrote:
>> I am sure there are people who would have wanted to be in the  

Unfortunately I didn't manage to get there... :(

>> Wait/signal model
>> -----------------
>> This is what Stéphane Letz described more thoroughly in his patch  
>> sent to
>> jackit-devel on wednesday.

/me ++

>> jack is multi-platform and there is no D-Bus available on OS X or on
>> Windows. So everything has to be de-coupled from the actual  

Btw, is there now support for "Windows Core Audio" (the new and finally
decent API shipped in Vista) in jackdmp?

>> "fallback"
>> backend which provides 0 inputs, 0 outputs and 1 software time  
>> source. This
>> would be so that if all other backends fail, jack would have a  
>> backend to
>> get timings from. The fallback backend could potentially handle  
>> freewheeling
>> mode by hyping up the software clock.

Isn't there "dummy" already for this?

I've been thinking about a new dumb backend based on POSIX timer API.
Now that there is dynticks and hrtimers in kernels by default, it should
be even pretty accurate...


BR,

        - Jussi

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [Jack-Devel] [LAC08] The Future of Jack

Stéphane Letz

Le 8 mars 08 à 02:36, Jussi Laako a écrit :

> Stéphane Letz wrote:
>>> I am sure there are people who would have wanted to be in the
>
> Unfortunately I didn't manage to get there... :(
>
>>> Wait/signal model
>>> -----------------
>>> This is what Stéphane Letz described more thoroughly in his patch
>>> sent to
>>> jackit-devel on wednesday.
>
> /me ++
>
>>> jack is multi-platform and there is no D-Bus available on OS X or on
>>> Windows. So everything has to be de-coupled from the actual
>
> Btw, is there now support for "Windows Core Audio" (the new and  
> finally
> decent API shipped in Vista) in jackdmp?

Are you interested to improve that?? ((-:  More seriously jackdmp  
uses a PortAudio based backend on Windows, and PortAudio itself is  
supposed to be improved to beneficiate of Vista improvements. Another  
issue is some new things in real-time thread managements, and this  
would have to be included in client thread code.

Stephane
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel