I2S output with CS4344

B

BenIP

Member
Hello,
I am currently trying to make the I2S audio output of the teensy work with a CS4344


Its data input are:

* SDIN
* SCLK
* LRCK
* MCLK

And while not strictly using the same naming as the teensy, using the datasheet informations I gathered:

* SDIN --> Serial Audio Data Input ie TX (Pin 22)
* LRCK --> Left Right Clock, can be 44.1khz, (Pin 23)
* MCLK --> Master Clock, can be 256x LRCK ie 11.2896MHZ, (Pin 11)
* SCLK --> External Serial Clock Input , can be 32x LRCK, ie 1.41MHZ, is BCLK (Pin 9)

For the rest, I pretty much followed the datasheet implementation.
Screen Shot 2019-02-11 at 10.52.11.png

Still no sound.. Testing with the "Part 1-2: Test Hardware" sketch of the library.

Is there something I am missing?
 
when using audio library the SCLK is 64xLRCLK, but as fas as I can tell from datasheet only bitclocks of 32,48 or 72 FS are supported
But you can modify the sampling rates easily.
 
Thanks for the answer!

Doesn't that contradict the information given on this page?

>BCLK (ie SCLK), 1.41 MHz
>LCRLK High=Left, Low=Right, 44.1 kHz

So a 32x ratio? Or do I read that wrong?
 
BenIP said:
Thanks for the answer!

Doesn't that contradict the information given on this page?

>BCLK (ie SCLK), 1.41 MHz
>LCRLK High=Left, Low=Right, 44.1 kHz

So a 32x ratio? Or do I read that wrong?
Click to expand...
BCLK is the Bitclock -It is x32 because of 32 Bits per word.
Check the data format and polarities too - there isn't "the" I2S. it can differ from chip to chip. The std. output we use for SGTL5000 has I.e. the FSE Bit set - "Framesync early" which means the LRCLK goes high one bit before the start of the frame. PT8211 does not like that, and it is disabled there.Then, there are different bit-polarities which can be set and more ...
 
But Bitclock and Serial Clock are two names for the same data right?
That's what I gathered from wikipedia
>Bit clock line: Officially "continuous serial clock (SCK)". Typically written "bit clock (BCLK)".

My understanding of the protocol is:
* A bitclock lines gives rythm at the bit level
* A Word clock (or left right clock) alternates between left and right select
* A third high frequency clock MCLK syncronizes the internals of the chips

Here all my clocks are at good frequencies, so my trouble might be bit polarities between clocks. Did I get that right?

I did indeed overestimated the plug'n play factor of the I2S. Would have used the SGTL5000 if it had come in a hand-solder friendly package!
 
On the other hand.. you should measure it. We have 2 words - left and right channel - and this gives x64. Can't check this at the moment, I'm not at home.
 
BenIP said:
Thanks for the answer!

Doesn't that contradict the information given on this page?
Click to expand...
The information on this page is outdated; only source code is authorative (not comments in code, but code itself)
The audio library (I2S object) has meanwhile be modified from 32bit/frame to 64bit/frame (frame rate = LR clock = sampling frequency)
and as there have to be 64 bits shifted during each frame the bitclock is 64 times sampling frequency.
 
The information on this page is outdated; only source code is authorative (not comments in code, but code itself)
Click to expand...

Seems like sensible advice! ;)

So now I2S is outputting 32bit/channel audio data at 44.1khz? Thats massive! And that would explain why it would not work for me, since the limit is 24 bit audio data.

And sadly, no oscilloscope, I really should start saving for one..

If I get it correctly, my issue here is that each word is too long (32 bits). But, looking at output_I2S.cpp, I fail to see where this is defined
 
BenIP said:
And that would explain why it would not work for me, since the limit is 24 bit audio data.
Click to expand...

No, that doesn't explain it at all. I2S is designed so the receiver ignores extra bits.

Most likely you've made a mistake in wiring. Maybe it's time to share photos, so we can help you figure out what's wrong.
 
Then it is time to admit something! I have been foolish and directly sent a board to fab without testing the chip first.
Definitely overestimated the plug'n play factor as said before!

You can find the repo here, with source files for the board.

I am afraid I don't have a macro camera that would allow to visually detect issues.

I did test all connections of the chip, and the rest of the circuit works as intended. It gets 3.3v as well.

If there is something wrong it is either:

* In the schematics
* I burned the chip by soldering for too long (It happens, though I was quite carefull)
 
Last edited:
If you give PDF files for the schematic & layout, I'll take a quick look. But I don't use Eagle, so not going to open your Eagle format files.
 
WMXZ said:
The information on this page is outdated
Click to expand...

Wow, turns out there are 8 very old html files still on the server, not linked anywhere from the rest of the site, which pre-date the design tool (somewhere in 2014).

I've updated all 8 of those ancient files, replacing the redundant documentation with links to the design tool documentation (right side panel). Now this page should not cause any more confusion (but may need to click refresh if your browser has cached the old page).
 
I'm confused by the bottom side image.

bottom.png

Is this a transparent view through the top of the board? Or is it actually looking at the bottom side, like holding the real board in your hand?
 
Sorry, yes this is a transparent view of the board, from the top, with top layer deactivated. It wasn't clear!
 
Looking at the Teensy footprint, this sure looks like an actual bottom side view, since VIN is on the left and GND is on the right.

But looking at the CS4344, it sure looks like a transparent view through the top of the board, since the pin 1 dot on the CS4344 appears on the right hand side.
 
Yes, it is because the teensy is soldered on the bottom side. So viewed from the top, we see its belly in transparent view.

bottom.jpg

Here for a real view from the bottom! Teensy is soldered on this side.
 
The data connections look ok.

Maybe try measuring DC voltages at all the CS4334 pins? The 3 clocks should measure ~1.65V, since they're 50% duty cycle. If the CS4334 chip has turned on its analog circuitry, you should see DC voltages on VQ and both AOUT signals.

I used to have some CS4344 chips here, but can't find them now, otherwise I'd do a quick breadboard check.
 
Aha!

As I was testing the voltages, while the prototype was running, I was testing between GND and VCC and suddenly I got sound one one hear!

Plugged it out, then back in, and it was silent once again..

Seems like I inadvertently triggerred something that turned it on.

But at least, nothing is wrong with the library!
 
It's been a looong day. But thanks to you all, it's working!

The issue was that one of the output was bridged to ground under the chip. This seems to have the effect of shutting the IC.

As a conclusion:

* The CS4344 is a plug'n play, low part count, Audio library compatible chip.
* The proposed schematic works, and gives a quite good sound output
* My prototype is working!

Here it is (through my ten year old mac PhotoBooth, sorry for the 2012 quality)!


So thanks to everybody! And especially to Mr Stoffregen, I can't count the number of time a teensy saved one of my projects! Can't wait to see what you have in mind for the T4.

Also, after testing the USB sound output, I can confirm the issue outlined in this thread, OSX 10.12.
 
Since I was running short on pins with a T3.2, I decided to go for a PCM5102 from TI, using a cheap AliExpress breakout board for development. This chip is also Plug and Play and has several advantages over the CS4334:
- It does not need a master clock, there is an internal PLL to restore it from the bit clock.
- It has an integrated charge pump, so that the output signal is bipolar without the need for coupling capacitors.
- It does automatic oversampling, x8 when fed with 44.1 or 48kHz, x4 when fed with 88.2 or 96kHz
- It accepts up to 32bit input data, and converts up to 24bit.

Just for info, in case someone was looking for a more audiophile alternative to the SGTL5000 on the playback side.
 
Sure thing, I'll keep documenting the project and post updates here as soon as it's done!

I already see lots of possible amelioration for the next prototype!

Thanks for the heads up regarding the PCM5102 chip! Would love to see a list of "proven" hardware directory that would help for BOM selection (with exemple schematics). So many variables when designing, it is always usefull to have some certainty!
 
I started a list of compatible I2S chips.

https://github.com/PaulStoffregen/Audio/commit/5bf65f1c47f8a5877179c13f6e180a5a5dab7dd3

For I2S output:

Code: 
Compatible CODEC Chips:

    STGL5000
    TLV320AIC3206
    AK4558 

Compatible DAC Chips:

    PCM5102A
    PCM1808
    PCM5242
    CS4344

For I2S Input:

Code: 
Compatible CODEC Chips:

    STGL5000
    TLV320AIC3206
    AK4558 

Compatible ADC Chips:

Compatible Microphones:

    SPH0645LM4H-B
    ICS43432
    ICS43434

There are probably many more lurking on old forum threads. If anyone knows of others I've missed, please reply with a link to the message or thread and I'll add it to the list.
 
You must log in or register to reply here.
Back
Top