Data format to ADAU17x?
I'm sure this is an easy one but I'm not finding the answer by searching for it. I have an application that uses an I2C connection from a SiLabs Gecko to send DSP configuration stuff (I had asked a question about that earlier, solved the problem and would be happy to share that code if anyone wants it). I also have an I2S connection and would be interested in sending it some prestored sounds - button press clicks- that sort of thing. I'm assuming it wants the data clocked in at the correct playback speed, but what format? Is it the 28.0 format? 5.23? Something else? Is there some trick other than just taking the data and jamming it in? A previous engineer on this project came up with some code that just makes raspy static noises and my attempts haven't done much better.
Examples of an implementation in code (any language or processor) would be greatly appreciated.
Thanks!
Howard
i2s
adau170x
audio
Hello Howard,
I2S is a bit different from the world inside the DSP. It is just word size that is important. I2S can be either 16 bit or 24 bit. Usually it is 24 bit. So you need to send 24 bit data. In the DSP this means it needs to be 1.23 format. In the DSP you will have a lot of headroom (5.23) but before it is sent to the serial ports it is clipped down to 1.23 and it is up to you to make sure the audio is limited before leaving the DSP. Look at figure 29 in the datasheet.
Next, I2S also needs left/right clock and bitclock that is at the proper frequencies. It also needs to be correlated to the master clock. I suggest you obtain a decent multi-channel scope to look at the LRCLK, BCLK and SDATA lines to "see" what is going on.
You also have to decide who is the master so you know who is sending the clocks and who is receiving. There is a lot more to all this but I will save that for further questions.
Dave T
Dave-
Thanks for the clarification! I was aware of the need for the clocks and determining who was the master. I worked on other parts of this design previously and another engineer claims to have written the code for the digital transfer of sound into the DSP. What he got was a horrible hiss and that's about all. So it's possible that I have the makings of the right solution. He probably got the clock wrong and I'm certain he got the data wrong. He's simply pumping 16-bit WAV format data into the stream and I knew that had to be wrong.
I have to put out another fire first, then I'll tackle this one. Obviously getting the data into 1.23 has to happen first.
Howard
Please log in to reply.