support for input ports. about simplejack

[mildsunrise]

It would be an interesting feature to implement, but I don't know how to make it fit in simplejack.
Simplejack's phylosophy is that you make a callback:

function callback(time, port) {
}

and the callback returns the sample.
So how should I make the API for input ports? I'm open to ideas.

[dg14]

Yes i know ;)

the first step is to implement a callback to return all the current buffer read from the port on the work_callback. it should works on analisys as fft. but i don't know if it's feasable. due to the fact that the read buffer is continoulsy changing (probably is a ring).

the second step is to put the new bytes read in a v8 stream, in the way that a client can get that stream and when data is present it should push to the stream. this second step should be usefull to save captured data.
http://jackit.sourceforge.net/cgi-bin/lxr/http/source/example-clients/capture_client.c

[mildsunrise]

the first step is to implement a callback to return all the current buffer read from the port on the work_callback. it should works on analisys as fft. but i don't know if it's feasable. due to the fact that the read buffer is continoulsy changing (probably is a ring).

I didn't understand this very well. You're saying we should add an API like client.getInputData(portNumber) that returns the current buffer?
And then we put this data in a stream for the user to read?

PS: FFT is not feasible, it's too much overhead. simplejack should just handle the data.

[dg14]

forget the first step. it's not feasible.

in the capture_client there's an example to write to a jack_ringbuffer. instead you should write to a stream.

about FFT. i know. it's off-topic.

[mildsunrise]

It's the JS API that worries me.
In the current API / phylosophy there is no notion of:

• Samples (user doesn't need to know the sample rate or period size or precision)
• Buffers (at any time is the user presented with binary data in a buffer)

But having a stream for the input requires the user to know the sample rate and the data format, therefore clashing with what I said above.

[dg14]

Jack don't know about that, is only a flow of numbers, precisely a flow of floats. the conversion is made from the server:

if i write this,

var amp=0.5;
// Register audio callback
client.output_callback(function(t) {
  return amp*Math.sin(2*Math.PI * 440 * t);
});

it means that i return a float number, that can go outside of [ -1.0 , 1.0 ].

i'll try to study the stream ( you could check this https://github.com/joeferner/node-portaudio/blob/master/src/nodePortAudio.cpp ). probably we need a back jack_ringbuffer ...

[mildsunrise]

To clarify, what I mean is that, with this:

var amp=0.5;
// Register audio callback
client.output_callback(function(t) {
  return amp*Math.sin(2*Math.PI * 440 * t);
});

you return a Number. You don't know if it gets encoded as a 32-bit float, or a 64-bit float, or as a 16-bit int, or anything, you're just returning a Number. You never have to deal with binary data.

With a stream (or buffer), you have.

(Now when it comes to the implementation, I don't know if a ring buffer is a good idea.)

[dg14]

do you think that this is heavy?

    /* input cycle */
    for (int port = 0; port < inst->input_ports; port++) {
      printf("input cycle");
      jack_default_audio_sample_t* buffer = inst->input_buffers[port];
      if (buffer!=NULL && inst->bufferSize>0) {
        v8::Handle<v8::Array> arrBuffer=v8::Array::New(inst->bufferSize);
        for (int i = 0; i < inst->bufferSize; i++) {
          arrBuffer->Set(i,v8u::Num(buffer[i]));
        }
        in_args[0] = arrBuffer;
        inst->input_callback->CallAsFunction(inst->handle_, 1, in_args);
        if (trycatch.HasCaught()) V8_THROW(trycatch.Exception()); //FIXME: find better way, keep mutex into account
      }
      printf("end input cycle");
    }

[mildsunrise]

I haven't heard good things of performance with plain arrays.
With typed arrays the performance improves, so we could go for Float32

But I still don't like this API, it requires the user to know about the
sample rate and calculate the time himself...

2014-11-21 19:25 GMT+01:00 dg14 [email protected]:

do you think that this is heavy?

/* input cycle */
for (int port = 0; port < inst->input_ports; port++) {
  printf("input cycle");
  jack_default_audio_sample_t* buffer = inst->input_buffers[port];
  if (buffer!=NULL && inst->bufferSize>0) {
    v8::Handle<v8::Array> arrBuffer=v8::Array::New(inst->bufferSize);
    for (int i = 0; i < inst->bufferSize; i++) {
      arrBuffer->Set(i,v8u::Num(buffer[i]));
    }
    in_args[0] = arrBuffer;
    inst->input_callback->CallAsFunction(inst->handle_, 1, in_args);
    if (trycatch.HasCaught()) V8_THROW(trycatch.Exception()); //FIXME: find better way, keep mutex into account
  }
  printf("end input cycle");
}

—
Reply to this email directly or view it on GitHub
#1 (comment).

[dg14]

Consider that the buffer is composed of

typedef float jack_default_audio_sample_t;

i think the sample rate is determined from server (http://jackaudio.org/files/docs/html/group__ServerControl.html)

but for now this code segfaults, i've to check why. i've also get the state of connected/disconnected, that's usefull, but it segfaults when connected ("terminate called after throwing an instance of 'v8::Persistentv8::Value'")

[mildsunrise]

Yeah, I know the sample rate is determined by the server.
But from the user point of view, with our current API:

client.callback(function(time) {
  return Math.sin(440 * Math.PI*2 * time);
});

Notice how there is no sample_rate appearing in the code; it'll work the same regardless of the sample rate choosen by the server.

Now, if we did what you say (pass an array of samples to the user), now the user needs to know what the sample rate is, and it needs to do the math himself.

[billythemusical]

Hi - just chiming in from left field here :) Thanks for making this btw!

It seems each client needs to know the sample rate and buffer size using vanilla JackTrip anyways, so using this feature seems to already come with a caveat?