Electrosmith Daisy

[potul]

You are getting confused.... An opamp is not an ADC.

Guitar signals will need to be aconditioned before feeding the ADC, so I would say you still need some kind of buffering/amplification. Line level signals might be ok to be fed directly.

[pruttelherrie]

Hm, confusing indeed. I have no idea what this remark of "16 bit ADCs" is about.

There is the audio stereo ADC-DAC, and there are also 12x 16bits ADC inputs (for pots, expression pedals, etc....). And 2x 12bits DAC outputs to interface with whatever you like.


This is at least my understanding.

Ah yes!

I think you're right.

[GuyB]

After a bit more research, I've learned that the Daisy Seed has the AK4556 chip on it's board for an AD/DA converter:

https://www.akm.com/content/dam/documents/products/audio/audio-codec/ak4556vt/ak4556vt-en-datasheet.pdf

"The AK4556 is a low voltage 24bit 192kHz CODEC for high performance battery powered digital audio subsystems. The dynamic performance to power supply voltage ratio is very high, attaining 103dB and 106dB SNR for ADC and DAC, respectively. Sampling rates up to 216kHz are supported. The AK4556 reduces jitter sensitivity by using an integrated switched-capacitor filter. The analoginputs and outputs are single-ended to minimize pin count and external filtering requirements. Packaged in a very small 20-pin TSSOP, the AK4556 is ideal for space-sensitive applications."

Potentially, the Daisy Seed is looking very good.



ElectroSmith posted this statement here:
https://www.muffwiggler.com/forum/viewtopic.php?t=228165

"Here are some specs!

CPU: STM32H750IBK6
SDRAM is run at 100MHz with 32-bit accesses per clock (the 1MB of internal SRAM is clocked at 480MHz). The external SDRAM is connected via a 32-bit parallel data interface.
Audio codec: AK4556 (Stereo 192kHz / 24-bit)"

Getting started with Daisy Seed:
https://forum.electro-smith.com/t/welcome-to-daisy-get-started-here/15

Some example Daisy Seed coding examples are here:
https://github.com/electro-smith/DaisySP/tree/master/examples

[Blackaddr]

The Daisy Seed has 24bit converters.

While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me 

The Teensy is not limited to 16-bit at all. You can you whatever you want for your intermediate processing. Float, double, etc. I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough. What you are limited to as 16-bit audio TRANSPORT. This means passing audio BETWEEN effects is 16-bit. But within an effect processing bock, you can have as much precision as you need.

ChipAudette even expanded the Teensy audio library to support floating point values as the native transport mechanism, but again, if you think you need more than 16-bit transport between stand alone audio effect blocks you might be making your processing less efficient than it could be for the same result.

You really do not need more than 16-bits for transport.

[pruttelherrie]

The Daisy Seed has 24bit converters.

While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me 

The Teensy is not limited to 16-bit at all. You can you whatever you want for your intermediate processing. Float, double, etc. I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough. What you are limited to as 16-bit audio TRANSPORT. This means passing audio BETWEEN effects is 16-bit. But within an effect processing bock, you can have as much precision as you need.

ChipAudette even expanded the Teensy audio library to support floating point values as the native transport mechanism, but again, if you think you need more than 16-bit transport between stand alone audio effect blocks you might be making your processing less efficient than it could be for the same result.

You really do not need more than 16-bits for transport.

I didn't say that the Teensy itself was limited to 16 bit.

The audio library works with 16 bit integer DSP (as you state). I followed discussions on the forum where Paul noted that he was not interested in going to 24 bit (unless it could be made downwards compatible, etc), but somehow I missed the ChipAudette library (the same Chip Audette who did a lot of work on STM32duino? [edit]not sure where I got that from?[/edit]). I'd like to tinker with the blocks themselves, but I'm totally lost in integer DSP, so I continued work on a port of the library to the floating-point DSP of ESP32: https://github.com/pruttelherrie/ESP32-A1S-Teensy-Audio

But "too many projects, not enough time" moved that backwards as well.

[Blackaddr]

The Daisy Seed has 24bit converters.

While the Teensy Audio library is a fun thing to play with, the limitations of 16 bit operations make it a no-go for me 

The Teensy is not limited to 16-bit at all. You can you whatever you want for your intermediate processing. Float, double, etc. I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough. What you are limited to as 16-bit audio TRANSPORT. This means passing audio BETWEEN effects is 16-bit. But within an effect processing bock, you can have as much precision as you need.

ChipAudette even expanded the Teensy audio library to support floating point values as the native transport mechanism, but again, if you think you need more than 16-bit transport between stand alone audio effect blocks you might be making your processing less efficient than it could be for the same result.

You really do not need more than 16-bits for transport.

I didn't say that the Teensy itself was limited to 16 bit.

The audio library works with 16 bit integer DSP (as you state). I followed discussions on the forum where Paul noted that he was not interested in going to 24 bit (unless it could be made downwards compatible, etc), but somehow I missed the ChipAudette library (the same Chip Audette who did a lot of work on STM32duino? [edit]not sure where I got that from?[/edit]). I'd like to tinker with the blocks themselves, but I'm totally lost in integer DSP, so I continued work on a port of the library to the floating-point DSP of ESP32: https://github.com/pruttelherrie/ESP32-A1S-Teensy-Audio

But "too many projects, not enough time" moved that backwards as well.

Sorry, I should have been clearer too as I was referring to the Teensy Audio Library itself.. Teensy Audio library is not limited to 16-bits in general. It is only limited to 16-bits for transport BETWEEN effects (AudioPrcoessors), which you shouldn't need anyway if you're doing things efficiently anyway.

People keep asking Paul to add 24-bit support to the library which is pointless here. No codec as SNR ratios that actually use those bits, they are all noise. It just would slow down the all the audio buffer memcpy's.

This discussion is actually a hot topic well outside the Teensy Audio vs. other dicussion. There is lot of eye-rolling going on in the studio DAW audio industry as uninformed consumers demand 24-bit for transport applications. Lots of articles about kind of nonsense:

https://www.mojo-audio.com/blog/the-24bit-delusion/

Having > 16-bits is essential for intermediate calculations but you can always dither back to 16bit for transport (either between effects/plugins or for storage)

[pruttelherrie]

Right!

Thanks for the elaboration.

The nice thing about 24 bit converters paired with decent preamps is that there's no need to get your gain "exactly right", just be in the ballpark and get going. I still remember late 90's recording with 16 bit ProTools converters and getting the gain right was a b*tch.
[edit] of course, 24 bits is overkill for getting the gain right, just a few more bits would be perfectly fine but in converters they usually jump from 16 to 24...
Also, I just remembered that my QuadraverbGT has 14 bit converters, and sounds just fine with those! [/edit]

[Firesledge]

I use 64-bit integers in my IIR filter coefficients because anything less isn't accurate enough.

Direct Form topologies really suffer from quantization (amongst other flaws). You could probably use filter designs like trapezoidal-integrated ones, that behave much better in 32-bit floating point at a very low extra-cost. See also the “SVF-vs-DF1.pdf - Noise performance plots” on the Cytomic technical paper page.

Though I sometimes use 64-bit floating-point for non-linear circuit simulation, because the extra accuracy makes the Newton-Raphson iterations converge much faster, even for elementary circuits like R-C-diode clippers. This is particularly true when the signal is strongly clipped.

of course, 24 bits is overkill for getting the gain right, just a few more bits would be perfectly fine but in converters they usually jump from 16 to 24

Usually digital and software people prefer a number of bits multiple of 8, so we generally go straight to 24 bits when 16 bits are not enough. Anyway codec manufacturers generally describe their chips with usual data like dynamic range, noise floor, SNR, THD, weighted or not, and that’s basically all we need.

BTW I would not dither to 16 bits for intermediate calculations (between plug-ins or FX modules) unless constrained by the architecture, because dithering noise can build up and suffer from non-linear processing. It’s much safer and probably cheaper to keep the full resolution on the whole path.

About the Daisy Seed, I build a few effects with it and it works great, I’m very happy with it. However the MCU has strong power use spikes contaminating the analog path so it requires a well-filtered power and serious capacitors. This said, if you don’t use high-gain effects, it’s perfectly acceptable.

[Blackaddr]

When dealing with embedded microcontrollers, you shouldn't be implementing filter topologies manually in your own code(assuming you will be heavily loading your CPU and don't have tons of cycles to spare). You should be using the hardware acceleration libraries for the processor which means you're limited to what they offer you.

In the case of ARM Cortex M's, the M4F and M7 have hardware DSP acceleration for filtering using the CMSIS library. For IIR filters the most processing efficient that they support is Direct Form I and II cascade biquads. If you implement your own filter topology with general software the performance will be terrible by comparison.
https://www.keil.com/pack/doc/CMSIS/DSP/html/group__groupFilters.html

Regarding the 16-bits for transport, we're just going to have to agree to disagree. Dithering converts the what would have been truncation error (potentially audible, but still improbably anyway) into random noise. in other words, it raises the noise floor slightly. The noise floor also can only be heard (if at all) during quiet or empty passages. As soon as there is actual sound content, you can't hear the noise anymore in an overall well designed system. E.g. if the total SNR for the whole system, end to end, is better than 60dB you probably think a very high quality, silent system.

Yes, the SNR adds up from any component in the system but the vast majority comes from outside the digital audio path. In other words, accumulating some dithered noise from a dozen effects is going to to be far less than that in the analog part of the system which is subjectable to all kinda of EMI noise and interference. Your accumulated SNR in your 16-bit TRANSPORT paths are going to be probably putting the SNR between 70dB and 80dB. Your actual analog audio path as a whole is probably going to be struggling to meet 60dB SNR. Your standard passive guitar pickups are brutal for SNR from EMI, everything else almost doesn't matter at all.

Again, as above, using higher precision in certain local math calcuations is essential. Using the 32-bit floats for IIR coefficients is going to be way more accurate than 64-bit fixed-point integers but the computation will be way slower. The 64-bit integer CMSIS accelerated biquads are way faster than the 32-bit float accelerated biquads. Using as many bits as you need hear in the fastest computation possible is what good DSP designers do. Slowing down the CPU and memory transfers putting bits where they do give you must return (like as transport between effects) is not a good idea.

By using 24-bit transport when you don't need to on a compute-bound processor means you are using more more RAM, more CPU cycles moving data around, everything gets slower. This is going to potentially reduce how complex your algorithm can be as with embedded audio processing we always seem to need more compute speed. Would you rather have more accurate reverbs and distortion effects due to more compute intensive algorithms, or would you rather trade that for simpler, less advanced algorithms in order to save a few dB of SNR buried so low you can't hear them anyway?

[Firesledge]

I haven’t benchmarked the CMSIS functions vs my own generic code, but you’re certainly right. There is nothing fancy in the CMSIS source code (standard instructions and intrinsics, loop unrolling, etc.), so nothing prevents you to implement your own filter topology with the same level of efficiency. In my previous post I just wanted to point that a topology change can be an relevant alternative to higher bitdepth if accuracy is an issue.

I agree that 16 bit may be enough for intermediate steps when you have a firm control on all the levels used in the effect graph. But requiring this control is actually an issue (what pruttelherrie told about setting the gain). And more importantly, if one of the effect is a distortion with a pretty high gain (like 60 dB), the dithering noise is amplified too, becomes annoyingly audible and may cancel all the good work done by a noise gate. Note that even without dithering, sounds at the edge of the quantization (like sounds of fingers holding the strings, or just occasional static noise) become ugly bursts of noise at the end of the chain after a massive amplification.

[GuyB]

At present, there is 10% off Daisy using code: ELECTRO10

See offer here:
https://www.electro-smith.com/daisy/daisy

[Processaurus]

I haven’t benchmarked the CMSIS functions vs my own generic code, but you’re certainly right. There is nothing fancy in the CMSIS source code (standard instructions and intrinsics, loop unrolling, etc.), so nothing prevents you to implement your own filter topology with the same level of efficiency. In my previous post I just wanted to point that a topology change can be an relevant alternative to higher bitdepth if accuracy is an issue.

I agree that 16 bit may be enough for intermediate steps when you have a firm control on all the levels used in the effect graph. But requiring this control is actually an issue (what pruttelherrie told about setting the gain). And more importantly, if one of the effect is a distortion with a pretty high gain (like 60 dB), the dithering noise is amplified too, becomes annoyingly audible and may cancel all the good work done by a noise gate. Note that even without dithering, sounds at the edge of the quantization (like sounds of fingers holding the strings, or just occasional static noise) become ugly bursts of noise at the end of the chain after a massive amplification.

In my tinkering with the line 6 modeler pedals, in particular comparing the amp modeler and distortion modeler to the others, they did a cool, interesting analog front end. They were mono pedals, but used a stereo ADC, one channel was normal, but the signal feeding the other channel had a high gain preamp with some garden variety TS style diode clipping. With the different models the programmer had the choice of the clean input or the amped input, that had much better detail with the quiet parts of the signal.

If you didn’t want to sacrifice stereo input, it could be a modest modification to use a general purpose digital output to use an analog switch, like the 4066, to switch in gobs of gain in the preamp for special distortion/high gain digital effects.

[Blackaddr]

In my tinkering with the line 6 modeler pedals, in particular comparing the amp modeler and distortion modeler to the others, they did a cool, interesting analog front end. They were mono pedals, but used a stereo ADC, one channel was normal, but the signal feeding the other channel had a high gain preamp with some garden variety TS style diode clipping.

That's really interesting. Given the compute power available back then, I would consider this "hybrid" modelling approach is acceptable if it gives guitars a better quality sound in the end. Kinda cheating though? Maybe?

I can see some reviewer saying it "DSP has really come far. This new digital pedal totally nails the simple diode clipping based distortion pedals."