Efficiently processing continuous signals?

bob_g4bby

Applications involving continuous signals such as music or software radios generally operate on buffers of data. All calculations must complete on average faster than the sample rate, else signal dropouts occur. Also it is desirable to minimise the delay between signal in and signal out.

To make an application as powerful as possible in a P2, maybe all 8 cogs need to be kept as near 100% loaded with tasks consistent with the above. Desirable 'features' are legion.

What algorithm for cog management have folks found works for them to achieve the above?

I'm familiar with Labview which operates on a dataflow principle, but wonder if that is o.t.t. for P2?

I guess this has been discussed long ago with P1? I've searched but not found it?

Cheers, Bob

bob_g4bby

I would like to use the HD audio add-on at maybe 48 ksample/s to give the user a decent chunk of radio spectrum on the display.

Processing would seem to split into two categories - signal path (fast) and user control (much less fast)

Christof Eb.

Hi @bob_g4bby ,
there is a a conflict of goals here, with audio processing no overrun is allowed. On the other hand you want the cogs to be loaded 100%. As far as I can see, you need something which is adjustable, for example if the quality of a result could be lowered. Or you could put cogs in a low power mode, if there is excess of work force. So you can adapt power consumption. Edit: You have 2 categories of tasks. You could do the user control in a variable pace to fill up to 100%.

I did some experiments which might be interesting here. Idea was that you have lots of small jobs to do. Put them onto a list, as soon as they are doable. There are "worker cogs" which grab the jobs from the list and mark them done. So there is no fixed mapping of tasks to cores.
https://forums.parallax.com/discussion/175422/p2-taqoz-v2-8-simple-automatic-multiprocessing#latest

I think the main advantage of the dataflow principle is, that it allows a meaningful graphical way of programming which allows scaling of the "map". Puredata / Plugdata https://plugdata.org/ use this principle too. (They are great!)

Daisy Seed and their library uses small buffers or single samples, Teensy Audio Library uses small buffers. The longer the buffer the better computer efficiency, because of the overhead of calling subroutines. They both use timer interrupts to pace audio tasks.

I have been thinking, that a compiler of Puredata patches to/in Forth must be possible as they use text files. :-)

I must say, that if you want to process one stream of data, than one single very powerful core like ARM M7 will be more suitable than to have 8 Cogs with limited Hub access. (Sorry)

Christof