"Custom" Sawtooth signal in ADAU1452?

Hi guys,

So basically I'm trying to make a sawtooth signal in sigma studio, recreating something like this (the x-axis values are accurate and it is indeed the values I wanted, but please ignore the y-axis values as what I need is actually for it to go from 0 to 1):

I noticed that the foundation of this signal is an inverted sawtooth, that has some zeros on it and that allows the orange and blue signal to be overlapping with each other, with the orange signal is simply the delayed version of the blue one. Not knowing how to modify the sawtooth block, I tried to sweep a 15-row LUT with a counter block, like this:

with the LUT being 1 to 0.9 to 0.8 and finally reaching 0s at the end. I am having difficulties in terms of getting them in my required timings (first picture). I observed the results through an oscilloscope and they looked like this:

but the resolution is pretty bad (my hunch is a 15-row LUT is not enough to make a smooth graph), and as I increase the rows, the timings also change. I am wondering if there is an elegant way to do this? Thank you!!

-Levi



(EDIT: the units of the x-axis values on the first picture is ms)
[edited by: Levi at 9:22 AM (GMT -4) on 7 May 2021]
Parents
  • +1
    •  Super User 
    on May 8, 2021 2:19 AM

         Hello Levi,

         Actually your LUT solution is quite elegant, it amounts to an arbitrary waveform generator.  Its outputs are well-defined and easily changed via the contents of the LUTs. By contrast,  I tend to think of "analog" ways to do things in SigmaStudio -- thus came up with an integrator (an adder which feeds back to itself) with ABCD comparators to provide the timing.  The project produces waveforms like those in your first picture -- with its horizontal axis I had unfortunately assumed to be in seconds.  At this scale, the waveforms' period is about 80 mS  (12.5 Hz). The project's output appears below:

         With the horizontal axis in mS instead of seconds, the desired waveforms' period changes to 80 uS, with a corresponding rep rate of 12.5 kHz.  A 48K sample rate yields only about 4 samples per cycle -- not enough to define the desired waveforms.  Another way of saying this is that the 12.5 kHz ramps include harmonics beyond the Nyquist frequency of fs/2.

          Even if you run the DSP at 192 K, the result still won't look very good.  My eval board only works at 48K, yet we can simulate the quality of the 12.5 kHz ramps at 192K by running 3.13 kHz ramps at 48K.  Here's the results:

           

         Note how each sharp upward transition is surrounded by ripples before and after.  My guess is these arise from the DAC's reconstruction filter, which could be an oversampled windowed-sinc FIR -- not unlike the "sin(x) / x interpolation" found in digital scopes.  Anyhow, I attached the project should you wish to have a look at it.  You can change the ramps' frequency by adjusting the "increment" value -- the integrators' per-sample ramping.

         Best regards,

         Bob

    1452-Ramps.zip

  • Hey guys,

    cc:

    So this is what I came up with. please check the Matlab link in my previous comment and I tried to make the gain control signal using a sine wave fed into an ABCD comparator so that every time the signal is negative, it outputs 0. The pitch shift is better than the stock one, in terms of it shifts every frequency correctly (my observation on the stock pitch shifting block on ADAU1452 was the shift isn't very consistent). The only exception was the output is trembling(?) I don't know how to put it on words and it would be great if anyone could check out the project file I attached and trying to use any MP3 file as an input. I am suspecting the tremble comes from the Gain Driver and Delay Driver not being matched in terms of frequency. This hunch is supported by the fact that the "tremble" goes way more intense over time.

    This might be a good enough candidate for a new pitch shifting algs (in my opinion). I'd be happy to receive any feedback on my schematic! And thank you!!

    Sincerely,

    Levi

    Delay Based Pitch Shifting.zip

  • 0
    •  Super User 
    on May 11, 2021 8:59 PM in reply to Levi

         Hello Levi,

         I tried your project and it's fun to "chipmunk" the Beatles!  Your observation is correct -- the effect degrades over time when the delay-shifting and cross-fading portions of the project drift apart,  You could improve the results by having the ramps which sweep the delays also synchronize the cross-fading.  Pitch algorithms generally have audible artifacts from the "splices" between re-pitched segments, yet the Matlab article describes how to minimize them.  BTW -- the two-tap moving average FIR filter at the ramp generator's output was to smooth the ramp's upward transitions before output to the DAC -- the help Wiki recommends filtering any sharp waveforms being output.  Since the pitch changer doesn't output the ramps to DACs, you may dispense with this filter.

         I attached a sample circuit in which everything proceeds from the ramp timing, so it solves the drift issue.  Yet there's many ways to do this, and besides I haven't attempted to adjust the cross-fade timing as described in the Matlab article.  So you'll do better experimenting with other arrangements.

         Best regards.

         Bob

    Delay Based Pitch Shifting3.zip

Reply
  • 0
    •  Super User 
    on May 11, 2021 8:59 PM in reply to Levi

         Hello Levi,

         I tried your project and it's fun to "chipmunk" the Beatles!  Your observation is correct -- the effect degrades over time when the delay-shifting and cross-fading portions of the project drift apart,  You could improve the results by having the ramps which sweep the delays also synchronize the cross-fading.  Pitch algorithms generally have audible artifacts from the "splices" between re-pitched segments, yet the Matlab article describes how to minimize them.  BTW -- the two-tap moving average FIR filter at the ramp generator's output was to smooth the ramp's upward transitions before output to the DAC -- the help Wiki recommends filtering any sharp waveforms being output.  Since the pitch changer doesn't output the ramps to DACs, you may dispense with this filter.

         I attached a sample circuit in which everything proceeds from the ramp timing, so it solves the drift issue.  Yet there's many ways to do this, and besides I haven't attempted to adjust the cross-fade timing as described in the Matlab article.  So you'll do better experimenting with other arrangements.

         Best regards.

         Bob

    Delay Based Pitch Shifting3.zip

Children
  • Hi KJBob,

    Thank you for your great and constant help in this effort to implement this alg! I see that in your schematic, instead of varying the gain using a multiplier cell, you used the signal to control a slew cell. I haven't yet tried to compile your schematics though, since my eval board is currently in my office and I haven't got the chance to play with it again.

    And about the cross fade adjustment, according to my time playing around with the matlab app (they got sliders to adjust how the crossfade timing is), they only produce decent result in 1 position. So I believe the ability to make it adjustable is not really necessary. I still have to decide though whether the current crossfade timing is ok or not. Will surely get back to you again once I got my hands on. Thanks a lot!!

    Sincerely,

    Levi