bfin simulator for linux/jack

[ghost]

grains dev was somewhat frustrating before I started developing dsp blocks offline using hand-rolled emulation of blackfin primitives. Couldn't make dsp/null go so I just started hacking. By the time grains was declared done, the simulator seemed to be covering all the blackfin s32 built-ins pretty well. s16 built-ins should also be easy. The result is here:

https://github.com/rick-monster/aleph/tree/dev/modules/grains/bfin_emu

Can't currently load entire modules - was just chucking in random dsp blocks and code changes to tweak things. I'm proposing an OSC layer which compiles against param.c to get the following things for each param.

• url from desc[N].label
• accepts any s32 between desc[N].min & desc[N].max, then schedules a call to module_set_param start of next jack audio block.

Once this is done the params of a running prototype module can be tweaked on-the-fly from, for example, common lisp repl in order to test things...

2 things kind of holding this back:

• wondering how the new block processing will change the makeup of aleph modules.
• not currently developing any new dsp module so no immediate need. As soon as the next module project is underway this will become a top priority

[catfact]

i checked in some early versions of block processing to the dev branch. still needs a little work, but mostly in the library layer. module API might have minor changes but is pretty much as you'd expect:

https://github.com/tehn/aleph/blob/dev/bfin_lib_block/src/audio.h https://github.com/tehn/aleph/blob/dev/bfin_lib_block/src/module.h https://github.com/tehn/aleph/blob/dev/modules_block/rawsc/module.c

possible tweaks:

• if we eliminate copy-and-shift step in the audio block ISR, buffers will contain 24b data (in the same format, but requiring shifts.)
• one opinion is that we should pass blocksize as an argument to the processing function. (don't know if i agree agree since it will only ever change at compile time.)

[ngwese]

one opinion is that we should pass blocksize as an argument to the processing function. (don't know if i agree agree since it will only ever change at compile time.)

if that other opinion was me consider it retracted. as long as there is a means to change the blocksize on a module by module basis (at compile time) then passing it around seems like a waste. i'd have to imagine if blocksize was a (small) constant known at compile time some loop unrolling might happen...

[ghost]

ok so based on comments & having briefly skimmed the new block processing code it looks like business as usual for the sample-by-sample API - next step would be to get some OSC examples cooking inside a C jack app.

Going to try liblo first... http://liblo.sourceforge.net/

Initially the goal is emulate sample-by-sample API. Then block processing can sit on top of sample-by-sample on linux/jack rather than trying to make jack frames line up with bfin frames. No performance considerations for now - it's purely for aleph prototyping using tools from the linux ecosystem.

In future we can also run aleph modules on embedded linux, in which case somehow try to match up block sizes (probably also at compile-time)

[ghost]

got this cooking now!!! Just managed to cross-compile dacs module against emulator code out on a feature branch with bfin params hooked up to OSC - still time for a quick test tonight...

hah - dacs doesn't even have audio in/out. Bit too useless for a test

[ghost]

ok the module mix.c compiles & no problem randomly pinging it with osc messages from lisp & can see/hear it works fine. smashed on the grains module cross-compile a little bit & got that going too. It's crapping out with segfault in the cubic interpolation somewhere - most probably circ pointer emulator is not quite right...

[ghost]

Just fired up grains module in the simulator - got pitch-shifted audio for a little while but seems to be some extra numerical errors in emulator making something drift out of operating range (probably in filter code I guess). Next step could be test out the dubious emulation of mult_fr1x32x32 directly against a running device using a dedicated mathcheck module & bees serial commands...

[ghost]

successfully cross-compiled mix, dacs, waves, lines, grains. Dsyn is a little fiddlier because there's a bunch of linux compiler directives already lying around in there ( I guess left over from the prototype). Remaining points to finish off bfin emulator:

• make mult_fr1x32x32 reflect bfin hardware accurately (can add some multiplication-testing params to analyser module)
• cross-compile analyser
• flesh out fr1x16 primitives

[catfact]

nice!

i kind of hate to bring this up, but... for the new round of modules i am trying to make more use of the bfin DSP library... these are optimized ASM chunks that are included in the toolchain and do nice things like FFT, IIR and FIR filters... https://blackfin.uclinux.org/doku.php?id=toolchain:libbfdsp

[ghost]

Well even a feature-incomplete emulator is kind of neat, right? I think there are a lot of quick little fun module ideas that could be done even without the more advanced DSP algorithms (fun when you have access to gdb, anyway). Besides, emulating all that extra stuff might be more manageable than it sounds. Can always just flick to/fro double-precision floating-point for emulation, chucking away as many bits as required to get close to the real thing...

[ghost]

Leaving this open for now...

in order to finish this as much as possible, let's go through the list of instructions here: https://blackfin.uclinux.org/doku.php?id=toolchain:built-in_functions make sure none of the basics are missing, then call this feature 'done'.

Don't think it's sensible investment of time to port the optimised ASM stuff to linux, but sure is helpful being able to debug fract versions of floating-point algorithms on a 'real' computer...