DSP Device for Guitar Pedal Effect...

Main Page | Report this Page

Science Forum Index » Electronics - Design Forum » DSP Device for Guitar Pedal Effect...

Page 5 of 6 Goto page Previous 1, 2, 3, 4, 5, 6 Next

DSP Device for Guitar Pedal Effect...

Author

Message

Nico Coesel...

Posted: Wed Nov 04, 2009 1:36 pm

Guest

Fred <frederick.brown at (no spam) gmail.com> wrote:

[quote]On Nov 3, 4:30 pm, Vladimir Vassilevsky <nos... at (no spam) nowhere.com> wrote:
Nico Coesel wrote:
Vladimir Vassilevsky <nos... at (no spam) nowhere.com> wrote:

That has nothing to do with DAC and ADC. Once you do nonlinear functions
in digital domain, you get aliasing.

If you apply nonlinear function to a perfect digital sine wave, you will
get harmonics. If those harmonics are above Nyquist, they will be
aliased down.

I read some articles about that. It does make me wonder whether you
could rewrite the non-linear functions in a way so the harmonics are
not created in the first place. This should be more efficient than
upsampling -> non-linear function -> filtering -> downsampling.

It could be done if you can approximate the input by an analytical
function. Or approximate the nonlinearity by Volterra Series. Both ways
require pretty involved math; brute force oversampling is usually
simpler and cheaper.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

I think I'll flesh out the code in C, apply it to some PCM files, then
analyze the results first.

Do you think the harmonics from the non-linear function on a digital
sample would show up in the processed PCM file or would it have to be
converted to analog then analyzed?
[/quote]
It will also be visible in the digital domain. Cooledit is a very good
tool for this sort of work.

[quote]The compression itself is going to add harmonics, so how would I be
able to separate the ones generated by the compression from the ones
generated by applying the non-linear function to a digital signal and
the conversion processes?
[/quote]
Try different input frequencies. At frequencies closer to Fmax you'll
see more aliasing.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------

Vladimir Vassilevsky...

Posted: Wed Nov 04, 2009 3:14 pm

Guest

Fred wrote:

[quote]On Nov 3, 4:30 pm, Vladimir Vassilevsky <nos... at (no spam) nowhere.com> wrote:

Nico Coesel wrote:

Vladimir Vassilevsky <nos... at (no spam) nowhere.com> wrote:

That has nothing to do with DAC and ADC. Once you do nonlinear functions
in digital domain, you get aliasing.

If you apply nonlinear function to a perfect digital sine wave, you will
get harmonics. If those harmonics are above Nyquist, they will be
aliased down.

I read some articles about that. It does make me wonder whether you
could rewrite the non-linear functions in a way so the harmonics are
not created in the first place. This should be more efficient than
upsampling -> non-linear function -> filtering -> downsampling.

It could be done if you can approximate the input by an analytical
function. Or approximate the nonlinearity by Volterra Series. Both ways
require pretty involved math; brute force oversampling is usually
simpler and cheaper.

I think I'll flesh out the code in C, apply it to some PCM files, then
analyze the results first.
[/quote]
This makes perfect sense. Before doing anything with a DSP, get the
stuff to work on PC with a sound card.

[quote]Do you think the harmonics from the non-linear function on a digital
sample would show up in the processed PCM file or would it have to be
converted to analog then analyzed?
[/quote]
Aliasing is a natural phenomenon. You will see it in digital as well as
in analog.

[quote]The compression itself is going to add harmonics, so how would I be
able to separate the ones generated by the compression from the ones
generated by applying the non-linear function to a digital signal and
the conversion processes?
[/quote]
Harmonics are the multiples of the fundamental frequency; aliases are
generally not.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

...

Posted: Wed Nov 04, 2009 3:16 pm

Guest

On Wed, 04 Nov 2009 18:10:55 +0000, ChrisQ wrote:
[quote]Fred wrote:
I have begun to doubt that the Spin chip will be able to handle all the
cordic code in a timely manner.

So, use a lookup table. Cordic is iterative and the more accuracy you
want, the more iterations you need.

It's much faster to use a lookup table, a single line of C or assembler
in the best case:
u16Sine = u16SineTable [u16Angle];

Ok, you need a few more to resolve over the full range for cos, but it's
still lightspeed in comparison to cordic or other analytical methods,
[/quote]
Presumably by "a few more" you mean lines of code to implement stuff
like cos x = sin(x+pi/2), sin(pi-x) = sin x, sin x = -sin(x+pi), and
so forth. Thus one can use one quarter-cycle table for both sin and
cos. Also it is straightforward to use a one-term Taylor series so
that a much-smaller table suffices. sin(x+h) ~ sin x + h*cos x and
cos(x+h) ~ cos x - h*sin x with accuracy improving quadratically as
table size increases. With n = 64, 128, 256 and 512 and |h| less
than pi/(2n) the maximum relative error and maximum absolute error
at angles (k*pi)/2^16 for any integer k are like in following table.

n Max rel err Max abs err
64 0.000502 0.000301
128 0.000125 0.000075
256 0.000031 0.000019
512 0.000008 0.000005

ChrisQ...

Posted: Wed Nov 04, 2009 4:56 pm

Guest

joe at (no spam) somewhere.org wrote:

[quote]
Presumably by "a few more" you mean lines of code to implement stuff
like cos x = sin(x+pi/2), sin(pi-x) = sin x, sin x = -sin(x+pi), and
so forth. Thus one can use one quarter-cycle table for both sin and
cos. Also it is straightforward to use a one-term Taylor series so
that a much-smaller table suffices. sin(x+h) ~ sin x + h*cos x and
cos(x+h) ~ cos x - h*sin x with accuracy improving quadratically as
table size increases. With n = 64, 128, 256 and 512 and |h| less
than pi/(2n) the maximum relative error and maximum absolute error
at angles (k*pi)/2^16 for any integer k are like in following table.

n Max rel err Max abs err
64 0.000502 0.000301
128 0.000125 0.000075
256 0.000031 0.000019
512 0.000008 0.000005
[/quote]
That's neat. My math is old and I haven't needed extreme accuracy in the
past, but that one goes in the methods logbook to look into further !. I
use sin tables for embedded graphics work primarily. Things like object
rotation, which needs a new x,y screen address calculated for every
pixel within the object. It's very compute intensive and unusably slow
using standard library calls. Table methods can allow the use of a much
lower performance cpu while still getting adequate performance. Modern
micros often have hundred's of k of flash code space, so it makes sense
to do the math offline, rather than at runtime. For a 16 bit table, the
entries are calculated and scaled so that sin (90) is close to 65535 to
maximise accuracy, then scale the range of the system data to suit.

The 'added lines' for cos were just to handle the fact that with a one
quadrant table, you need to start reading back from the end of the table
for cosine, rather than from the start in the sin case. For graphics,
you often need to work in all 4 quadrants, but that can be handled by
inversion and reflection on a single quadrant table...

Regards,

Chris

krw...

Posted: Wed Nov 04, 2009 7:00 pm

Guest

On Wed, 04 Nov 2009 18:31:01 +0000, ChrisQ <meru at (no spam) devnull.com> wrote:

[quote]JosephKK wrote:

Nothing new here, move along.
The grandfathered old poor code already is an issue in the FPGA world.
As if you didn't already know.

Didn't know in fact, but can guess that could be a problem, just as it
is with legacy asm and C. Have done very little with fpga's / vhdl as
well. Every time I consider one for a project, a fast micro wins by
getting the job done at lower cost and timescales...
[/quote]
You must have some pretty trivial problems then.

ChrisQ...

Posted: Thu Nov 05, 2009 6:04 am

Guest

krw wrote:

[quote]
You must have some pretty trivial problems then.
[/quote]
One design was a legacy (1996) counter driven state machine pwm driver
with less than a dozen ttl devices and an eprom. A gate array looked
attractive and would have been a good excuse to get into a bit of vhdl,
but it was a lower cost solution to use a silabs 8051 micro as a one
chip solution and already had the tools from other projects. The other
thing was design tools. Yes, you can download demo versions, but you end
up with Gbytes of hard disk space. Even using the smallest gate array
from Lattice would have been uneconomic compared to the micro solution,
and would still have needed the eprom.

So what complex problems are you solving with gate arrays and what
speeds ?...

Regards,

Chris

krw...

Posted: Thu Nov 05, 2009 7:13 pm

Guest

On Thu, 05 Nov 2009 11:04:29 +0000, ChrisQ <meru at (no spam) devnull.com> wrote:

[quote]krw wrote:

You must have some pretty trivial problems then.

One design was a legacy (1996) counter driven state machine pwm driver
with less than a dozen ttl devices and an eprom. A gate array looked
attractive and would have been a good excuse to get into a bit of vhdl,
but it was a lower cost solution to use a silabs 8051 micro as a one
chip solution and already had the tools from other projects.
[/quote]

IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and
pass the crap job off to the firmware group Wink

.

[quote]The other
thing was design tools. Yes, you can download demo versions, but you end
up with Gbytes of hard disk space.
[/quote]
So what? A 1TB drive is under $100. BTW, they aren't "demo
versions". They're fully capable versions, just somewhat limited
(usually something like <1M gates and <10KLOC testbenches). I have
Xilinx, Altera, and Actel software on my systems. Our disty said he
was bringing the Lattice stuff by next week in case the Altera CPLD
didn't work out (he gets paid for either). It's good to keep 'em
guessing. Wink

[quote]Even using the smallest gate array
from Lattice would have been uneconomic compared to the micro solution,
and would still have needed the eprom.
[/quote]
Nonsense. I have two solutions (one Actel FPGA and the other an
Altera CPLD) for another pretty trivial problem, both under $2.50, no
EPROM/flash required.

[quote]So what complex problems are you solving with gate arrays and what
speeds ?...
[/quote]
My current "problem" is also pretty trivial[*], yet an FPGA (or CPLD,
not sure which) still makes a lot more sense than yet another micro
and piles more software complexity.

[*] Though it saves something like one-third of the $150 BOM times
$5K-$10K, per year. The FPGA/CPLD is only a part of the savings,
though.

Fred...

Posted: Fri Nov 06, 2009 8:26 am

Guest

I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows
about 125 instruction steps per sample. I was thinking of some thin
with at least 30 MIPS.

I see those Silicon Labs devices run at 50 and 100 MIPS, that would
allow a higher sampling rate. Other thatn that they seem overly
capable.

I only need 1 ADC input and 1 DAC output, and whatever I/O necessary
to support table data if used.

Regards,

Fred

On Nov 6, 12:28 pm, ChrisQ <m... at (no spam) devnull.com> wrote:
[quote]krw wrote:

IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and
pass the crap job off to the firmware group Wink

.

In my small company, I *am* the firmware group, and think software
design far more than hardware these days Smile

.

Nonsense. I have two solutions (one Actel FPGA and the other an
Altera CPLD) for another pretty trivial problem, both under $2.50, no
EPROM/flash required.

Not so cheap in the uk in small quantities and more expensive than an
silabs 8051. Using a gate array, would still have needed the eprom, as
the sine tables wouldn't fit, whereas they just go in code space using
an mcu. I get other benefits like self test, an a-d for soft start,
voltage regulation, current limiting etc and a serial port for status
messaging. There's even a temp sensor on chip !. Makes a far more
capable product for a couple of weeks of software effort, which you
would need anyway using vhdl.

As an aside and have no commercial interest, the Silicon Labs fast 8051
series are quite amazing. They are typically 50 mips risc cored updates
of the 8051 architecture and the dev kits range from ~$100 down, with
all the hardware and dev tools. You can get started building and running
the simple demos out of the box within 30 minutes or so. I don't really
rate the 8051 architecture that highly, but the latest versions do a
good job even with everything written in C.

So what complex problems are you solving with gate arrays and what
speeds ?...

My current "problem" is also pretty trivial[*], yet an FPGA (or CPLD,
not sure which) still makes a lot more sense than yet another micro
and piles more software complexity.

I guess everything's software now, even hardware design, so if there's
not much difference in cost, it probably comes down to what you are most
familiar with in the end...

Regards,

Chris[/quote]

Fred...

Posted: Fri Nov 06, 2009 11:36 am

Guest

On Nov 6, 2:13 pm, ChrisQ <m... at (no spam) devnull.com> wrote:
[quote]Fred wrote:
I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows
about 125 instruction steps per sample. I was thinking of some thin
with at least 30 MIPS.

I see those Silicon Labs devices run at 50 and 100 MIPS, that would
allow a higher sampling rate. Other thatn that they seem overly
capable.

I only need 1 ADC input and 1 DAC output, and whatever I/O necessary
to support table data if used.

Regards,

Fred

The si labs stuff is very good for a certain class of project and they
are fast, but couldn't say for sure that they would have enough real
time capability for audio sampling and processing. They are an 8 bit
architecture and any code that requires 16 or 32 bit operations will
result in a lot of code. The kits are very low cost though and modelling
the application, possibly at a lower data rate and resolution, would
provide a lot of insight in terms of what was really needed for the
task, especially if you have no previous experience of dsp solutions (I
don't, either Smile

.

Some of the variants have 24 bit adc's which would be more than good
anough if the sampling rate is high enough. You could use a timer driven
interrupt level state machine to control the adc and to connect the
samples to the mainline code processing section. It may very well be
possible, but you may need to add an spi 16 bit dac to get the final
analog output...

Regards,

Chris
[/quote]
Analog and Infineon 16bit devices are looking good, their in the 40-80
MIPS range. There's a few PIC that might work too, 32MIPS though.

I guess it will take me a while to sort thouugh all the
canidates... :)

***

BTW I just realized that I could easily sim the algorhythm with
behavioral sources in SPICE, so I've been making audio clips and
running PCM files though that.

It's good to see and hear the idea in action, especially since I've
had it on hold for years now.

Regards,

Fred

ChrisQ...

Posted: Fri Nov 06, 2009 12:28 pm

Guest

krw wrote:

[quote]
IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and
pass the crap job off to the firmware group Wink

.
[/quote]
In my small company, I *am* the firmware group, and think software
design far more than hardware these days Smile

.

[quote]
Nonsense. I have two solutions (one Actel FPGA and the other an
Altera CPLD) for another pretty trivial problem, both under $2.50, no
EPROM/flash required.
[/quote]
Not so cheap in the uk in small quantities and more expensive than an
silabs 8051. Using a gate array, would still have needed the eprom, as
the sine tables wouldn't fit, whereas they just go in code space using
an mcu. I get other benefits like self test, an a-d for soft start,
voltage regulation, current limiting etc and a serial port for status
messaging. There's even a temp sensor on chip !. Makes a far more
capable product for a couple of weeks of software effort, which you
would need anyway using vhdl.

As an aside and have no commercial interest, the Silicon Labs fast 8051
series are quite amazing. They are typically 50 mips risc cored updates
of the 8051 architecture and the dev kits range from ~$100 down, with
all the hardware and dev tools. You can get started building and running
the simple demos out of the box within 30 minutes or so. I don't really
rate the 8051 architecture that highly, but the latest versions do a
good job even with everything written in C.

[quote]
So what complex problems are you solving with gate arrays and what
speeds ?...

My current "problem" is also pretty trivial[*], yet an FPGA (or CPLD,
not sure which) still makes a lot more sense than yet another micro
and piles more software complexity.

[/quote]
I guess everything's software now, even hardware design, so if there's
not much difference in cost, it probably comes down to what you are most
familiar with in the end...

Regards,

Chris

ChrisQ...

Posted: Fri Nov 06, 2009 2:13 pm

Guest

Fred wrote:
[quote]I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows
about 125 instruction steps per sample. I was thinking of some thin
with at least 30 MIPS.

I see those Silicon Labs devices run at 50 and 100 MIPS, that would
allow a higher sampling rate. Other thatn that they seem overly
capable.

I only need 1 ADC input and 1 DAC output, and whatever I/O necessary
to support table data if used.

Regards,

Fred

[/quote]
The si labs stuff is very good for a certain class of project and they
are fast, but couldn't say for sure that they would have enough real
time capability for audio sampling and processing. They are an 8 bit
architecture and any code that requires 16 or 32 bit operations will
result in a lot of code. The kits are very low cost though and modelling
the application, possibly at a lower data rate and resolution, would
provide a lot of insight in terms of what was really needed for the
task, especially if you have no previous experience of dsp solutions (I
don't, either Smile

krw...

Posted: Fri Nov 06, 2009 6:52 pm

Guest

On Fri, 06 Nov 2009 17:28:03 +0000, ChrisQ <meru at (no spam) devnull.com> wrote:

[quote]krw wrote:

IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and
pass the crap job off to the firmware group Wink

.

In my small company, I *am* the firmware group, and think software
design far more than hardware these days Smile

.
[/quote]
Obviously. ...even when the solution should be in hardware.

[quote]Nonsense. I have two solutions (one Actel FPGA and the other an
Altera CPLD) for another pretty trivial problem, both under $2.50, no
EPROM/flash required.

Not so cheap in the uk in small quantities and more expensive than an
silabs 8051. Using a gate array, would still have needed the eprom, as
the sine tables wouldn't fit, whereas they just go in code space using
an mcu.
[/quote]
Why wouldn't they fit? Xilinx stuff has piles of RAM/ROM/dual-port
stuff. The Actel and Altera stuff I'm using is just small enough that
there is no block-RAM. I'd like to have it but for this application
don't really need it.

[quote]I get other benefits like self test, an a-d for soft start,
voltage regulation, current limiting etc and a serial port for status
messaging. There's even a temp sensor on chip !. Makes a far more
capable product for a couple of weeks of software effort, which you
would need anyway using vhdl.
[/quote]
There is no reason all that stuff couldn't be done in hardware.

[quote]As an aside and have no commercial interest, the Silicon Labs fast 8051
series are quite amazing. They are typically 50 mips risc cored updates
of the 8051 architecture and the dev kits range from ~$100 down, with
all the hardware and dev tools. You can get started building and running
the simple demos out of the box within 30 minutes or so. I don't really
rate the 8051 architecture that highly, but the latest versions do a
good job even with everything written in C.
[/quote]
C. Ick!

[quote]So what complex problems are you solving with gate arrays and what
speeds ?...

My current "problem" is also pretty trivial[*], yet an FPGA (or CPLD,
not sure which) still makes a lot more sense than yet another micro
and piles more software complexity.

I guess everything's software now, even hardware design, so if there's
not much difference in cost, it probably comes down to what you are most
familiar with in the end...
[/quote]
Spoken like a true software weenie. There is a *tremendous*
difference. You really should add another arrow to your quiver.

JosephKK...

Posted: Sun Nov 08, 2009 1:40 pm

Guest

.

In my small company, I *am* the firmware group, and think software
design far more than hardware these days Smile

JosephKK...

Posted: Sun Nov 08, 2009 2:09 pm

Guest

On Fri, 6 Nov 2009 10:26:46 -0800 (PST), Fred
<frederick.brown at (no spam) gmail.com> wrote:

[quote]I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows
about 125 instruction steps per sample. I was thinking of some thin
with at least 30 MIPS.

I see those Silicon Labs devices run at 50 and 100 MIPS, that would
allow a higher sampling rate. Other thatn that they seem overly
capable.

I only need 1 ADC input and 1 DAC output, and whatever I/O necessary
to support table data if used.

Regards,

Fred

On Nov 6, 12:28 pm, ChrisQ <m... at (no spam) devnull.com> wrote:
krw wrote:

IOW, pretty trivial stuff. I'd likely use an 8051 for that too (and
pass the crap job off to the firmware group Wink

.

In my small company, I *am* the firmware group, and think software
design far more than hardware these days Smile

JosephKK...

Posted: Sun Nov 08, 2009 2:18 pm

Guest

On Fri, 6 Nov 2009 13:36:41 -0800 (PST), Fred
<frederick.brown at (no spam) gmail.com> wrote:

[quote]On Nov 6, 2:13 pm, ChrisQ <m... at (no spam) devnull.com> wrote:
Fred wrote:
I see the Spin chip is 6 MIPS, at 48kHz sample rate that only allows
about 125 instruction steps per sample. I was thinking of some thin
with at least 30 MIPS.

I see those Silicon Labs devices run at 50 and 100 MIPS, that would
allow a higher sampling rate. Other thatn that they seem overly
capable.

I only need 1 ADC input and 1 DAC output, and whatever I/O necessary
to support table data if used.

Regards,

Fred

The si labs stuff is very good for a certain class of project and they
are fast, but couldn't say for sure that they would have enough real
time capability for audio sampling and processing. They are an 8 bit
architecture and any code that requires 16 or 32 bit operations will
result in a lot of code. The kits are very low cost though and modelling
the application, possibly at a lower data rate and resolution, would
provide a lot of insight in terms of what was really needed for the
task, especially if you have no previous experience of dsp solutions (I
don't, either Smile

.

Some of the variants have 24 bit adc's which would be more than good
anough if the sampling rate is high enough. You could use a timer driven
interrupt level state machine to control the adc and to connect the
samples to the mainline code processing section. It may very well be
possible, but you may need to add an spi 16 bit dac to get the final
analog output...

Regards,

Chris

Analog and Infineon 16bit devices are looking good, their in the 40-80
MIPS range. There's a few PIC that might work too, 32MIPS though.

I guess it will take me a while to sort thouugh all the
canidates... :)

***

BTW I just realized that I could easily sim the algorhythm with
behavioral sources in SPICE, so I've been making audio clips and
running PCM files though that.

It's good to see and hear the idea in action, especially since I've
had it on hold for years now.

Regards,

Fred
[/quote]
I don't know how versatile you are, but you could try capturing
several input waveforms, and running them through the algorithms on
your PC and playing them back.

Page 5 of 6 Goto page Previous 1, 2, 3, 4, 5, 6 Next

All times are GMT - 5 Hours The time now is Mon Nov 30, 2009 12:22 am Science Forum Index