On Thu, Feb 13, 2020 at 5:31 PM Andre Schmidt <andre(a)osku.de> wrote:
On Thu, 13 Feb 2020 08:46:18 +0100
Kjetil Matheussen <k.s.matheussen(a)gmail.com> wrote:
On Wed, Feb 12, 2020 at 5:49 PM Andre Osku
Schmidt <andre(a)osku.de> wrote:
Hello JACKies,
i tinkered this thing
https://github.com/oskude/jackplot that plots jack audio data with
opengl in real-time (and am a really happy puppy :D). but as i'm a c, jack and opengl
noob, i was hoping to get some help here. (at least for the jack part)
so i set the jack data (pointer) to a global variable
https://github.com/oskude/jackplot/blob/bcac59813b01b3bf7c2ebebd4988b22f5bf…
and read that data in opengl draw function (when ever its ready to draw)
https://github.com/oskude/jackplot/blob/bcac59813b01b3bf7c2ebebd4988b22f5bf…
(ignoring the function i read it in, am i even reading the jack data correctly?)
i'm suprised that it works, and hasn't crashed!
but i have the feeling that this is a bad/unsafe way to do it...
any thoughts? tips? links?
You could look at example_clients/capture_client.c in the jack2 repository.
ah, gotta check capture_client.c in detail later, thanks!
but for the data reading part, i guess the tip is a ring-buffer[0]?
i guess that is benefitical for writing a "backup" to disk.
but do i really need/want it for real-time plotting?
Maybe there is a more efficient solution for your task, but a queue
(in this case a ringbuffer) is usually the simplest solution to these
types of tasks and it's also a solution that usually works good
enough.
hmm, i'll try to understand the basics first.
/me quickly "learns" c pointers
https://www.youtube.com/watch?v=mw1qsMieK5c
(cool-side-note: pointer++ automagically advances the right amount of bits!)
so i did (in jackplot code):
```
in = jack_port_get_buffer(input_port, nframes);
printf("%x\n", in);
```
and it gives:
```
efe54820
efe54820
efe54820
efe54820
efe54820
efe54820
efe54820
efe54820
efe54820
efe54820
```
does that mean jack writes here always to the same (starting) position in memory?
overwriting the old data?
if yes, this means when reading it somewhere else, we might get "wrong" data?
Yes, but the API does not guarantee this. You should at least copy the
memory to your own buffer before using it in a different thread. The
CPU overhead of copying the memory for each jack cycle does not
matter.
ps. i would also like to know where exactly - including technical terms - does the jack
process callback run? (trying to understand why it cant call opengl functions. not that i
want to run them there anymore though)
It's running in a realtime thread. If you do OpenGL directly in that
thread, data might not always be sent to the soundcard fast enough.