Teensyduino 1.52 Beta #1

Status
Not open for further replies.
Audio ADAT testing results

So i've tested ADAT, SPDIF and USB audio on Teensy 4.0, Windows 10 pro x64 1909 all recent.

Results for type "Audio":
Works only for DirectSound. input output are functional.
Strange behavior in device manager: three endpoints listed under Audio inputs and outputs.
This even after USB oblivion or manual removal of all present and nonpresent entries of teensy.

Soundmapper works input and output, links to DirectSound.

Teensy reports to WASAPI as device, but no input or output channels available at no sample rate or format, no shared, no polled.
Looks like an error in the device descriptor.

WDM streaming fails.

ASIO non existent.

Results for USB type "Serial + MIDI + Audio":
Nothing works.
No trace seen on device manager, no serial port, ni media device, nothing.
To reprogram Teensy4.0 needs pressing the button.

Results for USB type "Serial + MIDIx16 + Audio":
Nothing works.
Same as above.

Audio Library:

PWM Audio not working.

SPDIF output: signal has unstable clock, phase errors >25%. Needs very wide PLL window on input to produce crackle free signal. Nonstandard sample rate.

ADAT output: signal not decodable by E-mu, Motu, Alesis. Unstable word clock, phase lost. Wide window makes no usable channel data.

------

Sorry to have no good news here.
With older Teensyduino on T3.6 I have the same as the tested projects running in existing hardware, except for ADAT, which I never used with Teensy.
Actually I have no unused T3.6 around to check if things work there, but for T4 :mad:
 
Audio Library:

PWM Audio not working.
Yup, that was expected.


SPDIF output: signal has unstable clock, phase errors >25%. Needs very wide PLL window on input to produce crackle free signal. Nonstandard sample rate.
Which SPDIF? There are three. Which samplerate did you get?

ADAT output: signal not decodable by E-mu, Motu, Alesis. Unstable word clock, phase lost. Wide window makes no usable channel data.
I'm surprised that it has *any* output. So, someone worked on it?
Edit: Looked at the source. How did you get a signal?
 
I'm surprised that it has *any* output. So, someone worked on it?
Edit: Looked at the source. How did you get a signal?

Uh, yes, that may be why. The amplifier of the optical input is running up AGC unil it tries to sync to some noise. But TX LED is on (Edit) or off, shows last state of pin.

Which SPDIF? There are three. Which samplerate did you get?
SPDIF. Pin 14. Did not check for more.
Actually it changes so fast, the display is not readable. Nominal output should have been 44100.
(Edit) Thought the sound on SPDIF is the sine wave of my test, but actually the output has no relation to the generated data.

Consider not functional.
 
Last edited:
ADAT: I'm still suprised that there is activity on the pin.

Spdif: So, SPDIF3 ? sure?
I test that again, thanks for the Info.
 
Last edited:
SPDIF Question: Are you using a optical connection, or did you build something else?
At the scope it looks ok - have to re-build my hardware first (and find the parts ;) , to do more tests.
 
Connected a TOTX to Pin 14. It s a used part from a known-good device, as thanx to the C there is nothing else available, except useless time.
It seems to have a schmitt trigger inside which leads to the result of the LED hanging to the last active input, either on or off.

I just did bluntly follow the documentation available on PJRC.com, so did not invest more time needed to debug or trace anyting. Actually, like any customer would do.
If Pin 14 is not SPDIF, then it should be noted somewhere.
If ADAT uses a different pin, it should be noted somewhere.
etc...
 
Ok, as I read some days ago that it worked for an other user, I'll do no test and assume your test was wrong. ok?

We all know the documentation is wrong and unusable for T4-Audio.
Not working PWM was noted on the first page of this thread.


There are three SPDIFs, the third is on PIN 14, yes.

Edit: PS: Feel free to fix ADAT for T4* - you seem to have the Hardware. Neither Paul nor I, nor anybody else I know seems to have it. So, we can not work on it.

*or any other problems.
 
A beta test requires some kind of beta documentation somewhere. If things have to be trailed by testers and there are assumptions on a crystal bowl involved, it is not even an alpha trest. So my test had no chance to be right. Good. And out.
 
Agreed.
I have some time tomorrow. If I feel like it, I'll fork the GUI and create a T4-Variant.
Not sure about that, since it is a lot of work and I have no Idea if that would ever be merged.
(in contrast my PWM-Stub that _not_ should have been merged as I noted on many different places):confused:
 
I've tested it. At least it works with a cheap $10 SPDIF->Analog converter :)

I've attached my Sketch.

Code:
#if !SPDIF_NATIVE
AudioOutputSPDIF       spdif1; //Pin 7
AudioOutputSPDIF2      spdif2; //Pin 2 
#else
AudioOutputSPDIF3      spdif3; //Pin 14
#endif
Seems that the SPDIF via I2S (AudioOutputSPDIF, AudioOutputSPDIF2) does not play nice together with the native port, AudioOutputSPDIF3
Not sure why, and I don't know if I can fix that. Any ideas?

Image1.png
 

Attachments

  • spdif_out-200321a.zip
    51.4 KB · Views: 88
I've dug through the source code. Quite cryptic, but doable at least to some extent. So I understand it is no parity generated, no frames marked, actually even not closed.
At the end it may be the reason why it works on a 10 Euro chingchang DAC, but other equipment would reject.
Also, there is a 50/50 chance the channels get swapped without notice and recovery, if for some reason sync gets lost on a single frame.
If the signal contains any kind of noise (broken/pinched fiber, too long, plug not fit), the DAC will produce screaming noise, because parity and validity must not be used to check the data, before producing them to the ear.
AES interoperability not possible, because AES equipment is normally more strict than the chingchang DAC.
Right? Did I miss anything?
Sorry, I have no pure S/PDIF"light" equipment to test the signal.
 
Hi Paul,

I seem to be running into a bug related to USB audio, after programming, Teensy loader gives a message "error sending reboot command", and I manually need to press the button on the Teensy to make it reboot every time I program it. After that, USB audio (both input and output) work fine.
The issue does not appear when loading code that does not use USB audio.

Wouter Jan PE4WJ
 
No, not anything. For SPDIF3, this is all done in hardware, for the others in software. Parity is there, frame markers are there, you can mute the signal (of course not automatically) - uses the valid flag.
Did I miss anything?
yes. all :)

Oh, and it works on my 900€ receiver, too, and never heard of anyone - at least on t3 - who had problems (only with the 41117Hz samplerate on t3). Be sure: you're not the first who uses it :)
For T4 there can be bugs - quite possible. Please report them if they are reproducabl - but no blind guesses, please.
 
Hi Paul,

I seem to be running into a bug related to USB audio, after programming, Teensy loader gives a message "error sending reboot command", and I manually need to press the button on the Teensy to make it reboot every time I program it. After that, USB audio (both input and output) work fine.
The issue does not appear when loading code that does not use USB audio.

Wouter Jan PE4WJ

Same here.
Plus the other issues with USB audio from post233510
 
I was not writing about SPDIF3 "Hardware", but about the SPDIF and SPDIF2 emulations in software. The hardware part of T4 should be standard if calling itself S/PDIF. Obviously the tool is not usable for this any more. Te crystal ball did not show that.
 
It's not true for the emulations, too. Yes, put your crystal ball away.

If there are any problems, please fix them instead wasting time for blind guesses.
Would be nice if you fix ADAT for T4. You're one of the few users who have ADAT hardware.
 
As I do not understand anything, I seriously doubt that I am able to make ADAT work. :p

Please, it would be much more needed to have the documentation and the "Audio System Design Tool for Teensy Audio Library" adjusted to avoid any useless guesses.
 
@others:
As we can not help with the website (which does not even mention the Teensy 4 on many places), it would be good to help with the WIKI and add missing information there.
 
So I've figured out the different pins of S/PDIF on T4. And it is working. Thanks @Frank B

Still, ADAT I canot get to work. It compiles, but no usable signal on the new pin, which should be also Pin 7, like at SPDIF, not 22. Still WIP.

Is there the error somewhere?
Code:
void AudioOutputADAT::config_ADAT(void)
{

	CCM_CCGR5 |= CCM_CCGR5_SAI1(CCM_CCGR_ON);
//PLL:
	int fs = AUDIO_SAMPLE_RATE_EXACT;
	// PLL between 27*24 = 648MHz und 54*24=1296MHz
	int n1 = 4; //SAI prescaler 4 => (n1*n2) = multiple of 4
	int n2 = 1 + (24000000 * 27) / (fs * 256 * n1);

	double C = ((double)fs * 256 * n1 * n2) / 24000000;
	int c0 = C;
	int c2 = 10000;
	int c1 = C * c2 - (c0 * c2);
	set_audioClock(c0, c1, c2);

	CCM_CSCMR1 = (CCM_CSCMR1 & ~(CCM_CSCMR1_SAI1_CLK_SEL_MASK))
		   | CCM_CSCMR1_SAI1_CLK_SEL(2); // &0x03 // (0,1,2): PLL3PFD0, PLL5, PLL4

n1 = n1 / 2; // speed up x2

	CCM_CS1CDR = (CCM_CS1CDR & ~(CCM_CS1CDR_SAI1_CLK_PRED_MASK | CCM_CS1CDR_SAI1_CLK_PODF_MASK))
		   | CCM_CS1CDR_SAI1_CLK_PRED(n1-1) // &0x07
		   | CCM_CS1CDR_SAI1_CLK_PODF(n2-1); // &0x3f

	IOMUXC_GPR_GPR1 = (IOMUXC_GPR_GPR1 & ~(IOMUXC_GPR_GPR1_SAI1_MCLK1_SEL_MASK))
			| (IOMUXC_GPR_GPR1_SAI1_MCLK_DIR | IOMUXC_GPR_GPR1_SAI1_MCLK1_SEL(0));	//Select MCLK

	int rsync = 0;
	int tsync = 1;
	// configure transmitter
	I2S1_TMR = 0;
	I2S1_TCR1 = I2S_TCR1_RFW(0);  // watermark
	I2S1_TCR2 = I2S_TCR2_SYNC(tsync) | I2S_TCR2_MSEL(1) | I2S_TCR2_BCD | I2S_TCR2_DIV(0);
	I2S1_TCR3 = I2S_TCR3_TCE;

	I2S1_TCR4 = I2S_TCR4_FRSZ(7) | I2S_TCR4_SYWD(0) | I2S_TCR4_MF | I2S_TCR4_FSP | I2S_TCR4_FSD;
	I2S1_TCR5 = I2S_TCR5_WNW(31) | I2S_TCR5_W0W(31) | I2S_TCR5_FBT(31);

	//I2S1_RCSR = 0;
	I2S1_RMR = 0;
	//I2S1_RCSR = (1<<25); //Reset
	I2S1_RCR1 = I2S_RCR1_RFW(0);
	I2S1_RCR2 = I2S_RCR2_SYNC(rsync) | I2S_TCR2_MSEL(1) | I2S_TCR2_BCD | I2S_TCR2_DIV(0);
	I2S1_RCR3 = I2S_RCR3_RCE;
	I2S1_RCR4 = I2S_TCR4_FRSZ(7) | I2S_TCR4_SYWD(0) | I2S_TCR4_MF | I2S_TCR4_FSP | I2S_TCR4_FSD;
	I2S1_RCR5 = I2S_TCR5_WNW(31) | I2S_TCR5_W0W(31) | I2S_TCR5_FBT(31);

#if 0
	//debug only:
	CORE_PIN23_CONFIG = 3;  //1:MCLK	11.43MHz
	CORE_PIN21_CONFIG = 3;  //1:RX_BCLK	5.6 MHz
	CORE_PIN20_CONFIG = 3;  //1:RX_SYNC	44.1 KHz
//	CORE_PIN6_CONFIG  = 3;  //1:TX_DATA0
//	CORE_PIN7_CONFIG  = 3;  //1:RX_DATA0
#endif

}
The problem is, I don't have access to my scope, because of the general curfew.
 
Last edited:
Yup, I'm sure the pins were not easy to find in post#35 ;)



Maybe try to add CORE_PIN7_CONFIG = 3; somewhere.
Looks like the comment re: core_pin_7 config in the code fragment above is not 100% OK
 
Is this code fragment correct by means of selecting the right clock speed, which is twice the SPDIF speed, and frame length, wich is 256 instead of 128 bit.
Is this piece of code correct?

You are the big master of the SPDIF code, on which the code of ADAT is based on, so you should know.

The NRZI frames etc, I've just checked, they are ok, but do not appear on the Pin 7.

As written, without my scope, which I don't have in the house at the moment, and is out of reach for the coming months due to corona restrictions, I can not extensively check the signal on the Pin 7, frequency or the clock itself or packet geometry. I can just see on the Alesis if there is a carrier if it is within limits, but for now it is not, so that may be the first to check.
To exclude the TOTX, I've also substituted a AlGaAs LED connected directly via 330 Ohm. It works for S/PDIF and the LED has plenty of bandwith and power headroom.

And yes, the CORE_PIN7_CONFIG = 3; is set in AudioOutputADAT::begin(void), so like in the SPDIF code.

ED: All righty. Will make other thread once progress happens.
 
Last edited:
...please open an other thread for this.
You need to use DMAMEM and add some cache handling like in the SPDIF Code!

Edit: Choosing
n1 = n1 / 2; // speed up x2
means that the input for podf is slightly out of spec - it should be max 300MHz according to datasheet - it is 338MHz with n1/2. But my scope shows that it is OK (measured on enabled MCLK pin 23 -> 22.579 MHz)

The way you did it is good, because it does not change the PLL frequency which is used by other devices (i2s#2, spdif, etc), too
 
Last edited:
Status
Not open for further replies.
Back
Top