Dual channel 16bit dac PT8211

Frank, I took your comments about optimization as another learning opportunity and combined the two loops to one. That brought ISR execution time down from 113µs to 96µs. I then researched a bit about how to set compiler optimization options for single functions and used the "unroll-loops" option on the ISR. That brought the run time down to only 65µs and increased my test code size from 26356 to 26732 bytes. A good trade IMHO.

https://github.com/Ben-Rheinland/Audio/commit/cf013ec88efb83517e811df540bfa3027ba8c28d

I'm reluctant to issue a pull request as using these compiler options is a first for me...

-Ben
 
Frank, I took your comments about optimization as another learning opportunity and combined the two loops to one. That brought ISR execution time down from 113µs to 96µs. I then researched a bit about how to set compiler optimization options for single functions and used the "unroll-loops" option on the ISR. That brought the run time down to only 65µs and increased my test code size from 26356 to 26732 bytes. A good trade IMHO.

https://github.com/Ben-Rheinland/Audio/commit/cf013ec88efb83517e811df540bfa3027ba8c28d

I'm reluctant to issue a pull request as using these compiler options is a first for me...

-Ben

That looks good.
For the used compiler-option, i don't see a reason not to use it - there's one in the early startup-code, too.
 
Related question: with the compiler optimization in place, there shouldn't be any performance penalties if I reintroduce the loops, right?
 
Oh ok, I thought there were 32b DSP instructions available. Paul mentioned he is interested in interpolation/oversampling as well

Supposedly the crypto accelerator in the K66 chip can be used to rapidly compute 2nd or 3rd order polynomial interpolation. So tempting to play with things like that... but then I'd never get all the more urgent work done!
 
While I learned a lot and had some fun playing with CIC filters, I think it's ultimately not the best tool for 4x OS. CICs shine with very large OS factors where you can split up the OS into multiple stages, e.g. 120x OS split up in a 4x FIR stage and a 30x CIC stage.

IMHO a FIR or polynomial interpolator would be a better choice, both because these solutions can use DSP instructions on the Teensy and because it's the "more correct" way to do 4x OS.

I'm currently reading through this: http://www.rle.mit.edu/dspg/documents/main.pdf but I haven't actually tried anything yet.
-Ben
 
While I learned a lot and had some fun playing with CIC filters, I think it's ultimately not the best tool for 4x OS. CICs shine with very large OS factors where you can split up the OS into multiple stages, e.g. 120x OS split up in a 4x FIR stage and a 30x CIC stage.

IMHO a FIR or polynomial interpolator would be a better choice, both because these solutions can use DSP instructions on the Teensy and because it's the "more correct" way to do 4x OS.

I'm currently reading through this: http://www.rle.mit.edu/dspg/documents/main.pdf but I haven't actually tried anything yet.
-Ben

Would 8x be better? We could try if the hw can do it..
 
The more OS, the less analog filtering (fewer order) you need to achieve the desired stop band attenuation, but also the more computational cost... I wouldn't recommend trying this with the PT8211, maybe the internal DAC of the K20 is a better candidate for this? The datasheet states 550kHz bandwith (https://www.pjrc.com/teensy/K20P64M72SF1.pdf Page 47), and 8xOS on the teensy is 8*44.117 = 352.936 Hz, that would fit well. The K66 also has 550kHz BW (http://cache.nxp.com/files/32bit/doc/data_sheet/K66P144M180SF5V2.pdf Page 52)... So you could try it in stereo on your K66 beta board (and I could, too, once I receive my Round 3 or 4 board).

It might even be worth considering 16xOS for the internal DAC(s) if the digital update rate can be made so fast. The 550kHz spec seems to be the analog performance, not the maximum input sample frequency.

For external DAC ICs the typical upper spec for sample rate is a little over 200kHz. 192kHz is the highest professionally used sample rate I know of. There are, of course, higher sample rate DACs out there, I mean this in the scope of audio applications.


Edit: I changed the CIC filter to have 2 to 8 stages (set at compile time), I'm testing right now...
 
Last edited:
The variable CIC filter works great, but switching from the manually unrolled loop with code like:
Code:
integrateLOld[0] = integrateL[0];
integrateROld[0] = integrateR[0];
integrateLOld[1] = integrateL[1];
integrateROld[1] = integrateR[1];
integrateLOld[2] = integrateL[2];
integrateROld[2] = integrateR[2];

to this:
Code:
for (int k = 0; k < AUDIO_PT8211_INTERPOLATION_CIC; k++){
	integrateLOld[k] = integrateL[k];
	integrateROld[k] = integrateR[k];
}

introduces massive performance loss. It seems the "unroll-loops" compiler optimization does not work here, maybe the compiler doesn't recognize that the loop can be unrolled at compile time?

I created a branch "variable-CIC" on github for this (I'm slowly getting a grip on this Git thing...), in case anyone wants to have a look or try it out: https://github.com/Ben-Rheinland/Audio/commits/variable-CIC/output_pt8211.h

So far I only edited the (blockL && blockR) case to allow variable filter numbers because I tested stereo performance. The code for mono is still hardcoded to 3 filter stages.


EDIT: I googled arm_fir_fast_q15 to better understand how the audio library FIR filter block works, and I found this: https://www.keil.com/pack/doc/CMSIS/DSP/html/group___f_i_r___interpolate.html. If arm_fir_interpolate_q15 is available on the K20 and/or K66 this would be the way to go I guess. It uses polyphase FIR filters and according to what I learned in the last weeks this is exactly what we need. Sadly this is way over my skills with C++, but I could help with the filter design (coeff's) and testing.
 
Last edited:
Hi Ben (or others)

thank you again for your filter-board+schematic. I've added it to by my own board !
I have two questions:

- Do you have a tool to calculate the values ?
- What are the needed changes to modify the filter to a freq of about ~8000Hz ? (I need it for a emulation-project)
(would be best to change the parts only, because i have the boards already ;-)
View attachment 9832

Btw, the OP-Amp is ok for 8 Ohm headphones. Not too loud, but very OK.
 
Last edited:
Hi Ben (or others)

thank you again for your filter-board+schematic. I've added it to by my own board !
I have two questions:

- Do you have a tool to calculate the values ?
Yes, there's the Filter Design Tool from the university okawa-denshi (Japan) that does an excellent job for analog filters up to 3rd order: http://sim.okawa-denshi.jp/en/Fkeisan.htm
The tool is really all you need for 1st, 2nd and 3rd order filters, as it not only shows you ideal values but also calculates the closest R and C values of an E-series of your choice (e.g. capacitor values from E6 and resistor values from E24).
3rd order active filters can generally be made by two circuit topologies: Sallen-Key and Multiple-Feedback. The PT8211-shield (and presumably your board, too) uses a Sallen-Key topology, so this page is what you're looking for. By the way, you can use the same PCB layout to also create high pass filters instead of low pass, as long as your Rs and Cs have the same package, because they swap places (and change values of course) if you compare high- and low-pass Sallen-Key filters.

- What are the needed changes to modify the filter to a freq of about ~8000Hz ? (I need it for a emulation-project)
(would be best to change the parts only, because i have the boards already ;-)
View attachment 9832
With the okawa tool you can answer that question yourself ;). Let me know if you need help or a second opinion / "proof reading" regarding your solution.

Btw, the OP-Amp is ok for 8 Ohm headphones. Not too loud, but very OK.
That's great to hear, although it's technically out of spec. But hey, if it works, it works. I recall the OP is immune to shorts on the output, so no worries.

Hope this helps!

Regarding the actual topic of this thread: I have a fully assembled PT8211 shield on my desk at work that waits patiently to be tested and characterized, but I haven't found enough spare time so far. So my question is, does it still make sense to test the boards or have you (Frank) already tested the filter on your own board or on the PT8211 shield?

Cheers
Ben
 
Regarding the actual topic of this thread: I have a fully assembled PT8211 shield on my desk at work that waits patiently to be tested and characterized, but I haven't found enough spare time so far. So my question is, does it still make sense to test the boards or have you (Frank) already tested the filter on your own board or on the PT8211 shield?

Hi Ben,
thank you very much.

I have working boards, but i did not measure anything. I do not know enough about filters and analog electronic to do such measurings.
Btw, I've used 2x 47uF 0805 ceramic to buffer the OP-amp's power. I hope this is ok :)
RE: The headphones: The sound is quite OK and nothing gets hot.
 
Last edited:
I found a new chinese chip "TM8211" which seems to be a copy of PT8211. Even the pictures in the dataheet are copied.
I ordered some of them :) I'm curios...
..
 
Did you order on aliexpress? They really seem to be an exact clone.

I may have access to an IC decapsulation machine later this year, might be fun to compare the dice :)

I tried the manufacturers website titanmec.com, but most stuff is in chinese even after I chose english, not helpful for me.
 
Did you order on aliexpress? They really seem to be an exact clone.

I may have access to an IC decapsulation machine later this year, might be fun to compare the dice :)
Yes, I ordered a pack of 10 from alieexpress. I don't want to post a link here, but it's easy to find.
Oh, yes, a comparison would be very interesting !
 
Hey guys. I am trying to output now via TDA1543, it's a 16bit DAC, it's very similar to pt8211 but not the same. Maybe you can guide me how to do it and what i have to modify in the library.

This is the code

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>

// GUItool: begin automatically generated code
AudioSynthWaveform waveform1; //xy=110,75
AudioOutputI2S audioOutput; //xy=303,78
AudioConnection patchCord1(waveform1, 0, audioOutput, 0);
AudioConnection patchCord2(waveform1, 0, audioOutput, 1);
// GUItool: end automatically generated code

void setup() {
AudioMemory(16);
waveform1.begin(WAVEFORM_TRIANGLE);
waveform1.amplitude(0.99);
}

void loop() {
float freq = map(analogRead(A0), 0, 4095, 0.1, 2000);
waveform1.frequency(freq);

}

my output is this on the oscilloscope
out1.jpg
 
The TDA1543 came to market 26 years ago in 1991 and I'm not sure if it's worth the time to adapt the audio library for this museum's piece...

What you'd have to do is taking a logic analyzer and checking the actual I2S output and bring it to match with the TDA1543's I2S specifications as described in the data sheet.
 
vincentiuș;139160 said:
Yes, you are right, but this is what i have now until i receive the PT chips :)

Not easy to help you without having that chip.

At first, i'd try to
1) edit output_pt8211.cpp and the the line (near the end)
I2S0_TCR4 = I2S_TCR4_FRSZ(1) | I2S_TCR4_SYWD(15) | I2S_TCR4_MF /*| I2S_TCR4_FSE*/ | I2S_TCR4_FSP | I2S_TCR4_FSD; //PT8211
to
I2S0_TCR4 = I2S_TCR4_FRSZ(1) | I2S_TCR4_SYWD(15) | I2S_TCR4_MF | I2S_TCR4_FSE | I2S_TCR4_FSP | I2S_TCR4_FSD;
2) edit PT8211.h and disable the the oversampling

does that help ?
 
Back
Top