DSP Device for Guitar Pedal Effect

much=20

of=20

because

Interesting idea, too bad it (80287, 8MHz) cannot compute a trig function in time (10 microseconds).

Back in the day, the FPU was necessary (over 100:1 speed difference) to run SPICE. So was maximum RAM.

a=20

application.

=20

=20

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.

you care

=A0Each

or

wade

when

of

You

development

be

floating.

curve

than

=20

Cordic algorithms have similar properties. Besides there is nothing wrong or all that (time) expensive about a post multiply.

No. It is not fast enough. ;=3DP=20

to=20

ADC's=20

=20

or a=20

=20

create a=20

the=20

requires=20

On the other side of the coin 1MS/s 16 (REAL) bits is VERY expensive. Whereas 20 bits (real resolution) at 96 kHz is affordable.

has=20

always=20

will=20

frequency=20

guitar=20

on=20

into=20

=20

or=20

Not necessarily, there are three octaves between 12 kHz and 96 kHz. A mere 2nd order filter will give 24 dB attenuation, and a "better" 4th order filter will provide an easy 48 dB (if the electronics is that good).=20

It helps the analog filters a bit. Do the oversampling digitally.

digital.=20

No, not really. Not unless you are saturating the input ADC. If you do that all bets are off (so to speak).

digital.

in

I am not sure about what you hear (heard), but a lot of early CD players had lousy DACs. Lousy converters could be the problem in the early cheap effects devices. It is a very different sonic effect than aliasing. Then there are/were converters that lost resolution (ENOB) at higher frequencies (like 10 kHz).

With audio delta sigma DACs and ADCs, you typically have the group delay of 15..20 samples on either side. That makes for the delay up to few hundred microseconds or so, however for audio effects that doesn't matter much as the speed of sound is only 330m/sec.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Huh? Run the numbers.

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.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

The successful ones like Line 6 are believed to increase the sampling rate before applying the non-linear function (i.e. upsample) and then LPF whilst downsampling; see

Chris

I have begun to doubt that the Spin chip will be able to handle all the cordic code in a timely manner.

So as I look/wait for affordable hardware that can do this I might as well get started on the coding.

This project has already been on hold for years due to a lack of affordable hardware, at least they're getting closer.

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 Consultant

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?

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?

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,

Why do some people insist on doing things the hard way ? :-)...

Regards,

Chris

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...

Regards,

Chris