2 Jul
2015
2 Jul
'15
7:20 a.m.
Hi,
I'm still using debian's jackd1/libjack0 package (0.124.1) and have not
tried to reproduce this with git master yet (at least, I haven't seen an
obvious fix in the commit log since 0.124.1).
In one terminal window I run jack_showtime.
In the other window I do:
jack_transport
tempo 96 # just in case
master
play # does not
jack_showtime correctly shows the state, but no BBT information. From my
own client I know that jack_position_t::valid==0.
Some testing revealed that the timebase() callback in tools/transport.c
is *not called at all*, although jack_set_timebase_callback is called
and returns without error.
- But everything works fine when I switch to the jack2 stack...
And in some cases, when switching between/enabling/disabling different
Transport masters,
jack_position_t::valid retains the JackPositionBBT flag (and stale
information) -- but no-one updates them any more...
Maybe related: I've seen some strange values (*very* large negative
number) for bar_start_tick when using ardour4.1.
The very first time (and after rewind?) it contains 0.0 and is not
updated. A quick glance into the ardour source code reveals that this
field is not implemented yet. I could probably live with that.
BUT: After stopping+starting the playback, these strange values
appear... How can I know whether some value in this field is usable at
all -- except for some heuristics?
Back to the original topic... in both cases the jack_position_t struct
contains stale/random values, instead of starting from a "clean" base --
maybe memset(,0,) is all that is needed here?
Tobias
2 Jul
2 Jul
8:38 a.m.
jack_transport is not intended to act as a the time master.
providing BBT information requires some kind of tempo map. This is
beyond the scope of jack_transport.
the non-clearing of the transport state information is a bug, for sure.
On Thu, Jul 2, 2015 at 8:20 AM, Tobias Hoffmann
<lfile-list(a)thax.hardliners.org> wrote:
Hi,
I'm still using debian's jackd1/libjack0 package (0.124.1) and have not
tried to reproduce this with git master yet (at least, I haven't seen an
obvious fix in the commit log since 0.124.1).
In one terminal window I run jack_showtime.
In the other window I do:
jack_transport
tempo 96 # just in case
master
play # does not
jack_showtime correctly shows the state, but no BBT information. From my own
client I know that jack_position_t::valid==0.
Some testing revealed that the timebase() callback in tools/transport.c is
*not called at all*, although jack_set_timebase_callback is called and
returns without error.
- But everything works fine when I switch to the jack2 stack...
And in some cases, when switching between/enabling/disabling different
Transport masters,
jack_position_t::valid retains the JackPositionBBT flag (and stale
information) -- but no-one updates them any more...
Maybe related: I've seen some strange values (*very* large negative number)
for bar_start_tick when using ardour4.1.
The very first time (and after rewind?) it contains 0.0 and is not updated.
A quick glance into the ardour source code reveals that this field is not
implemented yet. I could probably live with that.
BUT: After stopping+starting the playback, these strange values appear...
How can I know whether some value in this field is usable at all -- except
for some heuristics?
Back to the original topic... in both cases the jack_position_t struct
contains stale/random values, instead of starting from a "clean" base --
maybe memset(,0,) is all that is needed here?
Tobias
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
10:30 a.m.
On 02/07/15 15:38, Paul Davis wrote:
jack_transport is not intended to act as a the time
master.
Well, comparing example-clients/transport_client.c and
tools/transport.c, I'd say the one big difference between the two is
that tools/transport.c (aka jack_transport) can act as a *simple*
timebase master...
providing BBT information requires some kind of tempo
map. This is
beyond the scope of jack_transport.
Sure, if I need a more sophisticated tool,
I'll use one (or write one
myself).
Thankfully, jack provides a lot of small command line tools for simple
tasks.
That's what I also expected from jack_transport. And with jack2 the same
jack_transport does work as a timebase master (with a "trivial" tempo map).
But the real issue here is a completely different one:
Does jack_set_timebase_callback() also require jack_set_process_callback()?
jack_transport (which is shipping with jack1) assumes that
jack_set_process_callback is not required -- which matches jack2's behavior.
But for jack1 the timebase callback is only called, when I add a process
callback (just return 0;).
Either jack1/libjack0 is wrong to also require the process callback, or
transport.c is wrong to assume that it's not needed (because it does not
process audio).
AFAIUI jackaudio.org/api does not clearly say that the process callback
must be non-NULL to become a timebase master, although I could see why
it might in fact be necessary (for a certain implementation).
Tobias
11:47 a.m.
On 02/07/15 17:30, Tobias Hoffmann wrote:
On 02/07/15 15:38, Paul Davis wrote:
Ok, I see now that the BBT update algorithm (in the "else" branch in
timebase()) in transport.c is quite broken, because it accumulates
rounding errors. However always using the first, recalculating branch
(basically: if (true)) seems to be stable -- or at least: better than
Hydrogen's timebase master, which updates the BBT only every few
cycles... (I've read that somewhere a completely rewritten Jack Master
implementation for Hydrogen is available, which I have not tested yet).
I find it quite sad that even some code distributed in the jack tarball
is an example of how NOT to use the Jack API ...
Tobias
jack_transport is not intended to act as a the
time master.
Well, comparing example-clients/transport_client.c and
tools/transport.c, I'd say the one big difference between the two is
that tools/transport.c (aka jack_transport) can act as a *simple*
timebase master...
11:57 a.m.
Frankly, computing BBT time has never been part of "how to use the
JACK API". It should probably never have been included in the source
code in the first place.
Managing BBT time is *extremely* complex - we have worked on it for
years in Ardour and it still has issues. I'd prefer to just rip it
out.
On Thu, Jul 2, 2015 at 12:47 PM, Tobias Hoffmann
<lfile-list(a)thax.hardliners.org> wrote:
On 02/07/15 17:30, Tobias Hoffmann wrote:
On 02/07/15 15:38, Paul Davis wrote:
Ok, I see now that the BBT update algorithm (in the "else" branch in
timebase()) in transport.c is quite broken, because it accumulates rounding
errors. However always using the first, recalculating branch (basically: if
(true)) seems to be stable -- or at least: better than Hydrogen's timebase
master, which updates the BBT only every few cycles... (I've read that
somewhere a completely rewritten Jack Master implementation for Hydrogen is
available, which I have not tested yet).
I find it quite sad that even some code distributed in the jack tarball is
an example of how NOT to use the Jack API ...
Tobias
jack_transport is not intended to act as a the time master.
Well, comparing example-clients/transport_client.c and tools/transport.c,
I'd say the one big difference between the two is that tools/transport.c
(aka jack_transport) can act as a *simple* timebase master...
3460
days inactive
3460
days old
jackaudio@lists.linuxaudio.org
4 comments
2 participants
participants (2)
-
Paul Davis -
Tobias Hoffmann