Status of Audio Library for Teensy 4.x?

Status
Not open for further replies.

cadr

New member
Hello,

What is the current state of support for the Teensy 4.x from the Audio Library? From reading the forum, it seems that it works and that people are actively using it, but the readme on github only talks about 3.x. Is this just a documentation issue?

Thank you!
 
Well also there is the issue of the Teensy 4.0/4.1 not having a DAC pin (DAC is digital -> analog, basically analogWrite will modify the voltage on the pin, rather than rapidly turning it off/on like it does for digital pins). The DAC pin allows you to play low quality mono sounds (3.2) or stereo sounds (3.5/3.6) by hooking up the DAC pin(s) to an amplifier and speaker without using an audio board.

Do note the pin assignments for the Teensy 4.0/4.1 for audio stuff (and spi) is different from the pin assignments for the Teensy 3.2/3.5/3.6. If you use the audio board, you will need revision D of the board for Teensy 4.0/4.1 (use revision C for Teensy 3.2/3.5/3.6).

The Teensy 4.0/4.1 also has a second I2S bus and direct S/PIDF support that the audio library can use.
 
Right, was aware of the lack of DAC.

So, if one is using the correct version of the Audio Board, and one doesn't need ADC, one should be good?

(I'm assuming when Frank says "ADC does not work good", he means as actual audio in, as apposed to reading values like from a potentiometer?)
 
Yup, normal analogRead() works fine.

Eventually I'll get back to the ADC code and improve it...

The only other issue I know is MQS doesn't play nice with I2S and probably others. Apparently it needs the audio clock configured differently. But the design tool doesn't know this.
 
Yup, normal analogRead() works fine.

Eventually I'll get back to the ADC code and improve it...

The only other issue I know is MQS doesn't play nice with I2S and probably others. Apparently it needs the audio clock configured differently. But the design tool doesn't know this.


OK, I can take a look in the next days.
I was not aware that MQS is problematic?
 
The "analog in" is a, and will be a problem anyway, because is uses a different sampling frequency.
If you want a clean solution the only way is to use 41117.6 kHz for the whole lib. But its's a little late for that change.. possible that this would be a breaking-change for some existing things.
There is a little bug in the calculation for the timer, too. The equation needs a -1 added. Then, it will not work if you change the cpuclock.

Perhaps we just should declare it as "experimental" .. forever :)


I had the idea to use a unused I2S (SAIx) to output LR-Clock to a non-existing Teensy-pin and use that to trigger the analog-in-DMA. It is just an Idea, and I don't know if that would work.
 
Just took a quick look @ MQS: I think an easy fix would be to just use PLL5 as clock source for SAI3.
 
The "analog in" ... uses a different sampling frequency.
If you want a clean solution the only way is to use 41117.6 kHz for the whole lib.

Then USB audio becomes "unclean" (as it is with Teensy 3.x).

I would prefer these problems all on-chip and 100% within our control, rather than between Teensy and USB hosts we can't fully anticipate on different operating systems.

Likewise for some distant future when we support audio devices in the USB host library!


Perhaps we just should declare it as "experimental" .. forever :)

Yeah, I probably won't find time to work on it again until after 1170 is released. Then we will have the ASRC peripheral which will make all these "unclean" things feel not so expensive.

Today 1170 feels like forever, but it will come.


I had the idea to use a unused I2S (SAIx) to output LR-Clock to a non-existing Teensy-pin and use that to trigger the analog-in-DMA. It is just an Idea, and I don't know if that would work.

That is a really interesting idea. Can we use SAI3 that way and still have it work for MQS?
 
I have to read sourcecodes and the manual to answer this... I'll do that.

USB-Host: Yup, but even 44100 are unusual.. I own several cheap USB-Audio soundcards that allow 48kHz only.
...maybe a 1170 thing, too...
 
Isn't the only reason for 44.1 the Windows wav-files ? It's easy to convert them before storing them to SD.
I'd really like to see 48kHz as default samplerate on the 1170. ASRC can then be used to convert the wave-files.. if really needed.
I had proposed a "audio-lib ext" or "pro" which does 48kHZ for all 3.x Teensies. It's better for S/PDIF, too. And yes, perhaps it should use floats (If it was for Teensies with floating point ..)
 
Ok, it seems SAI3 uses:

SAI3_TX_SYNC: GPIO_EMC_39 ALT3
SAI3_TX_SYNC: GPIO_SD_B1_02 ALT8

Both are not connected to any Teensy pins, so that looks good.
For the clock, I think we have a conflict and we can either use Analog-in or MQS, then. (I think that's better than using analog-in at 44117Hz. )

What do you think, Paul? What should I do?

a) use PLL 5 for SAI3, try to trigger analog-in with SAI3 (with the GPIOs above) and stilll use it for MQS, (which would conflict) or
b) leave Analog-in clock as it is, and modify MQS to use PLL5 only?

or, we can use SAI2 for the ADC - as it would use the normal frequencies, I don't see a conflict. The SYNC just had to trigger the analog-in, additionally. But I'm not sure if we can disable the pin if it's not needed for devices connected to SAI2.

Does anything else use PLL5? It's needed to change its frequency.
 
Last edited:
SAI2: Yes but we only need the "sync". It would work as before.

Edit: At least, at the moment, I think that. There's a chance that I'm wrong :)
 
Last edited:
Hm, yes. Ok, so it will be SAI3. I'm a bit confused by all the frequencies, and this evening i'll enable the SAI3 Sync for a test and see what frequency it has (and if it's probably possible to reconfigure divisors or oversampling).
After that i'll look at all these XBAR, IOMUX and ADC_ETC configs... hell on earth :)
At least, the ADC_ETC seems to be able to trigger two channels.
 
My Idea to use a unused PAD does not work, at least I found no way to trigger a DMA or the ADC with it.
 
The only other issue I know is MQS doesn't play nice with I2S and probably others. Apparently it needs the audio clock configured differently. But the design tool doesn't know this.

https://github.com/PaulStoffregen/Audio/pull/382

Just reduces the inbuilt-Hardware-Oversampling. I can hear no difference.
It would be good if you post a circuit that connects to the MQS-Pins. I.E a simple low pass (pwm-Freq is 352kHz)
An alternative would be to use 176kHz with the old 64x oversampling. I don't know which variant is better. For my ears, both sound pretty the same.
 
My current thinking is we'll only offer USB host audio support on boards with the ASRC hardware.

Paul, have you considered USB host audio support without offering sample rate conversion before the 1170 with ASRC hardware?

I'm asking since I'd like to put together a multitrack USB audio logger, with a Teensy 4.1 acting as host to a class-compliant audio interface (like a Focusrite Scarlett or an Expert Sleepers ES-8.) That would allow making music and recording it without having a laptop with a DAW running, taking advantage of the AD converters in the audio interface.

For anyone interested, I found this 2012 article with good foundations (in addition to the USB spec):
https://www.edn.com/fundamentals-of-usb-audio/

Thank you,
Knut
 
Paul, have you considered USB host audio support without offering sample rate conversion before the 1170 with ASRC hardware?

I'm asking since I'd like to put together a multitrack USB audio logger, with a Teensy 4.1 acting as host to a class-compliant audio interface (like a Focusrite Scarlett or an Expert Sleepers ES-8.) That would allow making music and recording it without having a laptop with a DAW running, taking advantage of the AD converters in the audio interface.

For anyone interested, I found this 2012 article with good foundations (in addition to the USB spec):
https://www.edn.com/fundamentals-of-usb-audio/

Thank you,
Knut

The focusrite is a host?
Really?

I thought it was just a usb device. All teensy 3.x or 4.x can act already as a USB audio device.
The user Blackaddr has a made a nice guitar interface with WM8731 audio codec for teensy. Haven't looked at his software so far, but I think it can act as usb-audio, too.

Adding recording shouldn't be complicated - or, maybe, it can do that already.

I'm working on a slightly modified version with headphone connection and display+some knobs and switches.
 
Last edited:
Status
Not open for further replies.
Back
Top