Audio Effects DSP Board

[micromegas]

I may be asking something someone asked before, but... are you going to sell these? If that's the case, I would love to get one. I've been wanting to try the XMOS family for quite long

[markseel]

Yes, I want to get these boards out to folks but I'm not sure how to do that yet.  Making them one-by-one is a bit of a pain   I'll try to make a few here and there and sell in small quantities until I can get a small production run figured out.

[Digital Larry]

Hi Mark,

I am thinking about how SpinCAD could be adapted to this platform.  At the highest level, there is an idea of representing DSP functional blocks with input and output connections, both audio control, and popup control panels to set static aspects of that block (e.g. maximum delay time).  For the FV-1 it's straightforward because there's only one "thread" so to speak, and I can easily connect something at the beginning of the chain to the very end (for example, "dry" mix).

You have described the Xmos system as working on a number of separate threads which get executed in order (I think).  So my question is, how would I go about passing a signal from the first block (ADC input) to very nearly the final block (wet/dry mix prior to DAC)?

DL

[markseel]

Moving samples from one thread to another is handled automatically by the provided framework.  The code in each thread then is only concerned with DSP and not with moving audio data around.

The basic model is that seven threads all work at the same time on different samples to form a data-flow pipleline.


ADC--->(Sample N)--->Thread1--->(Sample N-1)...--->(Sample N-7)--->Thread7--->(Sample N-8)--->DAC


With seven cores/threads there's seven samples (or more specifically sets of samples representing left,
right and two auxillary channels) ordered in time being worked on simultaneously.

The sample from the ADC is sent to thread1, thread1 output is sent to thread2 input, ...
thread6 output is sent to thread7, thread7 output is sent to the DAC.  This complete cycle
occurs once *every* audio cycle (at 48 kHz).

This is how we achieve such high DSP bandwidth; by operating seven 100 MIPs cores/threads
all at the same time but working on it's own sample in the dataflow.


Audio   |   Sample number being processed in each thread ...
Cycle   |   ADC       Thread1   Thread2    ...   Thread6   Thread7   DAC
--------+-------------------------------------------------------------------
N+0     |   N+0       -         -                -         -         -   
N+1     |   N+1       N+0       -                -         -         -
N+2     |   N+2       N+1       N+0              -         -         -
N+3     |   N+3       N+2       N+1              -         -         -
...     |
N+8     |   N+8       N+7       N+6              N+2       N+1       N+0
N+9     |   N+9       N+8       N+7              N+3       N+2       N+1

[Digital Larry]

If I catch your drift then, ADC input could be passed through the other blocks and arrive at the last core 7 or 8 sample ticks later?

[markseel]

That's right, with that illustration there would be a minimum 8 sample delay from ADC to DAC.  But keep in mind that the samples that go in to thread 1 and that come out of thread 7 are actually routed as follows where the seven threads we're talking about comprise the [effects] block below:


[Guitar (ADC)]-----+-------------------------[Mixer2]---->[USB In]
                   |                            /\
                   |                            |
                   \/                           |
                [Mixer1]--->[Effects]--->[Spatialization]
                   /\                           |
                   |                            |
               (Left Ch.)       +---------------+
                   |            |
                   |            \/
[USB Out]----------+-------->[Mixer3]--->[GraphicEQ]--->[Volume]--->[Line Out (DAC)]


So total delay from ADC to DAC is eight sample periods (less than 0.167 milliseconds with Fs = 48 kHz) for the [effects] plus the group delay through the AK4556 ADC and DAC (17+21 samples or 0.8 milliseconds) plus any other delays added by [Mixer1], [Spatialization], [Mixer3], and [GraphicEQ] blocks that are part of the framework and therefore in the audio path by default.  Total delay then for this effects framework is less than 1 msec.

Here's an idea.  I could also offer a more minimal framework that omits the mixers, eq and spatialization DSP code.  That would then look like this:

[Guitar (ADC)]-----+       +---->[Line Out (DAC)]
                   |       |
                   |       |
                  \/       |
              [Effects]----+
                  /\       |   
                   |       | 
                   |       |
[USB Out]----------+       +---->[USB In]


Notice from the previous code sample (earlier post) that the four samples passed in to and out of the function (for every audio cycle).  With this simpler default audio path definition the audio processing thread function arguments would then be defined as as ADC/DAC left, ADC/DAC right, USB out/in left, USB out/in right allowing you to mix any time (in any thread) as you see fit.  So using the example code for the LFO, Chorus and Tone control from a few postings ago ... see the comments below that call out the meaning of the four audio samples pass in/out.

// audio_sample[0] is left channel ADC (incoming) sample and left channel DAC (outgoing) sample
// audio_sample[1] is right channel ADC (incoming) sample and right channel DAC (outgoing) sample
// audio_sample[2] is left channel USB (incoming) sample and left channel USB (outgoing) sample
// audio_sample[3] is right channel USB (incoming) sample and right channel USB (outgoing) sample

void audio_thread_2_exec( int audio_samples[4], const int property_data[6] )
{
    // Process the ADC/DAC left channel audio sample for the current audio cycle.
    // The right ADC/DAC channel and USB audio channels are not modified.

    efx_lfo1_run(); // Update LFO value
    sample[0] = efx_chorus1_run( sample[0] ); // Apply tone shaping to left audio channel
    sample[0] = efx_tone1_run  ( sample[0] ); // Apply chorus effect to left audio channel

    // Give effects objects an opportunity to update parameters if property data applies

    efx_lfo1_update   ( property_data );
    efx_chorus1_update( property_data );
    efx_tone1_update  ( property_data );
}

[Digital Larry]

Mark, How many all pass filters would that thing hold do you think?  I have an application that seems to want a couple hundred.

DL

[micromegas]

Mark, How many all pass filters would that thing hold do you think?  I have an application that seems to want a couple hundred.

DL

Spectral delay? 

[Digital Larry]

cyletax!

[micromegas]

cyletax!

I need to give a try to that kind of implementation. Tried to code a plugin on JUCE using the fftw3 but the way it works gave me more than a headache and the project ended up in the bin...

[Digital Larry]

Here is a really wild sounding spectral delay implemented in Pure Data.  I ran it on my PC.

https://guitarextended.wordpress.com/2012/02/07/spectral-delay-effect-for-guitar-with-pure-data/

[Digital Larry]

Hi Mark,

I'm trying to get going on Ubuntu Linux, following Mac instructions.

Code Select Expand

gary@gary-Latitude-E6420:~/SimpleFX/FlexFX$ ./build.sh main
xcc: dsp.c: No such file or directory
xcc: flexfx.xc.o: No such file or directory
gary@gary-Latitude-E6420:~/SimpleFX/FlexFX$ ls *.c
main.c

Missing a few files apparently.  As I have something that I can't currently accomplish on an FV-1 I really want to give this a look ASAP.

Thanks,

Gary
er, I mean Larry   

[micromegas]

Here is a really wild sounding spectral delay implemented in Pure Data.  I ran it on my PC.

https://guitarextended.wordpress.com/2012/02/07/spectral-delay-effect-for-guitar-with-pure-data/

That's the one I tried to base my plugin on! The interface is nice but not so easy to control and I was trying to accomplish something more intuitive. The fftw3 got in the way and I was running out of time so ended up coding a multiband-multitap delay.

[markseel]

Hi 'Larry' -

I'm trying to get going on Ubuntu Linux, following Mac instructions.

Doesn't look like the environment variables are set.  Did you execute the 'SetEnv.command' script in the XMOS installation directory?

Mark, How many all pass filters would that thing hold do you think?  I have an application that seems to want a couple hundred.

For a first order allpass of perhaps y[n] = a*y[n-1] + x[n-1] - a*x[n] we'd have two MAC's and an ADD per sample.  We can execute 500 to 600 FIR taps per core (one MAC and one delay line update) so dividing that figure by two or three might be a good first estimate.  That puts us at about 200 1st order all-pass filters per core.

[Digital Larry]

Folders are a bit different than you showed, but:

Code Select Expand

gary@gary-Latitude-E6420:~/SimpleFX/FlexFX$ source ~/XMOS/xTIMEcomposer/Community_14.2.0/SetEnv
gary@gary-Latitude-E6420:~/SimpleFX/FlexFX$ ./build.sh main
xcc: dsp.c: No such file or directory
xcc: flexfx.xc.o: No such file or directory
gary@gary-Latitude-E6420:~/SimpleFX/FlexFX$ ls
build.bat              uac2_bulk.xc.o          xud_io_loop.s.o
build.sh               uac2_control.xc.o       xud_manager.xc.o
core_dsp.c.o           uac2_device.xc.o        xud_phy_reset_user.xc.o
core_peripherals.xc.o  uac2_dfu.xc.o           xud_ports.xc.o
core_system.xc.o       uac2_main.xc.o          xud_power_sig.xc.o
dsp.h                  uac2_midi.xc.o          xud_set_crc_table_addr.c.o
lib_assert.xc.o        xud_client.xc.o         xud_set_dev_addr.xc.o
lib_gpio.xc.o          xud_crc5_table.s.o      xud_setup_chan_override.s.o
License.md             xud_device_attach.xc.o  xud_support.xc.o
main.c                 xud_ep_funcs.s.o        xud_test_mode.xc.o
main.xn                xud_ep_functions.xc.o   xud_uifm_pconfig.s.o
README.md              xud_get_done.c.o        xud_uifm_reg_access.s.o
uac2_audio.xc.o        xud_glx.xc.o            xud_user.c.o
uac2_buffers.c.o       xud_io_loop_call.xc.o



200 all-passes per core sounds pretty promising!

[markseel]

Oh OK.  My bad.  Edit 'build.sh' and remove 'dsp.c' from the list of files to compile/link.

[markseel]

I should add DSP library code for all passes then.  Cascaded all-passes would be good to have, true?  This would help to minimize error since the sections would be cascaded (internal to the library) such that the 64-bit accumulator is maintained for each section rather than being truncated to 32-bit after a single section.

[Digital Larry]

Cascaded all passes would be awesome.  Keep in mind (maybe it's obvious) that I would be using "stretched" all passes, namely width more than one memory element, and in the ideal case, they'd be dynamically adjustable with inter sample interpolation.  At your convenince of course.   

[markseel]

I'm not familiar with those but I'm sure I could code them up after some reading.  Have a good link or two on how they work?  This looks good: http://dafx09.como.polimi.it/proceedings/papers/paper_36.pdf

[Digital Larry]

Exactly what I had in mind!   

It's like the all pass stages used in FV-1 reverbs.

Still missing:

flexfx.xc.o

I tried removing the reference in build.sh and wound up with a ton of Undefined References,

Thx,

DL