Efficiently processing continuous signals?
bob_g4bby
Posts: 411
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
Comments
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)
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
Thanks for the comments, @""Christof Eb." I'm thinking about software radio again as my application:-
The signal path needs to guarantee completion before the end of every timeframe. The time, in clock ticks, for each stage of the signal processing can be measured. Each stage is packed into a specific cog in a set (say cog 0-N). It's a bit like packing your suitcase - it's an art to get everything in + have the required signals ready for each stage. If the application uses a vga, hdmi or similar display, then that is controlled here too. Probably all code here is PASM2.
The rest of the application, such as the UI, makes use of cog N+1 to 8. Cog hierarchy to achieve that might be "Conductor and orchestra", "Dedicated cog per hardware peripheral" etc. Many different hierarchies to be considered. In the main, if no cogs are currently available, that part of the program can stall until a cog comes free. This is not noticed by the user. Code here could be SPIN2 or PASM 2 or a mixture of both.
The above is new ground for me - the software radios I've tinkered with up to now have been Windows based. Here, the programmer relies on the scheduler built into the operating system to manage the various parallel processes going on. Such software radios load the processors very lightly, so that when Windows takes a large chunk of processor for a while, no loss of signal occurs.
I've been doing a bit of research and notice a number of papers relating to realtime multiprocessor scheduling. They are heavy reading!
For now, I'm going to proceed in a bottom-up fashion - writing the dsp objects required to do a basic radio, grounded on Gerald Youngblood's Powersdr application, which I still have VB6 source code for. I successfully converted that to Labview code many years ago.
Cheers, Bob
I'm a bit surprised this topic didn't receive much comment. I guess it's early days for P2 still - there aren't that many dsp applications written for it yet that would need fancy cog management.
All existing solutions tend to be focused on one cog for one job. And since there is no pre-emptive OS or kernel involved there is limited task management tools available.
Maybe Catalina has something, I've not delved enough into Ross's packages to know what's what there.
If your system has two lists for small jobs. One high priority dsp a list and one low priority ui b - list, then each worker cog can after competion of a job first look, if there is a a-job to do and then look for a b-job. Near the input and the output you will need a ring buffer to handle varying delays.
That sounds like a more simple idea worth experimenting with, @"Christof Eb." and, for sure, buffers play a big part in all of this.