Author Topic: i.MX RT1062: Getting Started, on a Raspberry Pi?  (Read 8094 times)

0 Members and 1 Guest are viewing this topic.

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #25 on: February 23, 2023, 03:03:59 pm »
With very little effort I succeeded at installing Micro Python on my Raspberry Pi Pico board…
That's great!  But not really the topic of this thread.  I gave you a pass on the first one, and tried to bring the conversation back on topic.  If you wouldn't mind to start your own thread for that, it would keep the clutter down here.  Thanks!
Understood.  After re-reading this topic I realized I missed this point from your initial post:
Quote
NXP has their own IDE, SDK, and related tools, but they're either online or for x86/64 only.  I'm on a Raspberry Pi 4 with the official RasPi OS.
I incorrectly thought you were comparing target boards: Teensy4.1 vs. RPi Pico. But… This topic is about discovering useful RT1062 development tools which run under RasPi OS. I’m a bit surprised that official NXP development tools aren’t supported on RasPi OS. Are those NXP tools for Windows 10 only? Nothing for any flavor of Linux?

I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #26 on: February 23, 2023, 05:32:03 pm »
I’m a bit surprised that official NXP development tools aren’t supported on RasPi OS. Are those NXP tools for Windows 10 only? Nothing for any flavor of Linux?
That's how it appears to me, but westfw has a good point that I still have to check.  I might be able to use parts out of the Arduino framework, which does run on Linux, and the Pi, to make my own toolchain.
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #27 on: February 23, 2023, 05:40:46 pm »
...the i.MX RT1062 chip that I'm looking at is about that much again more than the Pico.  Only a single CPU, but 600MHz instead of the Pico's 125MHz, and hardware floating-point!  That's enough to have a decent audio library, whereas the Pico can barely keep up with a single signal generator at 48kHz according to my experiments.
I agree that Teensy4.1 is a better choice for audio applications compared to the the RPi Pico.

Do you have any direct experience with previous PJRC products, especially Teensy 3.5/3.6, the PJRC audio interface board, and best of all, the Teensy Audio Library?

Several years ago when the Teensy3.5 was first introduced I bought one and its companion audio interface board, having previously been very satisfied using AVR-based Teensy boards and the Teensy3.1. However the Teensy3.5 was a whole new experience for me. I was blown away by its audio capabilities along with the features of the superb PJRC audio library.

Today PJRC strongly recommends advancing to the Teensy4.1. They warn that their older boards may never be manufactured again (due to chip-a-geddon).
     https://www.pjrc.com/store/teensy41.html
     https://www.pjrc.com/store/teensy3_audio.html
     https://www.pjrc.com/teensy/td_libs_Audio.html
After finishing this post I'm ordering a Teensy4.1 along with its matching audio board. (as of this moment) both are in stock at the PJRC store.
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #28 on: February 23, 2023, 06:30:54 pm »
Example of an impressive Teensy-based audio application: This 6-voice polyphonic synthesizer was implemented with Teensy3.5 (120 MHz Cortex-M4F) and the PJRC audio library:
     https://www.pjrc.com/six-voice-polyphonic-synth/
Direct link to builder's Youtube demo video:
     
Builder's GitHub project:
     https://github.com/albnys/TeensyPoly6

In contrast the Teensy4.1 is a 600 MHz Cortex-M7. Just imagine how much more it can do! That said, I think the best reason to use the Teensy4.1 for audio processing is the PJRC audio library.  Whether or not you enjoy using the Arduino IDE, I believe it is the most direct route to creating a functional audio project containing the Teensy4.1

Another example: The same builder recently made a drum machine with Teensy4.1.  His GitHub project shows how the PJRC audio library is used:
     https://github.com/albnys/Drum-Machine
Demo of the finished drum machine:
     
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #29 on: February 23, 2023, 07:14:38 pm »
Do you have any direct experience with previous PJRC products, especially Teensy 3.5/3.6, the PJRC audio interface board, and best of all, the Teensy Audio Library?
I don't.  This is the first for me.

As for the Teensy Audio Library, it's fixed at 16-bit 44.1kHz, which is technically CD quality if you ignore the accumulated round-off error.  Pro gear pretty much always uses 24-bit converters now, so that the digital version is always better than its analog source.  (the bottom few bits are always below the analog noise floor: it's difficult, but possible to make a dedicated analog circuit out-perform a 16-bit converter, but not a 24-bit one)  And they up-convert from there to do all the processing, so that the accumulated round-off error isn't enough to make a difference at the 24-bit output converter.

For example, a popular cheap digital mixer, either as a console in back or a "smart stage box", uses 40-bit floating-point internally, between its 24-bit converters to and from the analog world.  Larger consoles that do more, and pretty much every DAW (Digital Audio Workstation - essentially an audio console that runs in software on a PC, with all of the extra features that that can offer) use 64-bit floating-point or better, again to keep the accumulated round-off error small enough to not matter.

If you keep the signal fairly "hot", then the low bit-depth doesn't matter as much, but when you turn it down a lot, it does.  Especially when you use the digital processing as the master volume control, feeding a fixed high-gain amplifier, as the pro world does and I've come to like because of what it allows you to do.

So I need more than 16 bits all around - 24-bit converters and at least 32-bit processing - which means I can't use that library.  Probably not that board either, as I would expect it to have 16-bit converters on it to match the 16-bit library.  It's good to play with, and learn about audio processing without having to dive into the weird unintuitive world of DSP code, but for me to call it a serious replacement for a DIY analog thing would require 24-bit I/O and 32-bit processing as an absolute minimum.

Soo...it looks like I *am* going to dive into the weird unintuitive world of DSP code.  ;D  Unless I can find a different library with a permissive license that doesn't have a prohibitively large buffer.  (big buffers can make things more efficient on systems that can do single-instruction-multiple-data (SIMD), or approximate it, but they also add a ton of latency equal to the buffer size)



If you're using it to make a synthesizer - melodic, percussive, whatever - then it probably doesn't matter as much.  The signal stays fairly "hot", as the master volume control is outside the scope of that project, and whatever non-idealities it still has, become part of its "character" as an instrument.

If you're using it as I am, to make a transparent processor and system manager, it needs to be better than that.
« Last Edit: February 23, 2023, 07:23:48 pm by AaronD »
 
The following users thanked this post: elecdonia

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14487
  • Country: fr
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #30 on: February 23, 2023, 08:01:16 pm »
...the i.MX RT1062 chip that I'm looking at is about that much again more than the Pico.  Only a single CPU, but 600MHz instead of the Pico's 125MHz, and hardware floating-point!  That's enough to have a decent audio library, whereas the Pico can barely keep up with a single signal generator at 48kHz according to my experiments.
I agree that Teensy4.1 is a better choice for audio applications compared to the the RPi Pico.

No kidding! It's a world apart.

But of course, it depends on what you want to do. If you stick to fixed-point, there's still a lot of cool stuff you can do with the RP2040, especially with its 2 cores, it's overclockability AND with the hardware blending peripheral, which can be used to accelerate interpolation and a lot of other things.

 
The following users thanked this post: elecdonia

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #31 on: February 23, 2023, 08:09:45 pm »
Yes, if your project is in the pro-sound or studio-grade realm you may wish to use higher resolution than 16 bits. But I doubt there are any high-resolution audio libraries with the capability of the PJRC 16-bit package which don't cost major $. I recommend evaluating and testing the PJRC items because the cost is negligible. The total invoice for the Teensy4.1 board, companion audio adaptor board, and shipping which I ordered today from PJRC was $53.63 USD. And the PJRC 16-bit audio library itself is free.
A vital  question is this:
     "What resolution does the PJRC audio library use internally, inside its functional blocks?

I don't yet have the answer to this question. However, years ago I learned when and where to use "long" variables in the code I write for 8-bit hardware like the AVR. It is certainly possible that functional blocks inside the PJRC audio library are implemented with far more than 16-bit resolution.

Do you feel that audio streams between hardware devices must have greater than 16-bit resolution?
 (For example an audio stream which comes from an RPi Pico and then flows into the Teensy4.1)

 
« Last Edit: February 24, 2023, 12:18:55 am by elecdonia »
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14487
  • Country: fr
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #32 on: February 23, 2023, 08:24:36 pm »
You can do 24-bit stuff with the RP2040 or the RT1062 alike. I was of course not talking about using any existing library. Write your own stuff.

I wrote a small synth with a RP2040 using fixed-point, hardware blending, the PIO for generating 24-bit I2S, and USB MIDI (using TinyUSB.)
Perfectly doable.
 
The following users thanked this post: elecdonia

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #33 on: February 23, 2023, 08:39:36 pm »
If you stick to fixed-point, there's still a lot of cool stuff you can do with the RP2040, especially with its 2 cores, it's overclockability AND with the hardware blending peripheral, which can be used to accelerate interpolation and a lot of other things.
The audio CD format is 2 channels of "signed 16-bit integer" audio. Although I enjoyed listening to Sony's "SACD" disc format in the early 2000's, it wasn't a commercial success. My favorite SACD discs were mixed for 4 discrete audio channels. They sound amazing! 

Personally I don't recall writing much code which required me to use floating point variables. I frequently use "long" variables (usually signed) in my code. But float? Not so much.

A major question for the OP is to learn what resolution is used inside the "16-bit" PJRC audio library?

Today I ordered a Teensy4.1 and its companion audio interface board from PJRC. (They are currently both in-stock!). I previously used the Teensy3.5, its  audio board, and an earlier version of the PJRC audio library: The results sounded absolutely terrific to me. The ease of designing audio processes with the PJRC audio library is amazing. The next step above that in my experience is a package like Native Instruments Reaktor, combined with a full-scale professional-grade DAW:
     https://www.vintagesynth.com/misc/reaktor.php
Of course this requires a high-performance PC and Windows 10. In fact most laptops aren't good enough. Reaktor has a visible gauge which shows its real-time resource consumption: I've seen 100% utilization more than occasionally.
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #34 on: February 23, 2023, 08:49:32 pm »
You can do 24-bit stuff with the RP2040 or the RT1062 alike. I was of course not talking about using any existing library. Write your own stuff. I wrote a small synth with a RP2040 using fixed-point, hardware blending, the PIO for generating 24-bit I2S, and USB MIDI (using TinyUSB.) Perfectly doable.
Is it available anywhere? The large community of starving musicians and makers certainly do need audio libraries which can operate on small hardware.
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #35 on: February 23, 2023, 09:03:46 pm »
Quote
If you keep the signal fairly "hot", then the low bit-depth doesn't matter as much, but when you turn it down a lot, it does.  Especially when you use the digital processing as the master volume control, feeding a fixed high-gain amplifier, as the pro world does and I've come to like because of what it allows you to do.
In old-school (analog) recording studios (and live-performance sound reinforcement) the audio levels for signal-processors (eq, reverb, compression, filters, noise gates) were carefully adjusted to (usually) the highest levels which didn't clip. The "Dolby" and "DBX" analog tape noise suppression systems compressed the audio before recording, then expanded it inversely on playback.
The relative position of faders (eg volume controls) in the audio chain always ended with the "master volume control." Prior to that point all levels were kept as high as possible "below clipping."
 
Can the OP's project be arranged so that "master volume" is applied in the final piece of hardware just prior to the power amps and speakers?
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14487
  • Country: fr
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #36 on: February 23, 2023, 09:22:45 pm »
You can do 24-bit stuff with the RP2040 or the RT1062 alike. I was of course not talking about using any existing library. Write your own stuff. I wrote a small synth with a RP2040 using fixed-point, hardware blending, the PIO for generating 24-bit I2S, and USB MIDI (using TinyUSB.) Perfectly doable.
Is it available anywhere? The large community of starving musicians and makers certainly do need audio libraries which can operate on small hardware.

It's not, but others have done synths too on the RP2040:


What I can share here is the PIO program for transmitting 64-bit/frame I2S (which you can use for transmitting anything from 16-bit to 32-bit samples, stereo), will work on any modern I2S DAC that takes 64-bit/frame, which is pretty much the norm now. This PIO program should be preferably used with DMA. For anyone that could find this useful.

Code: [Select]
;**         PIO assembler code for 32-bit I2S (64 bits/frame)

; Out pins:
;   0: SDATA (data out)

; Side-set pins:
;   0: BCLK (bit clock)
;   1: LRCLK (word select)

; Blocks on TX FIFO empty - the stream will stop if it's empty.

.program i2s_32_tx
.side_set 2

set x, 30           side 0b00

.wrap_target

left_word:
out pins, 1         side 0b00
jmp x-- left_word   side 0b01

out pins, 1         side 0b10  ; LSB
set x, 30           side 0b11

right_word:
out pins, 1         side 0b10
jmp x-- right_word  side 0b11

out pins, 1         side 0b00  ; LSB
set x, 30           side 0b01

.wrap

% c-sdk {

static inline void i2s_32_tx_program_init(PIO pio, uint sm, uint offset, uint SDATA_pin, uint BCLK_pin, float clk_div)
{
pio_gpio_init(pio, SDATA_pin);
pio_gpio_init(pio, BCLK_pin);
pio_gpio_init(pio, BCLK_pin + 1);

pio_sm_set_consecutive_pindirs(pio, sm, SDATA_pin, 1, true);
pio_sm_set_consecutive_pindirs(pio, sm, BCLK_pin, 2, true);

pio_sm_config c = i2s_32_tx_program_get_default_config(offset);

sm_config_set_out_pins(&c, SDATA_pin, 1);
sm_config_set_sideset_pins(&c, BCLK_pin);

sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_TX);

sm_config_set_clkdiv(&c, clk_div);
sm_config_set_out_shift(&c, false, true, 32);

pio_sm_init(pio, sm, offset, &c);
pio_sm_set_enabled(pio, sm, true);
}

%}

When calling i2s_32_tx_program_init() to initialize it, clk_div should be set to the divide factor that gets you twice the I2S bit clock frequency from the SYS clock.
 
The following users thanked this post: elecdonia

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #37 on: February 23, 2023, 09:26:27 pm »
A major question for the OP is to learn what resolution is used inside the "16-bit" PJRC audio library?
I would think it'd be a major selling point if it was different, so because it doesn't say, I'm pretty sure the entire chain is 16-bit 44.1kHz.  Again, that's okay for small stuff, or just messing around, as long as you keep the signal level up.  Standalone single-module type stuff is probably fine, with an *external* volume control.  You might use it to feed a PA, for example, where the sound guy has a pro rig.  Your module has its volume all the way up, and the sound guy controls it from there.

But as soon as you start making complex processing chains with a LOT of things in series to all contribute their round-off error, and all of that needs to be "transparent" - especially if you want to include the master volume in the digital world and have some *more* processing after that and *then* feed the DAC - you really need more.

In old-school (analog) recording studios (and live-performance sound reinforcement) the audio levels for signal-processors (eq, reverb, compression, filters, noise gates) were carefully adjusted to (usually) the highest levels which didn't clip. The "Dolby" and "DBX" analog tape noise suppression systems compressed the audio before recording, then expanded it inversely on playback.
The relative position of faders (eg volume controls) in the audio chain always ended with the "master volume control." Prior to that point all levels were kept as high as possible "below clipping."
 
Can the OP's project be arranged so that "master volume" is applied in the final piece of hardware just prior to the power amps and speakers?
No.

I'm aware of all those tricks to get better quality from a recording medium that only afforded maybe 8 to 10 bits of useful dynamic range between clipping and noise floor, and I still enjoy running a pure-analog live sound rig that probably has around 14 bits or so through all of its circuitry.  (you don't normally use bits to describe analog; I'm just making the comparison)

For another example of getting better quality out of a physical medium, the RIAA curve for vinyl records essentially has tiny bass so that the stylus doesn't fly all over the surface to pick it up, and massive sibilance so that it drowns out the surface noise.  When the playback system corrects it back, it gets the bass back to (roughly) where it's supposed to be, and effectively turns down the surface noise.

But for rearranging the master volume to be all the way at the end of the chain and then making it analog, yes there are VCA's that can be controlled from a DAC, and a lot of DAC's actually have that functionality built into them anyway.  But consider how that would work with a multi-way crossover that is followed by per-driver correction and limiting.  The corrective EQ's don't care whether the volume control is before them or after, and neither do the crossover filters.  So far, the master volume could be changed from a stereo-gang before the crossover to a many-gang after the correction, but the limiters DO care.  Technically, their thresholds can be adjusted to track a gain control that follows them, so that the *output* of that gain control is never above X, but it's a whole lot easier and more intuitive (and thus more maintainable) to have the limiter literally last.  And now, because the final gain is not last, and therefore *must* be in the digital world, and because linear processing (EQ's, filters, and gains) don't care about order, it becomes easier to put the final volume control before the crossover as a stereo-gang instead of many.

Of course the consequence of this, is that the DAC now receives maybe -30dBFS most of the time, instead of -1 or so, and the amplifier is fixed at 30dB more.  Essentially, the amp is calibrated to the DAC, so that full-scale = full-scale, and never touched again.  Because the DAC receives such a low signal, it needs enough bits that it still works well.
 
The following users thanked this post: elecdonia

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #38 on: February 24, 2023, 12:14:52 am »
I wasn't thinking of using anything analog at all. My suggestion is simply that the digital function block controlling master volume would be located towards the output end of the chain, rather than early in it.

Some questions:
   Do a majority of today's sound reinforcement power amplifiers have digital audio inputs?
   For flying modular main speaker arrays: Are the power amplifiers sometimes embedded inside the speaker cabinets?
   Does the signal chain ever need to be analog at all?

(I'm asking because most of my direct experience with large sound reinforcement systems is "out of date" to say the least. My career in that field was in the 1970's and 1980's. Among other things I designed several 3-way and 4-way electronic crossovers and a limiter/protection system which reduced driver failures, especially for drivers on high frequency horns. These items, of course, were all 100% analog)

I understand the desire for maintaining 24-bit resolution past the master volume control when a considerable amount of digital audio processing must happen after the master volume. Examples of such "downstream" digital processing:
    -Digital crossover frequency low//high pass filters for the speaker cabinets
                (subwoofer-mains, additionally low-mid-high crossover filters for the main speakers if bi-amped or tri-amped)
    -Anti-clipping limiter functions
    -Thermal protection for high frequency drivers (using a simulation of their long-term power handling limits)
    -Adjustable time-alignment delay (10 or 100usec steps), especially for the relationship between mid/high frequency drivers.

To summarize:
  OP application probably does require >16-bit resolution
  That said, for early prototyping/experimentation/testing, the PJRC 16-bit audio library might still be a useful "starting point."  It already contains ready-to-use function blocks for much of what is required to make a high grade sound reinforcement system. 

   
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #39 on: February 24, 2023, 12:26:45 am »
Quote
For example, a popular cheap digital mixer, either as a console in back or a "smart stage box", uses 40-bit floating-point internally, between its 24-bit converters to and from the analog world.  Larger consoles that do more, and pretty much every DAW (Digital Audio Workstation - essentially an audio console that runs in software on a PC, with all of the extra features that that can offer) use 64-bit floating-point or better, again to keep the accumulated round-off error small enough to not matter.
There must be some libraries around for doing this level of high-resolution audio processing if the end-products are reaching the "affordable" range.
For the past 25 years the specialized TI DSP chips reigned, but it seems to me that many general-purpose MCU chips have caught up. One problem with TI is that they wouldn't even talk to prospective customers who didn't promise to order millions of their DSP chips.
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #40 on: February 24, 2023, 12:28:50 am »
You know, I never expected to have an intense discussion of high-performance digital audio processing in a forum dedicated to microcontrollers priced under $1 USD each.
My, my, how things have changed over time...
« Last Edit: February 24, 2023, 02:34:42 am by elecdonia »
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline langwadt

  • Super Contributor
  • ***
  • Posts: 4427
  • Country: dk
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #41 on: February 24, 2023, 01:22:55 am »
For example, a popular cheap digital mixer, either as a console in back or a "smart stage box", uses 40-bit floating-point internally, between its 24-bit converters to and from the analog world.  Larger consoles that do more, and pretty much every DAW (Digital Audio Workstation - essentially an audio console that runs in software on a PC, with all of the extra features that that can offer) use 64-bit floating-point or better, again to keep the accumulated round-off error small enough to not matter.

I'm sure that is also a matter of convenience and what is available. 32bit fixed point is 150dB, that would probably go a long way but with fixed point you need to think about scaling all the time, 32bit floats are not enough (only ~24bit), lots of HW has 64 bit doubles or more so that is convenient and available



 

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #42 on: February 24, 2023, 01:56:00 am »
It's not "closed" or "inaccessible."  All open source, installed as source on your computer when you add the core.
Admittedly some combination of Windows and Arduino policies can make it a bit hard to find, but in a standard windows install (using IDE 2.x), it'll end up in "C:\Users\USERNAME\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.2\cores\teensy4\"

It even looks like there might be instructions somewhere on using it with a Makefile and bypassing all of the Arduino code entirely...
Code: [Select]
extern "C" int main(void)
{
#ifdef USING_MAKEFILE


// To use Teensy 4.0 without Arduino, simply put your code here.
// For example:


pinMode(13, OUTPUT);
while (1) {
digitalWriteFast(13, HIGH);
delay(500);
digitalWriteFast(13, LOW);
delay(500);
}




#else
// Arduino's main() function just calls setup() and loop()....
setup();
while (1) {
loop();
yield();
}
#endif
}
I'll have to look at that.  Per the title, I'm on a Raspberry Pi, not Windows, but I'd imagine the folder structure to be similar, starting from the user's home.
On my Pi, it's "/home/USERNAME/.arduino15/packages/teensy/hardware/avr/1.57.2/cores/teensy4"
A little bit different after the user's home directory, but not by much.  And there appears to be a complete project in there, ready for the one "add your code here" file that the Arduino IDE shows you.

It's a bit odd that it still uses "avr" as a folder, when there's no AVR involved here, but I guess that just shows the Arduino's heritage.  Maybe that level was supposed to organize by architecture, but ended up being kept for everything?  Anyway, I think it'll work.

Of course, I had to install the board first, to get any of that:
https://www.pjrc.com/teensy/td_download.html
 

Offline elecdonia

  • Frequent Contributor
  • **
  • Posts: 399
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #43 on: February 24, 2023, 02:30:47 am »
Human hearing is logarithmic rather than linear.

In the very first days of digital audio, well before ADC or DAC devices had >12 bits, there was a remarkable yet simple hardware design called “continuously variable delta slope modulation” which sampled the analog audio at a very high rate (>50kHz), producing a single bit signifying whether the input voltage was rising or falling. Delay was generated by sending this stream of single bits through a bank of early dynamic RAM chips, often 1b by 16k, 64k, 256k memory cells per chip. The analog signal was recovered by a simple opamp integrator. I remember being quite impressed with the audio quality. It wasn’t noisy or grainy. It even measured well: THD+noise <0.5%

To summarize, a lot can be accomplished in the digital audio domain by having a thorough understanding of the underlying math. Forcing more bits through the hardware is also an effective brute-force approach. But it isn’t the only method which works.
I’m learning to be a leading-edge designer of trailing-edge technology.
 

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #44 on: February 24, 2023, 05:00:42 am »
Some questions:
   Do a majority of today's sound reinforcement power amplifiers have digital audio inputs?
   For flying modular main speaker arrays: Are the power amplifiers sometimes embedded inside the speaker cabinets?
   Does the signal chain ever need to be analog at all?
Starting with the second question: Yes.  They're called "powered speakers" or "active speakers", and they're been around for a long time now.

Originally, it was just a comparable-sized amp shoved into the same cabinet with everything else the same.  Single amp channel driving a passive crossover, and it would blow tweeters just as well as a passive rig if you turned it way up and walked away.  One venue that I worked at had a set of those, and a guy that was very good at replacing the tweeters!  I was part of upgrading that rig to digital, with the requirement that "just anybody" should still be able to use it, so I put a "postage stamp" of an analog board in there for them, which fed into the main digital one that had limiters on that feed!  The controls for the digital were kept in a locked closet, to be brought out and used only by the more skilled people, who load the defaults back in when they're done.

Now though, the line-level input feeds an ADC into a DSP with only a handful of user-accessible settings, and that DSP drives a dedicated amp channel for each driver.  This allows per-driver correction and protection, and relaxes some of the acoustic design requirements, as the things that are easily corrected electronically don't have to be accounted for anymore when building the box.  So the acoustic design can focus only on what the electronics still can't do very well, and the combination produces the most accurate box possible in terms of converting a small electrical signal into far-field air pressure.  (within the constraints, of course, that a mass market puts on the overall architecture - the classic over/under woofer/tweeter box is not all that good, but it's what people are used to and therefore want)

Most powered speakers (that are sold to the general public) also have multiple inputs, with XLR/TRS combo jacks and a mic preamp for at least one of them.  If you only have a single mic, then you don't even need a mixer: just plug the mic directly into the powered speaker and use the mic/line switch to turn the preamp on.  (I have yet to see one with phantom power, so dynamic mics only)

For the first question, some amps do have digital inputs, even networking (Dante, for one example), so that the only analog in the system at all might be the mics and the amps' power stages (Class-D is still very much analog, despite the on/off output devices), but pretty much all of them still have analog inputs available.  The ones that have DSP built-in have an ADC following the attenuator; otherwise it feeds into the amp itself as usual, even for Class-D.

For the third question, analog is a very effective and easy way to resample.  Have a DAC feed an ADC, with each controlled by a different system with its own clock, and it "just works".  Digital resampling can be enough of a hassle to just hang the whole thing and do that instead.  If one system wants to change its sample rate, then it can tell its converter to do that, and the other doesn't have to know or care.  So in otherwise all-digital rigs, there may still be some analog links in a few places.  DAC's to amps, for one example.
Of course, *anything* in the analog world is subject to the analog rules, including headroom and noise pickup, so it still has to be done *right*.

I understand the desire for maintaining 24-bit resolution past the master volume control when a considerable amount of digital audio processing must happen after the master volume. Examples of such "downstream" digital processing:
    -Digital crossover frequency low//high pass filters for the speaker cabinets
                (subwoofer-mains, additionally low-mid-high crossover filters for the main speakers if bi-amped or tri-amped)
    -Anti-clipping limiter functions
    -Thermal protection for high frequency drivers (using a simulation of their long-term power handling limits)
    -Adjustable time-alignment delay (10 or 100usec steps), especially for the relationship between mid/high frequency drivers.
Yes to all of the above, except that the thermal protection could easily be measured instead of simulated.  Just put a thermal probe in there, connected to the DSP logic...
And for that matter, I've also seen accelerometers on the speaker cone...

To summarize:
  OP application probably does require >16-bit resolution
  That said, for early prototyping/experimentation/testing, the PJRC 16-bit audio library might still be a useful "starting point."  It already contains ready-to-use function blocks for much of what is required to make a high grade sound reinforcement system. 
Pretty much, yes.  Though I've done enough research with the idea of rolling my own, that I think I'm ready to just do that instead of learning a library (even if it barely takes anything to learn) and then ditching it because I need more.
https://dspguru.com/
https://webaudio.github.io/Audio-EQ-Cookbook/audio-eq-cookbook.html
https://www.musicdsp.org/en/latest/Filters/64-biquad-c-code.html
https://www.musicdsp.org/en/latest/Analysis/186-frequency-response-from-biquad-coefficients.html (to read back what it's actually doing)
https://www.earlevel.com/main/2012/11/26/biquad-c-source-code/
https://www.earlevel.com/main/2003/03/02/the-digital-state-variable-filter/
Etc.
That's just for frequency filters.  Similar for dynamics and other things.

And I've done enough live sound that I know what the "black box" modules do anyway.  No need to learn that; just how to make them in software.  Or find a suitably-licensed library that is also suitable for my end use.

Human hearing is logarithmic rather than linear.
Sorta.  Perceived amplitude is logarithmic, which is probably what you're referring to.  But the process itself is quite the exercise in Linear Systems.  It's not a single microphone per ear, but a series of acoustic bandpasses followed by peak detecting nerves.  A "biological RTA", if you will.  Before all of that is an acoustic/mechanical gain element (with a non-flat frequency response if you pay attention) that is controlled by the average of that RTA.  A "feedback compressor".  Older ears lose the ability to gain-down, which is probably why they complain more about volume.  It really IS louder for them, and painful, and at risk of losing more sensitivity, while the young kid next to them is perfectly fine.  (if your grandpa took you to a concert, he probably sacrificed more than you realized to make your day)

Also, because of that system architecture, the risk of pain and hearing loss depends on the mix and is not a single number.  A narrow, prominent range of frequencies, like a screaming guitar amp that shoots past the musician's knees and drills a hole in the back wall, leaves the RTA-average low enough to not activate your compressor, and so that range gets blasted even with young and healthy ears.  But if you turn UP the rest of the band to match (mix it well), then the average is high enough to make the compressor work, and then it's fine.

So it's important to have a FOH Engineer that knows what he's doing, on a rig that covers well, and keep the stage as quiet as possible.  No "acoustic spotlights" coming directly off the stage.  There are ways to do that without killing the "perfect" guitar sound: USE THEM!!!  A speaker-level DI, for one example, with a dummy load in place of the speaker, and the Monitor Engineer feeds a healthy amount of that back to the guitarist's floor wedge or IEM.  (In-Ear Monitor; basically glorified ear-buds)
(About that dummy load: Never run a tube/valve amp open-circuit.  It'll saturate the output transformer, which then becomes a short-circuit to the amp itself.  They tend to blow up when you do that.  Always have some kind of a load attached whenever it's powered on, that matches its rated impedance.  Likewise for a solid-state amp with a transformer output, though the relative cheapness of transistors means that it *might* (!) actually have enough additional circuitry to protect itself.  Still won't sound the same though, without enough load to keep the protection from activating.  Solid-state with no transformer is fine to run open.)

(Also, for smaller gigs, FOH and ME are probably the same guy, but a fair number of rigs are starting to have musician-controlled monitors now, either from a personal mixer that receives multitrack from the FOH board or a phone/tablet app that directly controls their output of the board.)

In the very first days of digital audio, well before ADC or DAC devices had >12 bits, there was a remarkable yet simple hardware design called “continuously variable delta slope modulation” which sampled the analog audio at a very high rate (>50kHz), producing a single bit signifying whether the input voltage was rising or falling. Delay was generated by sending this stream of single bits through a bank of early dynamic RAM chips, often 1b by 16k, 64k, 256k memory cells per chip. The analog signal was recovered by a simple opamp integrator. I remember being quite impressed with the audio quality. It wasn’t noisy or grainy. It even measured well: THD+noise <0.5%

To summarize, a lot can be accomplished in the digital audio domain by having a thorough understanding of the underlying math. Forcing more bits through the hardware is also an effective brute-force approach. But it isn’t the only method which works.
With such low bit depth, you'd need a lot higher sample rate than that to produce decent quality.  (50MHz, maybe, not kHz)  But that's still the basic principle behind a modern audio ADC: sample in the low- to mid-MHz range, run a high-order digital lowpass at that rate with a corner frequency below Nyquist for the final output rate, and then pick samples out at that final rate to send to the world.  The high initial sample rate and digital lowpass mean that the analog anti-aliasing filter doesn't have to be anything special - its Nyquist target is in the MHz range - and the effective averaging of high-frequency noise fills in the lower bits of what would otherwise be a crummy converter.

That's also the (very) basic concept of a digital resampler: stuff a bunch of zeros between input samples to make a much higher sample rate, lowpass that at the high rate with a suitable corner frequency for Nyquist at the output rate, and pick samples out at the new rate.  Of course, there are TONS of optimizations that are mathematically equivalent to that, but don't require nearly as much processing power.  For example, if you're using a Finite Impulse Response (convolution) lowpass, then each output sample is calculated independently, and so you only have to run the filter at the output rate, not the high intermediate one.  If you're using an Infinite Impulse Response (more like analog behavior), then every output sample depends on everything, so you do have to do ALL the work.  But IIR requires much less effort per sample than FIR, so without optimized hardware for either one, I'm not really sure which is "better".

Something else that I find fascinating to consider, is the idea that the universe is inherently digital because quantum.  That allows me to compare the translation between different digital systems, with the translation between digital and analog.  In that context, it's almost the same thing: convert to stupidly-high quality, then back down to what you want to end up with.  The universe is simply that high-quality digital...except for the unavoidable noise that completely drowns out that amount of detail.

You know, I never expected to have an intense discussion of high-performance audio signal processing in a forum dedicated to microcontrollers...
My, my, how things have changed over time...
:)
I find myself comparing the RT1062 to an earlier Raspberry Pi.  I would not be surprised if someone got a Linux kernel to run on a Teensy 4.x.  So what's a microcontroller?  And what's a desktop PC?  Is there much of a difference anymore?  :-//
I also think about the early days of computing: entire rooms, eventually shrinking to something that would (barely) fit on a desk, with an amount of processing power that we solidly associate with 10-year-old microcontrollers today.  Those were the pioneers of today's desktop systems, so could such a "desktop" system be built on one of our 10-year-old microcontrollers?  (my guess is yes, with some caveats)
« Last Edit: February 24, 2023, 05:12:30 am by AaronD »
 

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #45 on: February 24, 2023, 06:13:14 am »
A major question for the OP is to learn what resolution is used inside the "16-bit" PJRC audio library?
I would think it'd be a major selling point if it was different, so because it doesn't say, I'm pretty sure the entire chain is 16-bit 44.1kHz.

...in a standard windows install (using IDE 2.x), it'll end up in "C:\Users\USERNAME\AppData\Local\Arduino15\packages\teensy\hardware\avr\1.57.2\cores\teensy4\"
I'll have to look at that.  Per the title, I'm on a Raspberry Pi, not Windows, but I'd imagine the folder structure to be similar, starting from the user's home.
On my Pi, it's "/home/USERNAME/.arduino15/packages/teensy/hardware/avr/1.57.2/cores/teensy4"
...there appears to be a complete project in there...

Part of that project is a module called "AudioStream", that has both a header (.h) and a source (.cpp) file.  Towards the top of the header file is:
(broken up into separately scrollable sections, if your viewer is small enough to require that, and some parts omitted for clarity)
Code: [Select]
// AUDIO_BLOCK_SAMPLES determines how many samples the audio library processes
// per update.  It may be reduced to achieve lower latency response to events,
// at the expense of higher interrupt and DMA setup overhead.
//
// Less than 32 may not work with some input & output objects.  Multiples of 16
// should be used, since some synthesis objects generate 16 samples per loop.
//
// Some parts of the audio library may have hard-coded dependency on 128 samples.
// Please report these on the forum with reproducible test cases.  The following
// audio classes are known to have problems with smaller block sizes:
//   AudioInputUSB, AudioOutputUSB, AudioPlaySdWav, AudioAnalyzeFFT256,
//   AudioAnalyzeFFT1024
Code: [Select]
#ifndef AUDIO_BLOCK_SAMPLES
#define AUDIO_BLOCK_SAMPLES  128
#endif

#ifndef AUDIO_SAMPLE_RATE_EXACT
#define AUDIO_SAMPLE_RATE_EXACT 44100.0f
#endif

#define AUDIO_SAMPLE_RATE AUDIO_SAMPLE_RATE_EXACT
Code: [Select]
typedef struct audio_block_struct {
uint8_t  ref_count;
uint8_t  reserved1;
uint16_t memory_pool_index;
int16_t  data[AUDIO_BLOCK_SAMPLES];
} audio_block_t;

So it looks like this Audio Library is indeed 16 bits all the way through, with a default buffer of 128 samples and a strong recommendation to not change that.  I would also not be surprised if at least some of the modules were hard-coded for the default sample rate too, so changing that will result in all of their frequencies being off by that much.  (DSP functions know nothing about time, only samples)

The default buffer size at the default sample rate gives 128(samp) / 44100(samp/sec) = 0.0029(sec), or 2.9ms, of latency.
For comparison, the pro digital thing that I mentioned in an earlier post specifies 0.8ms analog to analog.  Having read the datasheet for several different audio ADC's and DAC's, I'm convinced that most if not all of that is in the converters, not the DSP.  So that DSP probably runs a single sample all the way through.  Buffer of 1, or no buffer, depending on how you think of it, and that's also what I think a later one of my projects is going to need.

That later project will effectively undo the acoustic lowpass through a wall that can't be removed (and a bunch of other things, but that's the core function), and so its analog-to-analog latency needs to line up with the speed of sound across a short distance.  At ~13.5in/ms (~34.3cm/ms), that's not very long, so I'm looking at running that system at a higher sample rate, just to allow the converters to use less-aggressive filters and thus reduce the latency by several samples *in addition to* having less time per sample.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6265
  • Country: fi
    • My home page and email address
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #46 on: February 24, 2023, 09:49:23 am »
Just like all the other parts of Teensyduino, the source code for the Audio library can be found at Paul Stoffregen's Github, specifically the PaulStoffregen/Audio repo.  They are quite permissively licensed, so you can create your own derivative, using either single-precision floating-point (24 bits of precision, Teensy 4.x does have single- and double-precision support in hardware), or 32-bit integer/fixed point for computation, or even double-precision floating point (53 bits of precision).

Also note that that library works with the Audio System Design Tool for Teensy Audio Library, a standalone HTML+JS tool that works in your browser (no server or internet connection needed), and can generate the Arduino sketch (source code) needed to implement the graphically defined audio system.
 

Offline AaronDTopic starter

  • Frequent Contributor
  • **
  • Posts: 260
  • Country: us
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #47 on: February 24, 2023, 01:37:36 pm »
Just like all the other parts of Teensyduino, the source code for the Audio library can be found at Paul Stoffregen's Github, specifically the PaulStoffregen/Audio repo.  They are quite permissively licensed, so you can create your own derivative, using either single-precision floating-point (24 bits of precision, Teensy 4.x does have single- and double-precision support in hardware), or 32-bit integer/fixed point for computation, or even double-precision floating point (53 bits of precision).
Nice!  But I didn't see a license file in there.  As I understand, the legal answer is "no", unless specified otherwise, and I don't see the specification otherwise.  Where is that?

There's still the 128-sample buffer that I'd rather not have (that's probably to allow the audio design to co-exist with a naive sketch without dropping out), so it's not just a matter of changing the datatype.  But I can't imagine it'd be *too* hard to read Paul's source, understand what it does, and write my own from that...once I see the license for myself and like it.

The multi-way speaker system that I described earlier is fairly low-power.  16-ohm "junk drawer" speakers, probably bridged, from a 12-24V DC supply.  (yes, I know that's a big range; I'll figure it out later)  I'm currently bridging them from the 12V rail of an ATX supply without a sub, and I could use a bit more than that.  I have a powered sub waiting to go in once I figure out the processing, so I guess I'll see what that does first.  Taking the bass out of the mains is going to help a lot by itself.

Another project idea is for an actual PA, and was originally going to use a 19" rack of small DSP amps that all get the same analog signal to drive a 4-way "true full-range" system.  No separate sub needed.  I'm starting to think about using a Teensy4 / RT1062 for that too: forget the rack entirely, and just mount the custom PCB('s) directly on/in the cabinet.



Also, I've not had good experience with the Pi Pico's tinyusb library for audio.  It works at first, but there seems to be a bug somewhere that gets it "stuck" when the host stops sending samples.  When the host restarts, tinyusb doesn't.  Since one of my projects is going to need ~8 tracks of high-quality audio each direction between itself and a PC, how's the Teensy USB library?
« Last Edit: February 24, 2023, 01:43:01 pm by AaronD »
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6265
  • Country: fi
    • My home page and email address
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #48 on: February 24, 2023, 02:47:22 pm »
Just like all the other parts of Teensyduino, the source code for the Audio library can be found at Paul Stoffregen's Github, specifically the PaulStoffregen/Audio repo.  They are quite permissively licensed, so you can create your own derivative, using either single-precision floating-point (24 bits of precision, Teensy 4.x does have single- and double-precision support in hardware), or 32-bit integer/fixed point for computation, or even double-precision floating point (53 bits of precision).
Nice!  But I didn't see a license file in there.
The license is at the beginning of each file.  It makes accepting contributions from other developers clearer; the license is impossible to miss.

But I can't imagine it'd be *too* hard to read Paul's source, understand what it does, and write my own from that...once I see the license for myself and like it.
As you can see in the contributor graph, it's not just Paul, but quite a few PJRC forum regulars and contributors in there.  But the code is indeed quite clean, once you get used to the mixed freestanding C/C++ style used.

Since one of my projects is going to need ~8 tracks of high-quality audio each direction between itself and a PC, how's the Teensy USB library?
Even over USB Serial (which on the Linux end has quite a bit of overhead, as it goes through the tty layer), I can sustain well over 200 Mbit/s in one direction.
Even 32-bit 192 kHz raw audiostream is just 6.144 Mbit/s, so the USB is definitely not a problem.

In case you haven't realized, RPi Pico only supports USB 1.1, 12 Mbit/s, whereas Teensy 4.0/4.1/MicroMod supports USB 2.0, 480 Mbit/s.

Teensyduino itself supports various combinations of USB endpoints (like USB HID + USB Serial), as in selectable directly from the Arduino GUI, so multi-endpoint USB is also well supported.  Teensy 4.0/4.1/MicroMod supports 8 bidirectional endpoints on each USB controller.  (They have two OTG/EHCI HS/FS/LS USB cores, core 0 wired to the programming USB connector, with the other on pads in 4.0 and pins in 4.1.)
 
The following users thanked this post: newbrain

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6723
  • Country: nl
Re: i.MX RT1062: Getting Started, on a Raspberry Pi?
« Reply #49 on: February 24, 2023, 03:24:59 pm »
The Tympan library is an expanded reimagining of the Teensy audio library for 32 bit floating point, created for the Tympan hearing aid project.
 
The following users thanked this post: elecdonia, Nominal Animal, AaronD


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf