Teensy 4.0 & 4.1

[rdagger]

The Teensy 4.0 build was missing the MCK pin definitions. I added them, rebuilt the binary, and committed the updated binary. Hopefully it works now.

Unfortunately, it's not working. I'm getting the following error:

File "<stdin>", line 1, in <module>
File "demo_play_wav_hp.py", line 55, in <module>
File "sgtl5000.py", line 543, in __init__
File "sgtl5000.py", line 1130, in write_word
OSError: [Errno 19] ENODEV

line 55 initializes the codec:

Code: Select all

codec = CODEC(0x0A, i2c)

I reverted to the 4.1 firmware and it's working again.

[Mike Teachman]

I found the problem, which also exists in the newer prototype Teensy 4.1 firmware: In the new Teensy prototype firmware, the MCK frequency ("Fmck"), is set based on the sampling frequency ("Fs"). Fmck = Fs * 256. The *256 multiplier is typical for MCK. Previously, Fs was set to a much higher fixed frequency. So, why does the new means of deriving Fmck cause a problem? Ans: The SGTL5000 device needs to have a MCK signal before I2C will work, and that MCK signal must be > 8MHz. When Fs = 16kHz, which is used in the example code, Fmck = 16kHz * 256 = 4.096MHz, which is < 8MHz. Thus, I2C does not work.

Here is an experiment to try: set SAMPLE_RATE_IN_HZ = 44100 in the example file. The example should now work, with audio played at the much higher frequency.

With this prototype firmware, the Teensy audio shield will only work with audio streams that have Fs >= 32kHz

I am considering what options, if any, should to be added to the mimxrt I2S implementation to accommodate this questionable design choice in the SGTL5000 device.

[rdagger]

Here is an experiment to try: set SAMPLE_RATE_IN_HZ = 44100 in the example file. The example should now work, with audio played at the much higher frequency.

It worked at the higher frequency with sample rates set to 44100 and 32000.

I can't think of any elegant solutions. Sorry I have a limited understanding of how the clocking works so the following might be ill-advised:
What about adding an option to add an external 11.2896 MHz oscillator to drive the MCK (44,100 x 256)?
What about letting the SGTL5000 be the I2S master so it's PLL would be available?

[Mike Teachman]

I am strongly considering that a limitation for using the Teensy audio shield is Fs>=32kHz. The Teensy Audio Library uses a fixed 44.1kHz as documented here. There seems to be no reason for MicroPython I2S to improve upon this limitation.

[alphaFred]

Please forgive my ignorance but would there be any use-case for lower sampling frequencies? Isn’t 44.1kHz the most used sampling frequency as it is used with CDs?

[Roberthh]

You do not need CD quality for all applications. See the table in https://en.wikipedia.org/wiki/Sampling_ ... rocessing)

[rdagger]

I’m trying to write an example of recording the stereo line input to a WAV file on the Teensy Audio adapter SD card:

demo_record_wav_li.py

The audio sounds good in the headphones while recording, but the 10 second audio clip takes 26 seconds to record. The resulting WAV file is 10 seconds long and sounds terribly choppy. Is the SPI SD card connection too slow and/or did I mess up the recording parameters?

[Roberthh]

Most probably the SPI based sdcard.py driver is too slow. I had that effect when playing from a SPI flash chip with LFS.
Check if the SPI baud rate is set to 40MHz. On Teensy 4.1, the SDard is connected to the USHDC port, which is way faster.
P.S.: I wonder how a 10 second long recording can take 26 seconds. Is one part of the setup moving at almost the speed of light?

[alphaFred]

We use 50MHz 4bit parallel interface with USDHC. Which should be hard to match with SPI. The peripheral supports even more if you have a certain card but I have not yet implemented these modes in the driver.

[rdagger]

Most probably the SPI based sdcard.py driver is too slow. I had that effect when playing from a SPI flash chip with LFS.
Check if the SPI baud rate is set to 40MHz. On Teensy 4.1, the SDard is connected to the USHDC port, which is way faster.
P.S.: I wonder how a 10 second long recording can take 26 seconds. Is one part of the setup moving at almost the speed of light?

I tried several SPI baudrates between 1 MHz (default) and 40 MHz. Regardless, the recording process always took 26 seconds and the resulting 10 seconds WAV sounded the same.