Re: [Jack-Devel] major change in jack1 MIDI handling

PrevNext  Index
DateSat, 12 Oct 2013 09:20:55 +0200
From Stéphane Letz <[hidden] at grame dot fr>
ToPaul Davis <[hidden] at linuxaudiosystems dot com>
CcJACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPaul Davis Re: [Jack-Devel] major change in jack1 MIDI handling
Follow-UpChristian Schoenebeck Re: [Jack-Devel] major change in jack1 MIDI handling
Follow-UpPaul Davis Re: [Jack-Devel] major change in jack1 MIDI handling
Le 12 oct. 2013 à 00:25, Paul Davis <[hidden]> a écrit :

> 
> 
> 
> On Fri, Oct 11, 2013 at 5:35 PM, Tim E. Real <[hidden]> wrote:
> 
> Thanks for the heads up! Nice work.
> 
> Paul, does this mean Jack1 and Jack2 are becoming
>  more alike? Or are there still advantages of one over the other?
> 
> That is, might (or should) the distros begin to swing
>  back in favour of Jack1?
> 
> Most seem to be Jack2 - centric at the moment.
> 
> people who want:
>   
>     * multiple cores for parallel data flow
>     * interfacing with PulseAudio
>     * interfacing with D-Bus
>     * click-free connections (and don't mind the larger latency that this causes)

Again, again, again, and again : click-free connections connections are *nothing* to do with larger latency.

jack2 has one more buffer latency in the so called "asynchronous mode", when the server does the wait for graph end in a given cycle, and write the output buffers from the previous cycle, and is absolutely similar to jack1 regarding latency in the so called "synchronous mode", where the server waits for graph end in a given cycle and write the output buffers produced by the graph in the given cycle

This was explained like 8 years ago in this paper:  http://www.grame.fr/ressources/publications/Jackdmp-lac2005.pdf

History is *not* going to be rewritten…. ((-;

Stéphane
PrevNext  Index

1381562462.13472_0.ltw:2, <3D3F5DAD-C435-4E3C-A457-99E7A98E7EA3 at grame dot fr>