Reduced volume with flanger demo

Reduced volume with flanger demo

Postby rascalmicro » Sat Aug 13, 2011 4:52 pm

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
Brandon Stafford
Rascal Micro: small computers for art and science
rascalmicro
 
Posts: 8
Joined: Sat Aug 13, 2011 4:19 pm
Location: Somerville, MA, USA

Re: Reduced volume with flanger demo

Postby rascalmicro » Sat Aug 13, 2011 4:58 pm

Oh, also, in attempting to understand the flanger code, I noticed a couple of funny things:
  1. It seems that temp3 is equal to temp1, i.e. they are both set to be equal to delaymem[x].
  2. It looks like temp4 is never initialized and no value is assigned to it. Seems weird.

Anyway, please don't take these as complaints-- I'm just trying to understand how this stuff works, and I'm new to audio stuff.

Brandon
Brandon Stafford
Rascal Micro: small computers for art and science
rascalmicro
 
Posts: 8
Joined: Sat Aug 13, 2011 4:19 pm
Location: Somerville, MA, USA

Re: Reduced volume with flanger demo

Postby guest » Sat Aug 13, 2011 10:09 pm

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

Code: Select all
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
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm

Re: Reduced volume with flanger demo

Postby rascalmicro » Sun Aug 14, 2011 4:57 am

Hi Mark/Dan/whoever is actually reading this,

Thanks for the responses.

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


Maybe add a paragraph on the wiki? http://wiki.openmusiclabs.com/wiki/AudioCodecShield

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


Ah, that makes sense. Is there a standard way of dealing with this, or do all flangers wipe out the signal at certain frequencies? It seems like it might be inevitable.

the if(++x == size)
increments to the next sample


I'm a moron-- I missed the ++.

As a general suggestion, perhaps the code could be made clearer by naming the variables after their function. For example, take the comment:
Code: Select all
// fetch delayed data with sinusoidal offset (temp2)

I'd think it would be reasonable to call temp2 something like sin_offset.

Anyway, I'm going to try to write code that reduces the dynamic range of music (I think people call that a compressor). Wish me luck!

Brandon
Brandon Stafford
Rascal Micro: small computers for art and science
rascalmicro
 
Posts: 8
Joined: Sat Aug 13, 2011 4:19 pm
Location: Somerville, MA, USA

Re: Reduced volume with flanger demo

Postby guest » Sun Aug 14, 2011 10:47 am

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
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm

Re: Reduced volume with flanger demo

Postby mcanulty » Sun Aug 14, 2011 4:23 pm

It's awesome to hear that you're getting into the code! Definitely consider uploading your stuff on the forum, and suggestions like variable name changes will get evaluated and hopefully implemented at some point. The C code is still young, so comments and implementable suggestions on the readability are helpful!
mcanulty
Site Admin
 
Posts: 63
Joined: Thu May 20, 2010 10:46 pm

Re: Reduced volume with flanger demo

Postby rascalmicro » Mon Aug 15, 2011 6:44 am

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
Brandon Stafford
Rascal Micro: small computers for art and science
rascalmicro
 
Posts: 8
Joined: Sat Aug 13, 2011 4:19 pm
Location: Somerville, MA, USA

Re: Reduced volume with flanger demo

Postby rascalmicro » Mon Aug 15, 2011 6:52 am

Hi Mark,

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


This is extremely useful. I wrote something last night that was successfully compressing the peaks, but it wasn't boosting the valleys. I'll try googling mu-law and a-law, and if those aren't enough, I'll try time-averaging.

Update:
http://en.wikipedia.org/wiki/M-law_algorithm
http://en.wikipedia.org/wiki/A-law_algorithm
http://en.wikipedia.org/wiki/Audio_level_compression

Thanks.

Brandon
Brandon Stafford
Rascal Micro: small computers for art and science
rascalmicro
 
Posts: 8
Joined: Sat Aug 13, 2011 4:19 pm
Location: Somerville, MA, USA

Re: Reduced volume with flanger demo

Postby rascalmicro » Mon Aug 15, 2011 7:23 am

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:
Code: Select all
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
Brandon Stafford
Rascal Micro: small computers for art and science
rascalmicro
 
Posts: 8
Joined: Sat Aug 13, 2011 4:19 pm
Location: Somerville, MA, USA

Re: Reduced volume with flanger demo

Postby guest » Mon Aug 15, 2011 7:07 pm

i was concerned that people wouldnt know what a macro was
or that it would be more confusing to introduce more lingo

if you dont use the macros
it takes 4 times as long to do a multiply
which basically eats up almost all of your time

it sounds like the explanation in the read_me file
didnt do a very good job of showing how to use the macro
guest
Site Admin
 
Posts: 449
Joined: Thu May 20, 2010 11:58 pm

Next

Return to Audio Codec Shield

Who is online

Users browsing this forum: No registered users and 1 guest


cron