Shematic for Teensy 4.1 compatible Pt8211-Kit?

Not testing with a scope - using a simple a speaker attached to the PT8211 board per the picture. When it doesn't work I get NO sound what so ever.

Right, my results exactly. When it works it works both ways, when it don't there's nothing from either.

I've got this working. Now my weekend plans are to introduce that mess of code from rev 0, page by page or line by line, until it either works again or ti doesn't. It seems to me if this works then I'm on my way (I am :)
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveform       waveform1;      //xy=2142,231
AudioSynthWaveform       waveform2;      //xy=2147,284
AudioOutputPT8211_2      pt8211_2;       //xy=2336,249
AudioOutputUSB           usb1;           //xy=2462,371
AudioConnection          patchCord1(waveform1, 0, pt8211_2, 0);
AudioConnection          patchCord2(waveform1, 0, usb1, 0);
AudioConnection          patchCord3(waveform2, 0, pt8211_2, 1);
AudioConnection          patchCord4(waveform2, 0, usb1, 1);
// GUItool: end automatically generated code


void setup() {
  // put your setup code here, to run once:
  AudioMemory(20);
  waveform1.begin(.5,1000,WAVEFORM_SINE); 
  waveform2.begin(.5,501,WAVEFORM_SINE); 
  waveform2.phase(90);
}

void loop() {
  // put your main code here, to run repeatedly:

}
 
Theres seems to be some thing else going on as well since specifing I2S1 and PT8211_2_1 is causing the some type of issue now. Think @PaulStoffregen needs to take a look cause now I am confused.

Yeah, this does indeed seem to be a rather elusive problem. I really do appreciate your effort.
 
Cool. Glad to see that the sketch was helpful.
Soo... you added the AudioOutputUSB object to push audio through USB, as well as I2S?
the T4 never ceases to amaze me.
You're where I was ~ a week ago with recovering from this. that's how I learned the hard way to make lots of backups all along the dev route. I ended up copying chunks of code from the broken sketch into the pristine sketch, until it broke. That identifies the culprit.

Looks like you're back on the road to success.
BR
:cool:
 
Yeah, this does indeed seem to be a rather elusive problem. I really do appreciate your effort.

Doing some more testing this morning with the sketch from post #85
Base Case:
Code:
Raw_Hid               OK
Dual_Serial           OK
Serial+MIDIx16        Fail
Serial+MIDIx16+Audio  OK
Audio                 Fail

Case 1:
Now if I change AudioOutputI2S to AudioOutputPT8211 and initialize AudioOutputPT8211_2 before AudioOutputPT8211_2:
Code:
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
AudioOutputPT8211       i2s1;      //xy=1709,230

Raw_Hid               OK
Dual_Serial           OK
Serial+MIDIx16        OK
Serial+MIDIx16+Audio  OK
Audio                 OK

Case 2:
If I now test with
Code:
AudioOutputPT8211       i2s1;      //xy=1709,230
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
Audio and Serial+Midix16 fails like in the base case.

Case 3:
Code:
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
AudioOutputI2S       i2s1;      //xy=1709,230
Audio now is ok but Serial+MIDIx16 Fails


CASE 4:
Now if I run the code from Post #101 which uses 2 waveforms
Code:
AudioOutputPT8211_2      pt8211_2;       //xy=2336,249
AudioOutputI2S           usb1;           //xy=2462,371
Code:
Serial+MIDIx16+Audio  OK
Audio                 OK
works even if I reverse the order of initialization.

Hope this helps with debugging Paul.
 
Code:
invalid conversion from 'volatile audio_block_t* {aka volatile audio_block_struct*}' to 'audio_block_t* {aka audio_block_struct*}' [-fpermissive]
  old_block = block ;
Sure smells like a mem allocation error to me.
"When it doesn't work I get NO sound what so ever."
I get burn marks on my walls lol.

I don't think it is an issue, but I do have edit changes on my machine just in case.

Simply the PWM class has block marked as volatile. And the release method or temporary holding to call release does not...
So I simply cast it to non-volatile and removed the warning...

Issued PR: https://github.com/PaulStoffregen/Audio/pull/436
 
Last edited:
Sorry I am confused on which things are failing. If I use the one from #85 Which I believe is:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveform       waveform1;      //xy=341.98877334594727,37.01164245605469
AudioSynthWaveform       waveform2;      //xy=346.98876953125,90.01163482666016
AudioOutputPT8211_2      pt8211_2;       //xy=535.98876953125,55.01163864135742
AudioConnection          patchCord1(waveform1, 0, pt8211_2, 0);
AudioConnection          patchCord2(waveform2, 0, pt8211_2, 1);
// GUItool: end automatically generated code


void setup() {
  // put your setup code here, to run once:
  AudioMemory(20);
  waveform1.begin(.5,1000,WAVEFORM_SINE); 
  waveform2.begin(.5,501,WAVEFORM_SINE); 
  waveform2.phase(90);
}

void loop() {
  // put your main code here, to run repeatedly:

}
So far retesting:
Doing some more testing this morning with the sketch from post #85
Base Case:
Code:

Raw_Hid OK
Dual_Serial OK
Serial+MIDIx16 Fail
Serial+MIDIx16+Audio OK
Audio Fail
Serial+MidIx16 appears to work for me.
Likewise Audio.
Case 1:
Now if I change AudioOutputI2S to AudioOutputPT8211 and initialize AudioOutputPT8211_2 before AudioOutputPT8211_2:

I dont see AudioOutputI2S... So guessing different starting point?
 
@KurtE
Should have posted the code. First - should have been post #93 not #85:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveform       waveform1;      //xy=1341,274
AudioOutputI2S       i2s1;      //xy=1709,230     ////// [COLOR="#FF0000"]NOTE removed this for base case[/COLOR]
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
AudioConnection          patchCord3(waveform1, 0, i2s1, 0);
AudioConnection          patchCord4(waveform1, 0, i2s1, 1);
AudioConnection          patchCord5(waveform1, 0, pt8211_2_1, 0);
AudioConnection          patchCord6(waveform1, 0, pt8211_2_1, 1);
// GUItool: end automatically generated code


void setup() {
  AudioMemory(15);
  waveform1.begin(WAVEFORM_SINE);
  waveform1.frequency(440);
  waveform1.amplitude(0.99);
}

void loop() {
}
Used this for the base case, case 1, case 2 and case 3.

For case 4 switched to:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveform       waveform1;      //xy=2142,231
AudioSynthWaveform       waveform2;      //xy=2147,284
AudioOutputPT8211_2      pt8211_2;       //xy=2336,249
AudioOutputUSB           usb1;           //xy=2462,371
AudioConnection          patchCord1(waveform1, 0, pt8211_2, 0);
AudioConnection          patchCord2(waveform1, 0, usb1, 0);
AudioConnection          patchCord3(waveform2, 0, pt8211_2, 1);
AudioConnection          patchCord4(waveform2, 0, usb1, 1);
// GUItool: end automatically generated code


void setup() {
  // put your setup code here, to run once:
  AudioMemory(20);
  waveform1.begin(.5,1000,WAVEFORM_SINE); 
  waveform2.begin(.5,501,WAVEFORM_SINE); 
  waveform2.phase(90);
}

void loop() {
  // put your main code here, to run repeatedly:

}
 
Thanks @mjs513...

Right now having failure with plain USB type Serial with:
Code:
#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveform       waveform1;      //xy=1341,274
AudioOutputI2S       i2s1;      //xy=1709,230
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
AudioConnection          patchCord3(waveform1, 0, i2s1, 0);
AudioConnection          patchCord4(waveform1, 0, i2s1, 1);
AudioConnection          patchCord5(waveform1, 0, pt8211_2_1, 0);
AudioConnection          patchCord6(waveform1, 0, pt8211_2_1, 1);
// GUItool: end automatically generated code

void setup() {
  pinMode(13, OUTPUT);
  AudioMemory(30);
  waveform1.begin(WAVEFORM_SINE);
  waveform1.frequency(440);
  waveform1.amplitude(0.99);
  while (!Serial && millis() < 4000) ;
  for (uint8_t pin = 2; pin < 5; pin++)
    Serial.printf("%u CTRL:%u CFG:%u\n", pin, *(portControlRegister(pin)), *(portConfigRegister(pin)));

}

void loop() {
  digitalToggleFast(13);
  delay(250);
}

It is blinking so I know it did not hang:
Code:
2 CTRL:4272 CFG:2
3 CTRL:4272 CFG:2
4 CTRL:4272 CFG:2
Debug output shows the pins are in Mode 2
Code:
 2	EMC_04	SEMC_DATA04	FLEXPWM4_PWMA02	SAI2_TX_DATA	XBAR1_INOUT06	FLEXIO1_FLEXIO04	GPIO4_IO04				
 3	EMC_05	SEMC_DATA05	FLEXPWM4_PWMB0	SAI2_TX_SYNC	XBAR1_INOUT07	FLEXIO1_FLEXIO05	GPIO4_IO05				
 4	EMC_06	SEMC_DATA06	FLEXPWM2_PWMA00	SAI2_TX_BCLK	XBAR1_INOUT08	FLEXIO1_FLEXIO06	GPIO4_IO06
Which is SAI2... which looks correct.

May try to turn on debug CORE and see if anything pops up...
 
I should mention that if I change around the order of the two lines:
Code:
AudioOutputI2S       i2s1;      //xy=1709,230
AudioOutputPT8211_2      pt8211_2_1;     //xy=1726,313
It works...

So I am curious about what might be different in these two cases. I am curious and will maybe check things like:
I believe they both call set_audioClock during the processing of their constructor.
And I see things like:
Code:
FLASHMEM
void set_audioClock(int nfact, int32_t nmult, uint32_t ndiv, bool force) // sets PLL4
{
	if (!force && (CCM_ANALOG_PLL_AUDIO & CCM_ANALOG_PLL_AUDIO_ENABLE)) return;
So then question is, are they calling with same values or not? Or first one wins? And if different,
And the PT8211 loses, will it work?

I will take a look in awhile (unless someone beats me to it), but now out to do some work on the yard.
 
Output more debug info end of setup:
Not working:
Code:
2 CTRL:4272 CFG:2
3 CTRL:4272 CFG:2
4 CTRL:4272 CFG:2
CCM_ANALOG_PLL_AUDIO: 8010201c
CCM_ANALOG_PLL_AUDIO_NUM: 8c0
CCM_ANALOG_PLL_AUDIO_DENOM: 2710
CCM_ANALOG_MISC2: 2f272f
CCM_CSCMR1 66132840
CCM_CS2CDR 736ce
IOMUXC_GPR_GPR1 80180018
I2S2_TMR 0
I2S2_TCR1 0
I2S2_TCR2 7000000
I2S2_TCR3 10000
I2S2_TCR4 10f13
I2S2_TCR5 f0f0f00
[B]I2S2_TCSR 90140001[/B]

Swapped order and working:
Code:
2 CTRL:4272 CFG:2
3 CTRL:4272 CFG:2
4 CTRL:4272 CFG:2
CCM_ANALOG_PLL_AUDIO: 8010201c
CCM_ANALOG_PLL_AUDIO_NUM: 8c0
CCM_ANALOG_PLL_AUDIO_DENOM: 2710
CCM_ANALOG_MISC2: 2f272f
CCM_CSCMR1 66132840
CCM_CS2CDR 736ce
IOMUXC_GPR_GPR1 80180018
I2S2_TMR 0
I2S2_TCR1 0
I2S2_TCR2 7000000
I2S2_TCR3 10000
I2S2_TCR4 10f13
I2S2_TCR5 f0f0f00
[B]I2S2_TCSR 90100001[/B]
Looks the same so probably not it...

Edit printed out more data:
The only difference I see is:
the transmit control register... Not sure if that means anything

I believe it is the FEF(FIFO Error Flag)
 
Last edited:
OK, so here's a thing - these are the last few lines of AudioOutputPT8211_2::begin():
Code:
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI2_TX);

	I2S2_TCSR |= I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;

	update_responsibility = update_setup();
	dma.attachInterrupt(isr);
	dma.enable();
Note that the transmit is enabled before the DMA interrupt is attached; so if the code is running from slow Flash, is there a chance the interrupt will trigger before the ISR can be attached, so it's lost and is never seen again?

I've tried using this order and things appear to be better:
Code:
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI2_TX);
	update_responsibility = update_setup();
	dma.attachInterrupt(isr);
	dma.enable();

	I2S2_TCSR |= I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;
I've not 100% convinced myself because every fix I've done before this has stayed fixed, even when I removed it!

Agree with @KurtE that the FIFO error flag is significant - it seems to be set every time it stops working. Oh, and the ISR isn't firing when it's not working, too.
 
OK, so here's a thing - these are the last few lines of AudioOutputPT8211_2::begin():

Note that the transmit is enabled before the DMA interrupt is attached; so if the code is running from slow Flash, is there a chance the interrupt will trigger before the ISR can be attached, so it's lost and is never seen again?

I've tried using this order and things appear to be better:
I've not 100% convinced myself because every fix I've done before this has stayed fixed, even when I removed it!

Agree with @KurtE that the FIFO error flag is significant - it seems to be set every time it stops working. Oh, and the ISR isn't firing when it's not working, too.

Not sure, but I made the change you mentioned and the version that was NOT working is now working.

It could easily be that not running from FLASHMEM slowed the code down enough that the window of time between a few of these statements was sufficient enough that in some cases the interrupt happens before we are setup and the DMA fails to run...

Now an interesting thing is that this same code fragment is replicated in several of the other output classes, like the output_i2s.cpp output_i2s2.cpp ...

So if this appears to fix this here, we maybe should do it in all of these classes and see if it resolves some of the other combinations of USB type and the like that were failing.
 
Not sure, but I made the change you mentioned and the version that was NOT working is now working.
Great!

It could easily be that not running from FLASHMEM slowed the code down enough that the window of time between a few of these statements was sufficient enough that in some cases the interrupt happens before we are setup and the DMA fails to run...
I assume you meant "running from FLASHMEM slowed the code down" (which it does, as Flash is slower than ITCM).

Now an interesting thing is that this same code fragment is replicated in several of the other output classes, like the output_i2s.cpp output_i2s2.cpp ...

So if this appears to fix this here, we maybe should do it in all of these classes and see if it resolves some of the other combinations of USB type and the like that were failing.
Yup, I spotted that too*. Agree it should be changed throughout, if others' experience is that the change I found works well for them.

EDIT: *but I also noticed that the ::begin() functions are often not marked FLASHMEM, so the problem might have been masked by the fast execution…
 
Last edited:
@Paul and all I updated my PR to remove the compiler warnings to slight rearrange of the constructor like mentioned above For the two PT8211 classes.

I think the main thing was the dma.enable() needed to be done before we set the TE bit that can start things up.

I ran the test that @mjs513 did in #93 I think it is and the ones that were failing before (dual serial, rawhid, Serial+Midi16+Audio) and they all appear to work.

Also sort of makes sense as it felt like there was a timing window where things could go wrong and this hopefully removes it.

You might try pulling in:
https://github.com/PaulStoffregen/Audio/pull/436

And see if it works for you.

Note: someone should probably go through all of the constructors to see if other classes have same issue.
 
You might try pulling in:
https://github.com/PaulStoffregen/Audio/pull/436

And see if it works for you.
Looks like Paul has already merged that! I’m a bit concerned that the update_responsibility() line is now out of its previous order…
Note: someone should probably go through all of the constructors to see if other classes have same issue.
I can take that on, once the PT8211_2 case has been ratified by @TheHermit and @boxxofrobots.

Do we (and especially @PaulStoeffregen) have a view on adding FLASHMEM to all the ::begin() and ::config_*() code? They shouldn’t need fast execution and some applications might be helped by freeing up some ITCM.
 
@KurtE
Just did a quick test of some of the USB Types I was having issues with your latest set of changes and your sketch in post #108 and they all seem to working for me now.

Note: someone should probably go through all of the constructors to see if other classes have same issue.
It looks like all the output_i2s types should be checked from output_i2s_hex:

Code:
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI1_TX);
	dma.enable();
	I2S1_RCSR |= I2S_RCSR_RE | I2S_RCSR_BCE;
	I2S1_TCSR = I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;
	I2S1_TCR3 = I2S_TCR3_TCE_3CH << pinoffset;
	update_responsibility = update_setup();
	dma.attachInterrupt(isr);
assuming this should be:
Code:
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI1_TX);
	dma.attachInterrupt(isr);
	dma.enable();
	I2S1_RCSR |= I2S_RCSR_RE | I2S_RCSR_BCE;
	I2S1_TCSR = I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;
	I2S1_TCR3 = I2S_TCR3_TCE_3CH << pinoffset;
	update_responsibility = update_setup();
 
Been doing more investigation, and I think one key point is that (as @KurtE said in #114) dma.enable() must occur before the I2S hardware is enabled, otherwise the I2S will fire a request to a non-enabled DMA channel. Typically it looks like the DMA is preset with about 1.5ms worth of silence, so unless something really gross occurs the vector would be set before the ISR was needed; but it's not worth risking...

Also, I think update_setup() should be called before enabling I2S, and possibly even before attaching the DMA interrupt. It sets the Audio interrupt vector and enables it, and returns TRUE if the object has acquired update responsibility. The audio interrupt is fired from code within the ISR of the hardware with update responsibility, so it had better be set up before the hardware's DMA service ISR!

So the "best" sequence is probably :
Code:
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI1_TX); // hardware dependent

	// hardware independent:
	update_responsibility = update_setup();
	dma.attachInterrupt(isr);
	dma.enable();

	// hardware dependent:
	I2S1_RCSR |= I2S_RCSR_RE | I2S_RCSR_BCE;
	I2S1_TCSR = I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;
	I2S1_TCR3 = I2S_TCR3_TCE_3CH << pinoffset;
i did have a bit of luck with otherwise poorly-ordered code, by pre-filling the FIFO , but it's only 32 samples long so only gives 0.73ms margin, and is extra code when re-ordering the required code is (I hope) guaranteed robust.
 
@KurtE
Just did a quick test of some of the USB Types I was having issues with your latest set of changes and your sketch in post #108 and they all seem to working for me now.
Excellent - thanks.

It looks like all the output_i2s types should be checked from output_i2s_hex:
And input_i2s, too. From input_i2s.cpp:
Code:
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI1_RX);

	I2S1_RCSR = I2S_RCSR_RE | I2S_RCSR_BCE | I2S_RCSR_FRDE | I2S_RCSR_FR;
#endif
	update_responsibility = update_setup();
	dma.enable();
	dma.attachInterrupt(isr);
}
Frankly ... ouch. In hindsight...

EDIT: just scanned all .cpp files in the Audio library which use update_setup(). At first glance I can't see a single one with these statements in the correct order.
 
As you mentioned, I did not see any consistency in the order of some of those calls. I was pretty sure from what we were seeing, was we needed to make sure that the DMA was enabled before we allow the transfer. And should probably have the ISR set before that as well, although you would then need to transfer I think half the buffer before the first dma interrupt...
And as you mentioned probably should have the responsibility set before we enable the transfers.

But the exact order may not matter except should have the DMA setup before we enable the transfer.

I was trying to get it working quick as I knew that Paul was trying to get the next beta build out.
Which I think may now be out :D
 
Code:
[COLOR=#333333]I can take that on, once the PT8211_2 case has been ratified by @TheHermit and @boxxofrobots.[/COLOR]

Okay. I can do whatever tests you guys need by using the miniPC and an oscilloscope, instead of the Surface pro and laser projectors. IOW, there's no risk of damaging my project. Since I've already fried several Teensys along the way, I have extras. As a reminder, I have quad SGTL5000 + PT8211 (pins 2, 3, & 4)
Been following this thread and sincerely appreciate everyone's efforts and want to help. But, I'm only understanding about 1/2 the chatter and since my system is working on ver 1.56, plus boxxofrobots' is as well, I don't understand what you're trying to solve. Nevertheless, consider me as putty in your hands, if you are willing to Keep It Simple (for the) Simpleton.
I'm running Windows on the miniPC w/version 1.56, as well. Would you like me to start with a fresh Arduino installation, then just add the following pull that KurtE mentioned?
https://github.com/PaulStoffregen/Audio/pull/436

Which sketch would you prefer me to test 1st? Please provide detailed instructions regarding the testing procedure(s) and how to produce the results you need.
 
Thanks @TheHermit! And yes, please don't risk any of your hardware...

For the moment I'd say we'd like confirmation that your previous tests and use-cases are more robust / completely fixed. You did a great table in post #64, so maybe the best procedure is:
  • start with Arduino + 1.56; can be fresh, probably better so
  • do a few of your post #64 tests, enough to show the problem still exists
  • pull in either @KurtE's PR, or Teensyduino 1.57b2, which includes the PR
  • redo your post #64 tests, ideally all but at least enough to be confident the problem is gone
The purist in me is not entirely happy with the ordering of these lines in libraries/Audio/output_pt8211_2.cpp (starts about line 73):
Code:
	dma.TCD->DADDR = (void *)((uint32_t)&I2S1_TDR0);
	dma.attachInterrupt(isr);
	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI1_TX);
	dma.enable();

	I2S1_RCSR |= I2S_RCSR_RE;
	I2S1_TCSR |= I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;

	update_responsibility = update_setup();
I'd much prefer:
Code:
	dma.TCD->DADDR = (void *)((uint32_t)&I2S1_TDR0);

	dma.triggerAtHardwareEvent(DMAMUX_SOURCE_SAI1_TX);

	update_responsibility = update_setup();
	dma.attachInterrupt(isr);
	dma.enable();

	I2S1_RCSR |= I2S_RCSR_RE;
	I2S1_TCSR |= I2S_TCSR_TE | I2S_TCSR_BCE | I2S_TCSR_FRDE;
Plus the previous speculative change of commenting out FLASHMEM at line 388 is still in place, so the issue may be fixed one and a half times; re-instating the FLASHMEM would be a better test of the above code.

Soooo ... if you felt really diligent, you could dive in and re-order the lines and put the FLASHMEM back and test the result ... but I think that's probably going a bit too far right now.
 
start with Arduino + 1.56; can be fresh, probably better so
do a few of your post #64 tests, enough to show the problem still exists
pull in either @KurtE's PR, or Teensyduino 1.57b2, which includes the PR
redo your post #64 tests, ideally all but at least enough to be confident the problem is gone

On it.
Plus the previous speculative change of commenting out FLASHMEM at line 388 is still in place, so the issue may be fixed one and a half times; re-instating the FLASHMEM would be a better test of the above code.
Soooo ... if you felt really diligent, you could dive in and re-order the lines and put the FLASHMEM back and test the result ... but I think that's probably going a bit too far right now.

Didn't Paul already commit that change to 1.57b2? IOW, won't it already be in place when I upgrade? Does that commit include the entire Teensyduino installation package or only the mods? Also, isn't there still the question regarding whether that same edit should be applied to the rest of the I2S files? Okay, I'm already getting ahead of myself.
Thanks for your guidance.
Stand back, folks. Here comes a cannonball in the deep end, well over my head. ;-)
 
On it.


Didn't Paul already commit that change to 1.57b2? IOW, won't it already be in place when I upgrade? Does that commit include the entire Teensyduino installation package or only the mods? Also, isn't there still the question regarding whether that same edit should be applied to the rest of the I2S files? Okay, I'm already getting ahead of myself.
Thanks for your guidance.
Stand back, folks. Here comes a cannonball in the deep end, well over my head. ;-)
SSSSSPPLOOOOSH!

Yup, Paul has put @KurtE's mods into 1.57b2, so you have the choice of just the audio PR or the whole shebang. Up to you...
 
SSSSSPPLOOOOSH!

Yup, Paul has put @KurtE's mods into 1.57b2, so you have the choice of just the audio PR or the whole shebang. Up to you...

Here's what I have so far, using the same code from before, with the same equipment and Arduino install running ver 1.56, apples to apples, except I've since removed the Audio Master from github, because it wasn't being used.

Code:
USB Type                                1.55    1.56   Hermit's 1.56  w/quad SGTL5000 + PT8211 
                                                       msg #64  Test #2 (apples to apples H/W & S/W)    
--------                                ----    ----    ------  -------
Serial                                  Fail    OK      OK       Fail
MIDI                                    Fail    Fail    Fail     OK
MIDI x4                                 Fail    Fail    Fail     OK
MIDI x16                                Fail    Fail    Fail     OK
Serial + MIDI                           OK      Fail    OK       OK
Serial + MIDI x4                        OK      Fail    OK       OK (norm config)
Serial + MIDI x16                       OK      Fail    OK       OK
Audio                                   Fail    OK      OK       OK
Serial + MIDI + Audio                   OK      Fail    OK       OK
Serial + MIDI x16 + Audio               OK      Fail    OK       OK




AudioConnection          patchCord14(X_MIX, 0, I2S_QUAD_DAC, 0);
AudioConnection          patchCord11(R_DC, 0, I2S_QUAD_DAC, 1);
AudioConnection          patchCord12(G_DC, 0, I2S_QUAD_DAC, 2);
AudioConnection          patchCord13(B_DC, 0, I2S_QUAD_DAC, 3);




                           I2S_QUAD_DAC Ports     Hermit's
USB Type                   3     2     1     0     1.56       Test #2
--------                  ----  ----  ----  ----   ----      --------     
Serial + MIDI x4            x    x     x    x       Fail      Fail 
Serial + MIDI x4            x    x     x    C       OK        Fail
Serial + MIDI x4            x    x     C    x       OK        Fail
Serial + MIDI x4            x    x     C    C       Fail      Fail
Serial + MIDI x4            x    C     x    x       OK        Fail
Serial + MIDI x4            x    C     x    C       Fail      Fail
Serial + MIDI x4            x    C     C    x       Fail      Fail
Serial + MIDI x4            x    C     C    C       Fail      OK
Serial + MIDI x4            C    x     x    x       OK        Fail
Serial + MIDI x4            C    x     x    C       Fail      Fail
Serial + MIDI x4            C    x     C    x       Fail      Fail
Serial + MIDI x4            C    x     C    C       OK        Fail
Serial + MIDI x4            C    C     x    x       Fail      Fail
Serial + MIDI x4            C    C     x    C       OK        OK
Serial + MIDI x4            C    C     C    x       OK        OK  
Serial + MIDI x4            C    C     C    C       OK        OK


Bonus test
w/o I2S_QUAD_DAC defined   N/A   N/A   N/A  N/A               OK
as AudioOutputI2SQuad

Arduino is set to not check for updates, so I don't understand the different test results. Looks like the kremlin is getting more particular with his patchchord connections. My lesson learned from this is to simply not use I2S objects with AudioOutputPT8211_2.
I'll move over to the miniPC, reinstall Arduino & ver 1.57b2 and run the same test on a scope.
Aa'll be bock!
:cool:
 

Attachments

  • PT8211_PJRCtest_msg62.ino
    6.5 KB · Views: 18
...and. I've had a crack at re-ordering the ::begin() code for most of the Audio I/O objects, the result of which can be found at https://github.com/h4yn0nnym0u5e/Audio/tree/fix/io-inits. I've done a bit of testing and I'm fairly confident that the I2S output objects are OK, along with the PT8211_2, PWM, MQS outputs, and ADC and I2S inputs. There's lots I haven't tested, and don't have the kit to do, including TDM, PDM and ADAT; and the quad, hex and oct I2S haven't had a proper test. So if anyone feels like having a crack at those, it would be most helpful.

The one object I couldn't figure out is the PWM out, so that's unchanged. I think at least some of that is @MarkT's baby, so if you're out there a bit of wisdom would be most appreciated!
 
Back
Top