Re: [Jack-Devel] The Situation(s) With JACK

PrevNext  Index
DateFri, 09 Dec 2011 18:58:00 -0500
From Paul Davis <[hidden] at linuxaudiosystems dot com>
ToFlorian Paul Schmidt <[hidden] at gmx dot net>
Cc[hidden] at lists dot jackaudio dot org
In-Reply-ToFlorian Paul Schmidt Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpFons Adriaensen Re: [Jack-Devel] The Situation(s) With JACK
Follow-UpFlorian Paul Schmidt Re: [Jack-Devel] The Situation(s) With JACK
On Fri, Dec 9, 2011 at 6:47 PM, Florian Paul Schmidt
<[hidden]> wrote:
> Personally I found the jack transport specification always lacking in this
> respect.

lacking? you say its lacking but then ask for a very simple protocol:

>IMHO a better approach would be to just privide a very simple

which we have!

> protocol, which is just framebased and provides just the states STOPPED,
> RUNNING and a shared frame number. Making assumptions about musical time,
> etc., is too restrictive.

STOPPED and RUNNING can't accomodate slow-sync clients.

> To provide musical time interoperation between different audio apps an
> independent protocol could emerge and once it has matured one could again
> think about integrating it into jack transport..

we've had the simple protocol for years now. we've also had MMC for
even longer, which is totally independent of JACK but has been
integrated into via jackmmcctl or whatever its called.

i recommend reading the wiki page cited on this. it has an excellent
discussion of the entire issue.
PrevNext  Index

1323475090.1282_0.ltw:2,a <CAFa_cK=LTxW7MahRhvTj2j_Kahf11JsgujP1uJjAqRxRGFXBVg at mail dot gmail dot com>