I tried searching on google, but I need to apply “effects” as in mathematical equations (especially sine waves) for around 8192 values. All of this should ideally be around a few milliseconds, but should not take longer than 10ms.

Similarly, I need to run Input on 8192 values too. This most likely will happen with memcpy, from one array to another, but this might take longer as it can have multiple inputs (network/serial/usb).

In this case, I have to guarantee, that both steps before outputting do not take longer than around 25 ms.

Is there a way to definitely limit these functions to timeframes, so they will be killed/returned if taken to long?

I cannot spawn new threads for each input/effect step, as it takes some time to build these threads. Both methods will be called in a loop, directly after another, so they will run approx. 30-45 times a second.

Whats the way to limit these? I can surely guarantee the read-time where I copy a buffer, but running maths operations seems like something that could potentially take too long.

Realtime-Operating Systems also can somehow guarantee those times, so whats the way here?

(BTW, this all is going to run on a minimal debian linux system, with the GUI decoupled from the actual mehhanism.)

One of my ideas would be to pre-calculate those values in some other thread, lets say the next 100 ops for a given value and then just replay them, so I have some buffer.

Other ideas?

  • Gandalf1783@feddit.deOP
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    In general, dropped frames/effects that either take too long or are lost are not inherently bad, since theres another one in just 10-20ms.

    Its just that I want to make sure that these function are not taking literal seconds or longer.

    But thanks, I already feared this was the case. I will take a look on an RTOS, I just havent read far into it and therefore dont know how you would code something against that.

    Thanks anyways!

    • deegeese@sopuli.xyz
      link
      fedilink
      arrow-up
      5
      ·
      edit-2
      1 year ago

      Writing your own FFT or something?

      If your function gets called every 40ms, design it so that it normally completes in 20ms and use a buffer of a couple batches. Should work fine unless some other process monopolizes all the cores.

      edit: I noticed you need data from external sources with high latency. You need to put the data read in it’s own thread so that processing current data doesn’t get held up by latency reading new data.

      • Gandalf1783@feddit.deOP
        link
        fedilink
        arrow-up
        3
        ·
        1 year ago

        Nope, to be specific, my application is going to apply many effects onto light sources (DMX).

        Those effects are going to be sine/cosine, pwm, triangle and more. Those make my head hurt most, especially since I cannot predict how long the calculation takes for the 8192 values (512 channels times 16 universes, this can/will expand to even more, e.g. 512 channels times 128 universes).

        Those output-frames need to be fluent, e.g. it should not lag (-> high refresh-rate, max allowed is around 40-45 Hz).

        Currently, Im running in lockstep, e.g. a single thread decoupled from the parent which first has to run inputs (e.g. network input, etc. and then has to apply effects (e.g. math operations) on many thousands of parameters.

        While I only need 8 bit precision per channel ( a channel is a single byte), some devices may take 2 channels for fine control (e.g. 16 Bit), where my accuracy has to be higher.

        I think that I can remove the inputs, I can just decouple them into another thread and just update some shared buffer, where it can be always read regardless of how long the input method actually takes.

        Btw, while technically there can be multiple effects running (e.g. a sine on channels 1-12, a triangle on 32-35), no channel will ever have multiple effects. So I am technically always computing max. 8192 (or however many universes times 512) values.

        I cannot post code yet (still have to tidy up the codebase), but it will be open source later on.