Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 26 to 50 of 83

Thread: Teensyduino 1.52 Beta #1

  1. #26
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87

    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

  2. #27
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    Quote Originally Posted by radias View Post

    Audio Library:

    PWM Audio not working.
    Yup, that was expected.


    Quote Originally Posted by radias View Post
    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?

    Quote Originally Posted by radias View Post
    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?

  3. #28
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    Quote Originally Posted by Frank B View Post
    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.

    Quote Originally Posted by Frank B View Post
    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 by radias; 03-21-2020 at 05:57 PM.

  4. #29
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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 by Frank B; 03-21-2020 at 07:04 PM.

  5. #30
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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.

  6. #31
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    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...

  7. #32
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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.

  8. #33
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    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.

  9. #34
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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)

  10. #35
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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?

    Click image for larger version. 

Name:	Image1.png 
Views:	22 
Size:	144.8 KB 
ID:	19438
    Attached Files Attached Files

  11. #36
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    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.

  12. #37
    Junior Member
    Join Date
    Jan 2020
    Posts
    5
    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

  13. #38
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    Quote Originally Posted by radias View Post
    Right?
    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.

  14. #39
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    Quote Originally Posted by PE4WJ View Post
    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

  15. #40
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    Quote Originally Posted by Frank B View Post
    yes. all
    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.

  16. #41
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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.

  17. #42
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    As I do not understand anything, I seriously doubt that I am able to make ADAT work.

    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.

  18. #43
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    Agreed, the documentation is a known issue.

  19. #44
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    @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.

  20. #45
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    Last edited by Frank B; 03-23-2020 at 12:32 AM. Reason: added preview

  21. #46
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    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 by radias; 03-22-2020 at 02:43 PM.

  22. #47
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    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

  23. #48
    Member
    Join Date
    Sep 2017
    Location
    Italia
    Posts
    87
    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 by radias; 03-22-2020 at 11:56 PM. Reason: All righty. Will make other thread once progress happens.

  24. #49
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    yes that looks correct.

  25. #50
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany NRW
    Posts
    7,021
    ...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 by Frank B; 03-22-2020 at 11:52 PM. Reason: added measured freq

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •