Open Music Labs Forums

Hi,

Just got my audio codec shield a couple of days ago, and I've just been trying to get it going with an Arduino this afternoon. Took me a little bit to figure out that I should put the Audio Codec Shield in the Arduino/Libraries folder, but after I figured that out, it works beautifully. Congratulations on making something that works!

In trying out the different examples, I notice that the flanger reduces the volume of the signal as it passes through the shield. Is this what's expected? Is the volume decreased by a constant factor?

Brandon

thanks for the feedback

the whole library issue is a bit frustrating
but im not sure how to make that better
perhaps a small tutorial on where to place them

as far as the flanger is concerned
it may reduce volume in some cases
as it mixes a delayed version to the original
and if they are out of phase
this will be a subtraction

if you look at the temp3 issue

temp1 = delaymem[x];
// fetch next delayed data for interpolation
if (++x == SIZE) { // check for buffer overflow
  x = 0;
}
// we need some more temp variables
int temp3;
int temp4; 
temp3 = delaymem[x];

the if(++x == size)
increments to the next sample
so the next time delaymem is called
its at the next sample

cool
best of luck with the compressor

sorry about the confusing c refrences
im new to the whole c thing

there are two different ways of doing compression
one is just with a lookup table and interpolation
this is basically how early telephones did it
they had different lookup tables
mu-law and a-law were the common ones
and they used them to get better dynamic range
out of the a to d converters

the other sort is used in studios and cellphones today
and its a dynamic compressor
or automatic gain control circuit
and these try to keep the output signal at the same level
regardless of the input signal
so it takes a short term average of the rms signal
and uses that to set the amplification factor

Hi Dan,

Definitely consider uploading your stuff on the forum

Here are a few bits that you can use or not use as you like.

Edit: actually, I think I'll post this stuff in its own topic, as it has nothing to do with the flanger demo any more. By the way, I figured out why my volume was unexpectedly low-- it was because one of the connectors in my right_in line was bad.

Brandon

The C code is still young, so comments and implementable suggestions on the readability are helpful!

Here's one other code suggestion. In AudioCodec_readme.txt, you explain how your fast multiply functions work. However, the "functions" are actually macros, not functions. In this case, the distinction actually matters, because functions can't alter the variables that are passed to them, while macros can.

Someone looking at code like this:

MultiSU16X16toH16(result, input1, input2)

If that's a real function, no result will be returned. This confused the hell out of me until I found the link in your source code back to the original author, Norbert Požár: http://mekonik.wordpress.com/2009/03/18 ... plication/

He says:

The functions are implemented as macros. This means that you have to call them in a little bit different manner than regular C functions. For example, using signed 16bit x 16bit -> 32bit multiplication is performed by:

int x = 12;
int y = -32;
long result32;
MultiS16X16to32(result32, x, y);
Also, this means that the whole multiplication code is included at every place that you use a macro. This can be undesirable if you are using one macro many times. Of course, you can write your own stub function, for example:

long FuncMultiS16X16to32(int x, int y) {
long result32;
MultiS16X16to32(result32, x, y);
return result32;
}

I'm not sure what the performance penalty is for implementing these macro-wrapping functions, but it might be worth it to avoid confusing the average C programmer like me, who has to look up the difference between a function and a macro in a book before he knows what's going on.

On the other hand, maybe just some comments in the code alerting people to the presence of macros might be enough.

Brandon

I'm not sure what the performance penalty is for implementing these macro-wrapping functions, but it might be worth it to avoid confusing the average C programmer like me, who has to look up the difference between a function and a macro in a book before he knows what's going on.

On the other hand, maybe just some comments in the code alerting people to the presence of macros might be enough.

Yeah, to get the arduino to handle audio, getting the best performance possible out of the micro is essential. So the macros and such are designed to help keep the code efficient partly by the way they unravel into explicit commands rather than creating a jump in the code.

If you're like me, you'll find that getting into this kind of coding is a huge eye opener in understanding the way C works in a really fundamental way, and even though that sounds really scary, I've found it kind of fun really. Good suggestion on making the language a bit clearer, and maybe we can post further comments on macros in a new thread for future readers who are scratching their heads.

good catch
its 4x doing a normal mutiply
a function wrapper shouldnt incur too much loss
as long is its still an inline function