17 Feb
2013
17 Feb
'13
3:06 a.m.
I haven't really looked at the recorder program, but the player is pretty
cool.
To make it easier for me to understand, I simplified the code somewhat (got rid
of lash stuff, reduced output to a single port, etc) so my code excerpts below
don't match up exactly with the original code.
The first question is a rather stupid one: How long is a Jack frame? If we're
running at 44.1 kHz, is a frame 1/44100 sec? Or is it some multiple? Or is it
something else? And does the process callback get called at each frame while
transport is rolling?
process_callback() calls process_midi_output(), wherein we find:
port_buffer = jack_port_get_buffer(output_port, nframes);
Why the nframes parameter? Is there a separate buffer area for each frame?
A little later in the same function we have:
last_frame_time = jack_last_frame_time(jack_client);
Is this the time of the end of the last process cycle?
--
7:8
17 Feb
17 Feb
1:21 p.m.
On Sat, Feb 16, 2013 at 10:33 PM, M Donalies <ingeniousnebbish(a)cox.net> wrote:
The first question is a rather stupid one: How long is
a Jack frame? If we're
running at 44.1 kHz, is a frame 1/44100 sec? Or is it some multiple? Or is it
something else? And does the process callback get called at each frame while
transport is rolling?
IIRC, a "frame" in JACK parlance is one sample, so 1/44100 in your
example. The process callback is called regardless of transport
state. You call a function (jack_transport_query I think? I don't
have any of my code in front of me right now) to get transport state
and timing/tempo information (including bar:beat:tick).
process_callback() calls process_midi_output(),
wherein we find:
port_buffer = jack_port_get_buffer(output_port, nframes);
Why the nframes parameter? Is there a separate buffer area for each frame?
There's a separate buffer for each port.
A little later in the same function we have:
last_frame_time = jack_last_frame_time(jack_client);
Is this the time of the end of the last process cycle?
Not sure about this one. The docs say: "the precise time at the start
of the current process cycle" which should be the same time as the
start of the current process cycle, I would think.
18 Feb
18 Feb
1:07 p.m.
On Sunday 17 February 2013 08:21:51 Paul Coccoli wrote:
Yes, and that's the output_port arg, but what's with nframes? Why isn't the
function simply: jack_port_get_buffer(output_port) ?
Oh, I get it. I was reading "last" as "previous" as in currentCycle -
1.
--
7:8
On Sat, Feb 16, 2013 at 10:33 PM, M Donalies
<ingeniousnebbish(a)cox.net>
wrote:
process_callback() calls process_midi_output(), wherein we find:
port_buffer = jack_port_get_buffer(output_port, nframes);
Why the nframes parameter? Is there a separate buffer area for each
frame?
There's a separate buffer for each port. A little later
in the same function we have:
last_frame_time = jack_last_frame_time(jack_client);
Is this the time of the end of the last process cycle?
Not sure about this one. The docs say: "the precise time at the start
of the current process cycle" which should be the same time as the
start of the current process cycle, I would think. 
1:33 p.m.
On Mon, Feb 18, 2013 at 8:35 AM, M Donalies <ingeniousnebbish(a)cox.net>wrote;wrote:
On Sunday 17 February 2013 08:21:51 Paul Coccoli
wrote:
Yes, and that's the output_port arg, but what's with nframes? Why isn't the
function simply: jack_port_get_buffer(output_port) ?
because the client may not want to get all the data at once.
ardour, for example, breaks up the process() cycle internally to deal with
"global" scheduled events. so it may ask for the first N frames, then
another M, then another P frames until everything is done.
there was another reason at one time too, but the internally engineering of
JACK has eliminated that one.
On Sat, Feb 16, 2013 at 10:33 PM, M Donalies
<ingeniousnebbish(a)cox.net>
wrote:
process_callback() calls process_midi_output(), wherein we find:
port_buffer = jack_port_get_buffer(output_port, nframes);
Why the nframes parameter? Is there a separate buffer area for each
frame?
There's a separate buffer for each port.
2:07 p.m.
On Monday 18 February 2013 08:33:16 Paul Davis wrote:
On Mon, Feb 18, 2013 at 8:35 AM, M Donalies
<ingeniousnebbish(a)cox.net>wrote;wrote:
Oh, I see. process_callback() is called once every N frames, where N depends
upon user settings for latency, etc. I was mistakenly reading it as a callback
each frame.
--
7:8
On Sunday 17 February 2013 08:21:51 Paul Coccoli
wrote:
Yes, and that's the output_port arg, but what's with nframes? Why isn't
the function simply: jack_port_get_buffer(output_port) ?
because the client may not want to get all the data at once.
ardour, for example, breaks up the process() cycle internally to deal with
"global" scheduled events. so it may ask for the first N frames, then
another M, then another P frames until everything is done. On Sat, Feb 16, 2013 at 10:33 PM, M Donalies
<ingeniousnebbish(a)cox.net>
wrote:
process_callback() calls process_midi_output(), wherein we find:
port_buffer = jack_port_get_buffer(output_port, nframes);
Why the nframes parameter? Is there a separate buffer area for each
frame?
There's a separate buffer for each port.
1:56 p.m.
This question arises from jack-keyboard rather than jack-smf-utils. The basic
framework is very similar, but jack-keyboard gets input from a gui rather than
from a smf.
So the idea is that you press a key on the keyboard and an event handler gets
called. The event handler calls queue_new_message(int, int, int), which
creates a midi event ev on the stack. Then it calls queue_message(&ev).
queue_message() copies ev to a ringbuffer. Okay, so far, so good.
queue_new_message() exits and ev goes out of scope, so only the copy on the
ringbuffer remains.
The next process cycle process_callback() is invoked. It calls
process_midi_output(), which takes data from the ringbuffer and moves it to
output_port's buffer.
Is this what's happening?
Now for receiving timing info from Jack. Where's a good place to look for code
that explains how to get (and display in a gui widget) the current time while
transport is rolling? There's QJackCtl of course. Is there something simpler,
more of an example program?
--
7:8
4118
days inactive
4119
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
M Donalies -
Paul Coccoli -
Paul Davis