USB Audio VU meter

[infiniteimprobability]

Version: 1.1
Status: Alpha
License: BSD
Download: /files/project_builds/vu.zip

This project uses one of the low cost 128 x 64 OLED dsiaplays that can be found on ebay to give a VU meter for USB audio devices.
The display uses the SSD1306 controller IC connected via I2C and is connected to the XMOS MFA USB audio ref design.
It uses a function inline with the I2S loop to peak hold and decay. A separate task reads this info and sends it out to the display. It manages about 40 FPS (limited by I2C write speed @ 400Kbp) so quite a convincing effect. I tried and it does actually manage 1Mbps, but do so at your own risk!
Video here - www.youtube.com/watch?v=S7VSKjkmqRs
Video:

Images:

[infiniteimprobability]

Source code has been added. See readme.txt for guidance. You will need the USB Audio firmware first, which you can get from xmos.com (requires a license)

[infiniteimprobability]

I have extended the SSD1306 library to support printing text now (basic implementation currently but works).
Gives you a 21 x 8 line console, which can be used to redicrect printf etc.
If there is interest in this, let me know and I'll tidy it and post it.

[dweeb4]

I get errors during build:
../src/extensions/vu_task.xc:91:20: error: use of undeclared identifer `LEFT_VU'
        xscope_int(LEFT_VU, left_vu);                       //Show on xscope
 
../src/extensions/vu_task.xc:92:20: error: use of undeclared identifer `RIGHT_VU'
        xscope_int(RIGHT_VU, right_vu);
../src/extensions/vu_task.xc:97:20: error: use of undeclared identifer `LEFT'
        xscope_int(LEFT, left);
../src/extensions/vu_task.xc:98:20: error: use of undeclared identifer `RIGHT'
        xscope_int(RIGHT, right);

[infiniteimprobability]

Hi - sorry about that. It is just debuf stuff (so I was able to view the signals graphically in real-time). You can either comment those lines out, or try the updated version attached. The difference is that I have included config.xscope which describes the xscope probes referred to in those lines that caused error. 
 

[dweeb4]

Thanks - I didn't know it wa sthat simple a fix - from looking at the code (I'm only newe to this) I thought it was doing something integral to the VU meter calcs - didn't realise XScope was a JTag debugging tool. I've a lot to learn still :) 

[Cal1sto]

Search a way to run the vu_calc(sampleOut) inline function into an other logical core than the audio one , it seems that the lmul call take time on Audio part and destroy the data flow when i run my dac on PCM 768khz, without the both lmul call it run perfectly (with it will generate noise output) , so i search  a way to set this function into an other non blocking logical core, so the audio core will not be impacted by it, some idea there ?

[WilliamC]

Hi infiniteimprobability,
Thank you for share your project, I already implement it in my code and working well.

I have two questions on the below, please gave me your suggestion kindly.
1. How to get 4252200097(#define MUL_PWR_100_DIV_2P32) in vu_calc_inline.h? Could you explain more clear?
2. How to separate to get VU in Bass/Midrange/Treble?

Thank again...

[infiniteimprobability]

I have two questions on the below, please gave me your suggestion kindly.
1. How to get 4252200097(#define MUL_PWR_100_DIV_2P32) in vu_calc_inline.h? Could you explain more clear?

I think it's to do with the decay. After peak hold, we apply an exponential decay. In order to avoid a divide (expensive), we pre-calculate a fixed point multiply. The maths is 32b * 32b -> 64b. But we discard the lower 32b so 4252200097 / 2^32 = 0.9900424855 which is the decay value per iteration. 0.9900424855 ^ 100 = 0.368 which is pretty much 1/e.

2. How to separate to get VU in Bass/Midrange/Treble?

I would apply 3 biquads (low pass, bandpass and high pass) and run the vu 3 times. You will probably need to do this calculation outside of the main I2S loop. So you would forward the samples on to a DSP/VU task which would calculate the 6x VUs which would be picked up the I2C output task. It is certainly possible though with the architecture and all of the building blocks are available (eg. lib_dsp), although would be a bit of a squeeze in a single tile XS1 device. Using xCORE 200 you can use all 8 cores in a tile in USB so that would be a better option.

[Snoozer]

I have extended the SSD1306 library to support printing text now (basic implementation currently but works).
Gives you a 21 x 8 line console, which can be used to redicrect printf etc.
If there is interest in this, let me know and I'll tidy it and post it.

I'd appreciate if you could post this

thank you