#key click

1 messages · Page 1 of 1 (latest)

bitter magnet
#

I see the "example" and the "lowpass" one, but not one with ramp-up and down

#

above is "example"

#

"lowpass" is similar, just reduced amplitude

random cape
#

This is what I'm seeing for a release and attack. Looks like the harmonic distortion is probably coming from a stairstepped ramp on the vca.

bitter magnet
#

probably yes, and you can use Analyze->Plot Spectrum to check out the spectrum ... you probably already are

#

you could probably generate some smoother test waveforms in Audacity and just play them through the TLV. I don't think it's the problem -- I think it's expecting smoothness from the synthio code

random cape
bitter magnet
#

looks and sounds like "fuzz" 🙂

random cape
#

yeah...🫤

#

So I guess this part seems like a synthio thing then? (also, that wav file was 48000Hz sample rate)

bitter magnet
#

I think so. You could generate a smoother sine wave sample yourself and just play it back through the current setup to confirm

random cape
#

This is what the reproducer code sounds like if I set the DAC sample rate down to 22kHz

bitter magnet
#

for any particular speed of cw, you only need dit and dah waveforms of certain lengths (1:3), so you could generate those samples nicely and then just play those fixed length samples back

random cape
#

and this is what the sinewave spectrum looks like at 22kHz

bitter magnet
#

sounds like that too 🙂

random cape
#

it's pretty brutal

#

So, what's your take on where this falls in the it's-a-bug vs won't-fix continuum? At some point, expecting really good audio quality from CircuitPython seems maybe unrealistic. It would be nice if it were possible though.

bitter magnet
#

if you generate that same sine wave at the same resolution and play it on your dev computer, does it sound any better?

#

that is, with

sinewave = np.array(
    np.sin(np.linspace(0, 2*np.pi, 1024, endpoint=False)) * 32760,
    dtype=np.int16)
#

i am off to sleep soon

random cape
#

Thanks! I'll give that a try. More tomorrow maybe.

#

This is a 22kHz wav file I generated with Audacity with the kind of tone I'd love to be able to get out of CircuitPython if it was possible. Haven't tried it on the Fruit Jam yet. This is just exported from Audacity at 22kHz. I generated silence and 650Hz sine wave then ran it through a 48dB/octave bandpass (650Hz lowpass, normalize, 650Hz highpass, normalize).

random cape
#

The samples sound great on macOS, but they get mangled pretty bad going through the TLV320. I wonder if that might be relatively easy to fix as the TLV320 has a filtering stage. In the datasheet it looked like the filters may have been intended to deal with variable sample rate stuff.

random cape
#

@bitter magnet I've been looking at the TLV320DAC datasheet. It seems like the DAC is designed with the intention that when using low sampling rates, you should configure high DAC Oversampling Ratio (DOSR MSB/LSB registers) and select a suitable PRocessing Block interpolation filter (PRB_P1..PRB_P25 depending on desired filter type).

#

From what I can make out, it looks like the type of noise I'm seeing is typical of a delta-sigma converter operated at low sample rate with inadequate oversampling.

#

As far as I can tell, the CircuitPython TLV320 driver is just using the powerup defaults for the processing block interpolation filter (which looks fine) and a fixed value for the oversamping rate (not so fine). Seems like adding driver support for DOSR selection might be the solution I need.

#

(working from the assumption that 44kHz wav file sample buffers would use way too much SRAM)

random cape
#

I'm reasonably confident that the main problem is how the TLV320 driver currently always uses 128 as the DOSR (oversampling rate) value rather than selecting an appropriate value based on the sample rate.

#

I think I've basically answered my question. Seems like bad DOSR values are the main problem and Adafruit_CircuitPython_TLV320 is the right repo for this issue.

bitter magnet
random cape
#

made some major progress. This is a recording straight out of the DAC running at 8kHz sample rate with a modified adafruit_tlv320 driver module. I've set DOSR=768 for the oversampling (instead of 128), and I'm using 5 MHz PWM out to MCLK with a custom PLL tune (solved for low PLL frequency error) in the driver.

[edit: I messed up the wav file. scroll down 2 messages for the good one]

#

The noise floor is way lower than anything I've heard coming out of the Fruit Jam, ever. This is making me think that everything I've ever done up until just now with the TLV320DAC has been set up with a bad PLL configuration.

#

The bit that's making this work well is:

i2c = I2C()
dac = TLV320DAC3100(i2c)
mclk_out = PWMOut(I2S_MCLK, frequency=5_000_000, duty_cycle=2**15)
dac.configure_clocks(sample_rate=SAMPLE_RATE, bit_depth=16, mclk_freq=5_000_000)
#

and in adafruit_tlv320.py for the _configure_clocks_for_sample_rate() method, it's doing this:

        elif mclk_freq == 5_000_000:
            if sample_rate == 8000:
                p, r, j, d = 5, 2, 46, 800
                ndac = 15
                mdac = 1
                dosr = 768
#

I got those values from running a brute force solver

random cape
#

okay, I generated PLL settings for 48kHz, 44.1kHz, 22.05kHz, 11.025kHz, and 8kHz and they sound good. This is a recording spliced together from running my test code at each of the sample rates. To be clear, the WAV file attached below was recorded at 48 kHz, but each of the sections within that recording came from the Fruit Jam's headphone jack running code to play WAV files at different DAC sample rates. Each sample rate is playing a short wav file, at that rate, containing a 650 Hz sinewave. To my ear, they sound effectively the same (which is the outcome I was aiming for).

#

I'm gonna turn this into a PR with sample code showing how to set up the PWMOut for I2S_MCLK. The quality improvement is so big that I'm expecting people will probably want to switch to using that method for Fruit Jam OS and other such things.

random cape