Some more explanations on jackdmp...

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

Some more explanations on jackdmp...

Stéphane Letz
Following Jesse advice... here are some more explanations on jackdmp  
and how it is different from normal jackd, and how these differences  
can be visible from the user point of view:

- jackdmp use a new client activation model that allows simultaneous  
client execution (on a smp machine) when parallel clients exist in  
the graph (client that have the same inputs). This activation model  
allows to better use available CPU on a smp machine, but also works  
on mono-processor machine.

- jackdmp use a lock-free way to access (read/write) the client  
graph, thus allowing connections/disconnection to be done without  
interrupting the audio stream. The result is that connections/
disconnection are glitch-free.

- jackdmp can work in 2 different mode at the server level:
       
        - "synchronous" activation: in a given cycle, the server waits for  
all clients to be finished (similar to normal jackd)

        - "asynchronous" activation:  in a given cycle, the server does not  
wait for all clients to be finished and use output buffer computed  
the previous cycle. The "audible" result of this mode is that if a  
client is not activated during one cycle, other clients may still run  
and the resulting audio stream will (possibly [1]) still be produced  
(even if its partial in some way). This mode usually result in fewer  
(less audible) audio glitches in a loaded system .

Oof course I am interested to get feedback...

Stephane

[1] This depends of the client graph topology
 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some more explanations on jackdmp...

Simon Jenkins
On Wed, 2005-11-30 at 16:40 +0100, Stéphane Letz wrote:
> [...]
> - jackdmp use a lock-free way to access (read/write) the client  
> graph, thus allowing connections/disconnection to be done without  
> interrupting the audio stream. The result is that connections/
> disconnection are glitch-free.
> [...]

Hi Stéphane

I'm wondering - now that glitch-free connect/disconnect is a
reality for you - whether this changes your view on re-ordering
the graph when it becomes acyclic?

AFAICT (but I've only looked at the code briefly) jackdmp does
not do this. Correct me if I am mistaken here. If it /does/
do this then some disconnections will not be glitch-free.

Cheers

Simon




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some more explanations on jackdmp...

Stéphane Letz

Le 3 déc. 05 à 13:16, Simon Jenkins a écrit :


> On Wed, 2005-11-30 at 16:40 +0100, Stéphane Letz wrote:
>
>
>> [...]
>> - jackdmp use a lock-free way to access (read/write) the client
>> graph, thus allowing connections/disconnection to be done without
>> interrupting the audio stream. The result is that connections/
>> disconnection are glitch-free.
>> [...]
>>
>>
>
> Hi Stéphane
>
> I'm wondering - now that glitch-free connect/disconnect is a
> reality for you - whether this changes your view on re-ordering
> the graph when it becomes acyclic?
>
> AFAICT (but I've only looked at the code briefly) jackdmp does
> not do this. Correct me if I am mistaken here. If it /does/
> do this then some disconnections will not be glitch-free.
>
> Cheers
>
> Simon
>

Hi Simon,

Well, I took the simplest model: special "feedback" connections are  
established when the loop is closed, and remain untill the given  
connection is finally removed.  Thus there is no re-ordering of the  
graph. Thus basically i changed my mind..., because it was much  
easier to do....

Anyway, I have kind of 2 similar concepts implemented right now:

- special feedback connections

- a special "loopback" driver that can possibly be used (manually) to  
cut a connection between 2 clients, use the loopback driver, so that  
those 2 clients become runnable in parallel on a smp machine (adding  
a one buffer more latency to have a "pipelining" effect)

I think one concept only should be enough, but maybe this would  
require a more global re-thinking that would take also in account the  
discussion you had some weeks ago about client multiple activation  
inside a same cycle.

Any news on the subject?

Stephane








-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Some more explanations on jackdmp...

Simon Jenkins
On Sat, 2005-12-03 at 13:45 +0100, Stéphane Letz wrote:

> Le 3 déc. 05 à 13:16, Simon Jenkins a écrit :
>
>
> > On Wed, 2005-11-30 at 16:40 +0100, Stéphane Letz wrote:
> >
> >
> >> [...]
> >> - jackdmp use a lock-free way to access (read/write) the client
> >> graph, thus allowing connections/disconnection to be done without
> >> interrupting the audio stream. The result is that connections/
> >> disconnection are glitch-free.
> >> [...]
> >>
> >>
> >
> > Hi Stéphane
> >
> > I'm wondering - now that glitch-free connect/disconnect is a
> > reality for you - whether this changes your view on re-ordering
> > the graph when it becomes acyclic?
> >
> > AFAICT (but I've only looked at the code briefly) jackdmp does
> > not do this. Correct me if I am mistaken here. If it /does/
> > do this then some disconnections will not be glitch-free.
> >
> > Cheers
> >
> > Simon
> >
>
> Hi Simon,
>
> Well, I took the simplest model: special "feedback" connections are  
> established when the loop is closed, and remain untill the given  
> connection is finally removed.  Thus there is no re-ordering of the  
> graph. Thus basically i changed my mind..., because it was much  
> easier to do....

I said at the time, IIRC, that actually sitting down to code that
behaviour would be enough to convince you that it shouldn't be
done ;) jack_check_acyclic turned out to be twice as much code as
the entire rest of the sort... and nobody has seen fit to remove
my comment that it corrupts data. IMO (especially with JACK
MIDI becoming ever more mainstream) maybe its time for
jack_check_acyclic to go?


> Anyway, I have kind of 2 similar concepts implemented right now:
>
> - special feedback connections

> - a special "loopback" driver that can possibly be used (manually) to  
> cut a connection between 2 clients, use the loopback driver, so that  
> those 2 clients become runnable in parallel on a smp machine (adding  
> a one buffer more latency to have a "pipelining" effect)

(hoping my ascii art survives the journey...)
.
.          +-----+
. ----o--->|  A  |>--o----->
.     |    +-----+   |
.     |              |
.   o--------<-------o
.   | |
.   | o------<-------o
.   |                |
.   |      +-----+   |
. --o----->|  B  |>--o----->
.          +-----+
.

I understand the temptation to run A and B in parallel here! On
grounds of symmetry alone it looks like the right thing to do.
But really the dependencies introduced by those feedback
connections are just as real as any other dependencies
introduced by any other connections, forwards or backwards. You
can't honour both dependencies, because its a loop, but that
doesn't make them better candidates to ignore (to achieve
pipelining) than other connections would be. Maybe it actually
makes them /worse/ candidates, since pipelining would affect
the resulting sound as well as the latency.

Running A and B in parallel /here/ OTOH....
.
.       +-----+      +-----+
. ----->|  A  |>---->|  B  |>---->
.       +-----+      +-----+
.

...would increase latency but have no other effect on the
resulting sound. (Except a glitch if you switch from serial
to parallel or back). In some circumstances such pipelining
would be a very VERY useful feature to have. I'm just
wondering now whether it could be done automatically and
glitchlessly...


> I think one concept only should be enough, but maybe this would  
> require a more global re-thinking that would take also in account the  
> discussion you had some weeks ago about client multiple activation  
> inside a same cycle.
>
> Any news on the subject?

On paper its definitely workable and, thanks to some things
Jussi said, I've got a reasonable looking API for it.

Now I just need to code it up, which I'll try to get done in
January. I've been reluctant to put too much effort into demoing
a "post-1.0" feature candidate when its not certain which
code base (jackd or jackdmp) to target. Maybe jackdmp would
be the best place to experiment with this stuff anyway? Its
a good fit... more activations == more potential parallelism.
OTOH I'm totally agnostic wrt which code base ends up being
used so I'll probably just demo it wherever it seems easiest
and quickest when I start.

Cheers

Simon




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
<a href="http://ads.osdn.com/?ad_idv37&alloc_id865&op=click">http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel