Hi,

I am working on a project where the output is a 24 bit audio signal.
I am using an FPGA chip to generate this audio signal.
The input to the FPGA is a frequency value ( anywhere between 400hz to
10,000hz).
Inside the FPGA, the frequency is converted to its amplitude by giving
it to a sine look up table.
The output 'A'is then manipulated in such a way( dividing it by 2)
that the amplitude increments by a constant value ( for eg: 6 dBFS)
The output 'A' is manipulated and given out of the FPGA as a serial
data ( 24 bits)
This 24 bit audio ouptut seems to have the correct frequency
information.

What I would like to know is..if this method is correct:that by
dividing this output 'A' by a constant value 2, does it give a change
of 6dBFS

If so, would dividing the 'A' by 1.122 give me a change of 1dBFS?

Or is there any other logic behind this?

Any kind of help would be highly appreciated.

Thankyou

genlock wrote:
Hi,

I am working on a project where the output is a 24 bit audio signal.
I am using an FPGA chip to generate this audio signal.
The input to the FPGA is a frequency value ( anywhere between 400hz
to
10,000hz).
Inside the FPGA, the frequency is converted to its amplitude by
giving
it to a sine look up table.
The output 'A'is then manipulated in such a way( dividing it by 2)
that the amplitude increments by a constant value ( for eg: 6 dBFS)
The output 'A' is manipulated and given out of the FPGA as a serial
data ( 24 bits)
This 24 bit audio ouptut seems to have the correct frequency
information.

What I would like to know is..if this method is correct:that by
dividing this output 'A' by a constant value 2, does it give a change
of 6dBFS

If so, would dividing the 'A' by 1.122 give me a change of 1dBFS?

Or, multiply by the reciprocal, 0.8913, whichever is more
convenient.

Or is there any other logic behind this?

That'd be about it.

However, I assume you are aware of the fact that any time you
perform an operation that could potentially involve truncation
or any other loss of data, you are at risk for introducing
quqntization artifacts. The simplest way to avoid this is to
dither the result before truncation. More sophisticated schemes
could involve noise shaping and similar.

What I want to do is vary the audio amplitude from 0dBFS to -30 dBFS in

increments of 1 dB....


The audio amplitude is represented by a 24 bit binary value


This is the output of the FPGA


The input to the FPGA is the frequency information


Whats happening inside the FPGA is that the frequency is converted to
its amplitude


This amplitude value is given to a variable "sample" which is 24 bits


When sample is taken as the 24 bit output, its showing a value of 0dbFS



What manipulation should I do to this "sample" to make it change in
steps of 1?


thankyou

genlock wrote:
What I want to do is vary the audio amplitude from 0dBFS to -30 dBFS
in
increments of 1 dB....

The audio amplitude is represented by a 24 bit binary value

Presumably, it's a 24 bit signed integer, yes?

This is the output of the FPGA
The input to the FPGA is the frequency information
Whats happening inside the FPGA is that the frequency is converted to
its amplitude

Well, I don't know how a "frequency is converted to its amplitude."
I presume this to mean that givena frequency, the FPGA will outout
a series of values at regular intervals (the sample rate) at the
appropriate amplitude for that given instant of the output function,
a sine.

This amplitude value is given to a variable "sample" which is 24 bits
When sample is taken as the 24 bit output, its showing a value of
0dbFS
What manipulation should I do to this "sample" to make it change in
steps of 1?

Since 1 dB represents a change, relative to the normalized
amplitude, of 0.89125..., you'll need to multiply the values
you're outputing from you sine-wave generating function (or
lookup, however you want to do it) by appropriate amounts.

If it were me, I'd have a simple lookup table of gain coefficients.
The amount of attenuation applied is simply an index into that
table. A gain of 0 would look at the zeroth entry of the table
and that would return a normalized gain of 1. A gain of -1 dB
would look at the first entry, and it would have a normalized
gain of 0.89-15, a gain of -2 dB would look at the second entry,
where an normalized gain of 0.79432 resides, and so on. So,
there's NO run-time math involved in generating the gain
coefficienct.

Now, to get your gain adjusted signal, simply multiple the
instantaneous amplitude by the gain coefficient. And you're done.

But NOT quite!

If you're output is going to remain in 24 bit integer format,
you WILL have to truncate the result, and that throws away
information. That leads to the introduction of quantization
artifacts which WILL be audible. TO eliminate those artifacts,
you have to at least apply dither BEFORE you truncate the result
back to 24 bits.

In the simplest effective implementation, the dither consists
of a random number whose amplitude distribution is triangular
and whose amplitude is around 1 signifcant bit of the final
word length. THat random value is added to the gain-adjusted
amount, then the result is truncated down to 24 bits. That's
your final output.

This is all pretty standard signal processing stuff which you
should be able to find in any number of references.




thankyou

Yes, the audio amplitude is represented by a 24 bit

When I say that "frequency is converted to amplitude"....what you have
explained is correct...thats what is happening inside the FPGA....can
you explain this process or give me some reference where I could get a
detailed explanation ....

The technique for getting the output, you are talking about is what I
have tried

And I have also truncated the gain adjusted amount to 24 bits ( the
MSB).

I havent done any dither adjusment though

Are you saying that doing the dither adjustment would give the correct
output of -1dBFS, -2dBFS respectively?

How do we select a random number for the dither?....What do you mean by
the amplitude distribution being triangular....

Is there any website or book that I can refer to...

Thankyou

genlock wrote:
Yes, the audio amplitude is represented by a 24 bit

A 24 bit WHAT? Signed integer? fixed point? is it 24 bit precision
in a 32 bit float? what?

When I say that "frequency is converted to amplitude"....what you
have
explained is correct...thats what is happening inside the FPGA....can
you explain this process or give me some reference where I could get
a
detailed explanation ....

Uh, since this seems to be YOUR project, I was hoping you'd
already know. I assumed you were programming some FPGA to do
this.

The technique for getting the output, you are talking about is what I
have tried

And I have also truncated the gain adjusted amount to 24 bits ( the
MSB).

I havent done any dither adjusment though

Are you saying that doing the dither adjustment would give the
correct
output of -1dBFS, -2dBFS respectively?

No, I am saying that ANY TIME you have to truncate the precision
of the output stream, you MUST dither to eliminate quantization
artifacts.

Look gain adjustment is, in essence, a multipliciation. Multiplying
extends the precision of a number. If, for example, you have a 24
bit value, and you multiply it by a 16 bit normalized gain coefficient,
you will end up with a 16+24 or 40 bit result. But you want 24, so
you have to truncate the 40 bit result by throwing away the bottom 16
bits. But those 16 bits, even though they are in the LSB side of the
value, represent real data. Dithering is ONE way of preserving that
data.

How do we select a random number for the dither?....

You have an algorithm that generates random numbers. Simple as
that.

What do you mean by
the amplitude distribution being triangular....

Most simple random number generator algorithms give results that
have rectangular probility distribution. That means that over its
range, there is an equal probability of getting one number as
getting any other. Plot probability vs value, and you get a
rectangular-looking graph

Triangular probability distribution means that you have the highest
probability of getting a value in the middle of the range, and the
probability decreases linearly as you approach the extremes of the
range from the center. Plot probability vs value, and you get a
triangular looking graph.

Now, if you have two uncorrelated rectangular random number sources,
and you simply add the two, you will, over the long term, get random
numbers with a triangular probability distribution.

Now, lets look at a pseudo code implementation. Assume you have
a function SineGen which returns your 24 bit signed inteher sample
value. Assume you hand it a time t, form which it generates its
value. Also assume you have a function called GainCoeff which returns
a 16 bit signed positive normalized gain value, meaning that a
gain of 1 = 0x7FFF (32767), a gain of -1 dB is 0x7214 (29204),
-2 dB is 0x65AC (26028) and so forth (your -30 dB gain would be
0x40C or 1036)

And further assume you have a function, TPDrand, which returns a
16 bit signed integer random number with triangular probability
distribution. Your gain control algorithm would look something
like:

t = 0;
for (;
{
// Derive the gain adjusted signal value
outVal = SineGen(t) * GainCoeff();
// the result is a 40 bit signed int value
// dither it by adding a TPD random value
outval += TPDrand();
// Truncate to the top 24 bits
outval &= 0xFFFF00;
// Normalize by shift right 16 bits
outVal = 16
// outVal now holds the gain adjusted, dithered
// 24 bit instantaneous sample value
}

Is there any website or book that I can refer to...

for what? It's a VERY big topic, and unless you can be more specific
as to what you're trying to do and why, it's hard to point to any
one site or book.

1)A 24 bit WHAT? Signed integer? fixed point? is it 24 bit precision
in a 32 bit float? what?

Its represented by a 24 bit binary value (integer).

2)Uh, since this seems to be YOUR project, I was hoping you'd
already know. I assumed you were programming some FPGA to do
this.

The problem here is that even though I am working on this project, it
was initially done by somebody else...I have taken it up from the
middle and unfortunately that person isnt around to find out what
exactly he has done

Yes the programming has been done inside the FPGA where the frequency
info is taken as an input ( "theta"). Inside the module, we calculate
sin (x)

where x= theta * ( 2 pi/ 2 ^ theta_width) radians

theta_width is 10 bits wide in this case

sin(x) is what is given to "sample"

I was asking you about the process goin on here


3) In the pseudo code implementation that you are talking about,
SineGen would produce this "sample"

If I am understanding correct, you are saying that we can use a dither
value of 16 bits as well as Gain value of 16 bits right

Thankyou very much for this algorithm

I am going to try working this out to see if I am getting the correct
values as outputs.

Also assume you have a function called GainCoeff which returns
a 16 bit signed positive normalized gain value, meaning that a
gain of 1 = 0x7FFF (32767), a gain of -1 dB is 0x7214 (29204),
-2 dB is 0x65AC (26028) and so forth (your -30 dB gain would be
0x40C or 1036)

How did you exactly arrive a the vlue 29204 for -1dB?

genlock wrote:
1)A 24 bit WHAT? Signed integer? fixed point? is it 24 bit precision
in a 32 bit float? what?

Its represented by a 24 bit binary value (integer).

Is it a 24 bit SIGNED integer?

2)Uh, since this seems to be YOUR project, I was hoping you'd
already know. I assumed you were programming some FPGA to do
this.

The problem here is that even though I am working on this project, it
was initially done by somebody else...I have taken it up from the
middle and unfortunately that person isnt around to find out what
exactly he has done

That's why everyone who works for me has to supply code with whaty
I consider to be adequate documentation or else they get fired.

Yes the programming has been done inside the FPGA where the frequency
info is taken as an input ( "theta"). Inside the module, we calculate
sin (x)

where x= theta * ( 2 pi/ 2 ^ theta_width) radians

theta_width is 10 bits wide in this case

sin(x) is what is given to "sample"

I was asking you about the process goin on here


3) In the pseudo code implementation that you are talking about,
SineGen would produce this "sample"
Okay.

If I am understanding correct, you are saying that we can use a
dither
value of 16 bits as well as Gain value of 16 bits right

I was merely using 16 bits as an example of one possible
implementation. It could just as easily be an 8 bit gain
and 8 bit dither, though you would have less gain accuracy.

I am going to try working this out to see if I am getting the correct
values as outputs.

Well, let me ask a question: how do you know if you have the
right values or not?

genlock wrote:
Also assume you have a function called GainCoeff which returns
a 16 bit signed positive normalized gain value, meaning that a
gain of 1 = 0x7FFF (32767), a gain of -1 dB is 0x7214 (29204),
-2 dB is 0x65AC (26028) and so forth (your -30 dB gain would be
0x40C or 1036)

How did you exactly arrive a the vlue 29204 for -1dB?

Uh, pretty simple.

Let's start from the beginning. We have stated that our gain
coefficient will be a positive 16 bit integer whose highest
positive value will correspond to a gain of 1. The highest
value a 16 bit signed integer can take on is 32767. That, in
our notation, is 1.

Now, we both agree that a gain of -1 dB corresponds to a gain
coefficient of 0.89125, right?

Fine, what's 32767 * 0.89125? Well, try it, it's 29024!

And if -2 dB corresponds to a gain coefficient of 0.79433,
then the normalized gain coefficient is 32767*0.79433 which
equals 26028.

But, instead of doing the multiplication of 32767*10^(atten)
every time you want to get the normalized gain coefficient,
I'd just precalculate the stuff and stick it in a lookup
table: makes it VERY fast and simple to get.

I'm happy to try to help someone out when they need it. However, and I
hope you don't take offense as none is intended, I think you need to do
some significant homwework on the fundamentals. I have, to this point
invested nearly an hour in answering your questions. And, as I said,
while I am happy to help, it is my opinion your probably going to need
a significant amount of assistance and guidance in order to solve your
technical problems. Normally, this is the kind of technical support and

assistance that I provide professionally to my clients. The time that I
have spent thus far is now starting to eat into the time I devote to
clients. That time is billable time, and I can't chew into that time to
spend
giving out free help.

I might be wrong, but this sounds like it might be a product you are
working on? If so, then you might want to consider whether the project
can afford to hire me to provide the kind of assistance you need. It
seems I can get to the end point more efficiently than it seems you
can. This is why it is often times more economically efficient to hire
a consultant for this sort of work. I've already done this work, I
already
have the experience and knowledge and tools to do it.

If you want to consider a more formal involvement on my part, then
we'll want to discuss this further. If, on the other hand, this is
something
you're doing for yourself, then I hope I have helped you along, but
must
disengage at this point.

In either case, I wish you success in your endeavors.

Please fell free to contact me if you want to pursue things further.

Hi,

Yes it would have been good if there was some documentation....really
helpful

I know if the values are correct of not by connecting the output to an
audio measurement unit....

This unit shows the frequency information as well as the audio
amplitude as -1dBFS or watever it is that we program

I am using a microcontroller to control the front panel of this
pdt...so when I change the values in the front panel, the
microcontroller talks to the FPGA

Depending on what values the FPGA receives( in this case lets say "a",
when we turn a knob to change values by 1 dB steps, "a" fed into the
FPGA changes accordingly from 1 to 30), it accordinly manipulates
sample

wrote in message
ups.com...
If you're output is going to remain in 24 bit integer format,
you WILL have to truncate the result, and that throws away
information. That leads to the introduction of quantization
artifacts which WILL be audible.

Whilst I totally agree in principle, WILL the artefacts really be audible
for 24 bit data?
(assuming the 24 bit co-efficients are used and the data rounded back to 24
bit)

MrT.

On Sun, 3 Apr 2005 12:48:29 +1000, "Mr.T" MrT@home wrote:


wrote in message
oups.com...
If you're output is going to remain in 24 bit integer format,
you WILL have to truncate the result, and that throws away
information. That leads to the introduction of quantization
artifacts which WILL be audible.

Whilst I totally agree in principle, WILL the artefacts really be audible
for 24 bit data?
(assuming the 24 bit co-efficients are used and the data rounded back to 24
bit)

As I said in one of my responses in the
rec.audio.pro/rec.audio.marketplace version of this thread, most
probably not. I opined that improving the sine generation (larger
table lookup and/or using interpolation) would do much more to reduce
distortion than would dither at the 24-bit level.
This poster was also asking about division on the fpga group, and
they were correctly telling him it's easier and better to multiply by
the reciprocal.
Google the threads - he's received a huge amount of help, the
equivalent of several chapters of a highly technical book, all
oriented to just what he's trying to do. I've never been in favor of
crossposting, but in thie case there would have been a lot less
duplication of effort on our part if he had just made one big
crosspost to all the involved groups.

MrT.

-----
http://mindspring.com/~benbradley

Hi Ben,

This topic is my first post...and as I was in need of help...I just
posted this topic wherever I could....I dont understand what u mean by
cross posting...But I appreciate all the help received....and Sorry for
any inconvenience.