I suggest that you finish the DAC. That's when you'll know if you're actually getting something meaningful.
Which PLL are you using, the SPDIF PLL or the Audio PLL ? And what configuration ?
Upon format change, you service the auto-detect interrupt that involves writing all the configuration registers (except PLL) to suit the newly detected format.
Upon auto-detection, the new format is indicated by the HDR interrupt that needs to be picked up by the micro. How do you exactly know that it's decoding correctly and what method are you currently using to discern DTS vs. AC3 vs. PCM?
You need an LCD to continuously read-back from multiple registers on the chip. You may later omit that after your code has become bulletproof.
for the DAC, you could temporarly use a Rasberry pi dac or Aryclic DAC (ES9023) board with 4 wire i2s + 2 for supply and Ground and you will have RCA audio out. incase you do not have a MCLK than connect 50Mhz Oscilator to MCLK pin and use 3 wire.
https://www.arylic.com/products/expansion-boards
https://www.arylic.com/products/expansion-boards
1) I don't know, I'd rather get the bitstream looking good first. If the sample rate is 32khz, I think it's not good considering nothing in my audio setup should be 32khz
2) I'm using the SPDIF PLL.
3) What do you change based on the format? I mean, streamsel and decodesel are already updated in the callback, so what is there to set? If I read sfreq, it always seems to return 0, which to me is weird.
4) You said previously you update your PLL coefficients - I'm not doing that, since I'm using 384 which is the default. Don't you need to know the sample rate for that? How are you getting that? None of my calls for the sample rate seem to return anything useful.
Well, if I change the audio on my TV, the callback happens, which to means it's decoding I think. The three clocks on the I2S lines all appear right, other than the 32khz issue. ANd if I poll what it's decoding, it says it's decoding SPDIF and Dolby Digital for the format.
2) I'm using the SPDIF PLL.
3) What do you change based on the format? I mean, streamsel and decodesel are already updated in the callback, so what is there to set? If I read sfreq, it always seems to return 0, which to me is weird.
4) You said previously you update your PLL coefficients - I'm not doing that, since I'm using 384 which is the default. Don't you need to know the sample rate for that? How are you getting that? None of my calls for the sample rate seem to return anything useful.
Well, if I change the audio on my TV, the callback happens, which to means it's decoding I think. The three clocks on the I2S lines all appear right, other than the 32khz issue. ANd if I poll what it's decoding, it says it's decoding SPDIF and Dolby Digital for the format.
It's interesting, I tried briefly to update to the Audio PLL (I'm not entirely clear on the difference in my case), and the output switched to 48kHz now, which seems right. The other clocks are reflective of 384xFS as well.
And are you using the SPDIF input ?
There'e config regs for AC3, DTS, MPEG etc. that need to carry some meaningful values for correct decoding. Refer to the "Getting Started" document.
No need to update, PLL regs are cleared only upon hard reset, not a soft one.
No need for sample-rate. 32kHz belongs to the 48kHz family.
Looks like you're Linear PCM.
You seem to be shooting in the dark. I suggest you get the DAC & an LCD to write reg values and debug properly.
Based on which reg values ?
I don't need an LCD, I have a real time debugger - the STM32. I can literally set a breakpoint and see the value of the registers after they are read. I can also see the frequencies of the I2S lines on my oscilloscope, or when they show nothing. I don't think I'm shooting in the dark, I can watch it all in real time, even the registers when they are read and when the callback happens.
Ahh! That might explain it.. Thanks.. You think I drop everything to 256, or just switch to the audio PLL?
See, there's an inherent issue with this chip that is, in the LPCM mode, the chip doesn't know it's doing LPCM, nor does it know the sample rate. The SFREQ update is for the encoded formats only.
So, for LPCM, it maybe better to use the SPDIF PLL as the sample rate is recovered from the bitstream. For others, it doesn't matter which PLL is used, as the sample rate information i available from the bitstream header and also automatically updated to SFREQ.
Whenever I poll SFREQ, it's always zero. Even when the decoder says it's decoding DOLBY. So I dunno, it's weird. .I'm using a HDMI to SPDIF converter that looks cheap. I ordered a better one tomorrow and I"ll see if it makes any difference.
I tried switching to the 256xfs and updating the SPDIF and PCM DIVIDER registers, and now the SPDIF PLL is outputting 48kHz on the I2S (fixed) word clock, which is right (48khz sampling rate).
Last edited:
Although 0 according to the datasheet says 46kHz - maybe it is a typo and means 48kHz? Maybe that's accurate then.
The correct SFREQ value for 48kHz is zero, for all encoded formats including AC3. For LPCM, this reg is not updated at all.
No need, it's probably working correctly.
Right. Maybe you meant I2S instead of I2C.
The weird thing is using that device it doesn’t always execute the callback when I think it should. Like if I adjust it from 5.1 to 2.0, often the chip will still think it’s decoding 5.1 even though the device says 2.0. So I just want another device to test. It’s Amazon, so I can always return if 🙂
Anyways, thanks for your help. I'm heading out to drink beer now, so I'll try more tomorrow. I have a cheap I2S decoder board somewhere that has a headphone jack, so maybe tomorrow I'll wire it up and see if I can hear sound. But now that it's outputting at 48kHz on the oscilloscope, I feel more hopeful.
I think that's correct, only a change in format will cause the autodetect interrupt to strike. The HDR interrupt and the relevant status reg might show a change though.
I think that’s the weird thing. If the device can’t auto detect a change to pcm and a sfreq of 0 means 48kHz, is there any real way to know that the sfreq register isn’t valid in that case? If you read it I imagine it’ll still say zero.
The chip can detect a change from AC3 / DTS to PCM, it's just PCM to PCM that can't be picked up, as that's not a change in format. And, whenever the autodetect returns a PCM stream (DTYPE = 0x00), the SFREQ value is not valid and the sample rate must be picked up looking at the DECODESEL value.
And for PCM, there's no status register update, so you just assume 2.0 ch and 1536kbps all the time. Hope that helps.
Last edited:
So, a bit of progress update.
I built a DAC today based on the PCM1681. I don't have any speakers hooked up currently, but I watched the waveform on the output of it, and when I use the Beep Tone on the STA310, which the documentation says is a triangle wave, it shows up just fine as a triangle wav on the scope. So far so good.
When I do dolby digital though, I can see the waveforms, and they follow along with what the TV shows, but the signals seem to have more noise than signal. I'm not sure if this is clock jitter or where it's coming from, but it's a very noisy representation of the audio waveform. I know it needs to go through a low pass filter next, but it seems pretty messy at this stage, and I'm not sure a LPF will fix it.
I ordered a simple I2S board from Amazon that has a headphone jack, so I'll try it on Monday and see how it sounds. It could be just an artifact of the testing process. But when I look at the three audio clocks, PCMCLK, BITCLK and LRCLK, they don't look super great on their own - PCMCLK looks more like a sine wave, BITCLK looks like wobby square wave, and both LRCLK and DATA look square wave like, but with ringing. So I might have to play with it a bit. Do you ever look at your clock outputs? Just curious what yours looked like. I don't really have much control over those so not sure how I can make them better.
I built a DAC today based on the PCM1681. I don't have any speakers hooked up currently, but I watched the waveform on the output of it, and when I use the Beep Tone on the STA310, which the documentation says is a triangle wave, it shows up just fine as a triangle wav on the scope. So far so good.
When I do dolby digital though, I can see the waveforms, and they follow along with what the TV shows, but the signals seem to have more noise than signal. I'm not sure if this is clock jitter or where it's coming from, but it's a very noisy representation of the audio waveform. I know it needs to go through a low pass filter next, but it seems pretty messy at this stage, and I'm not sure a LPF will fix it.
I ordered a simple I2S board from Amazon that has a headphone jack, so I'll try it on Monday and see how it sounds. It could be just an artifact of the testing process. But when I look at the three audio clocks, PCMCLK, BITCLK and LRCLK, they don't look super great on their own - PCMCLK looks more like a sine wave, BITCLK looks like wobby square wave, and both LRCLK and DATA look square wave like, but with ringing. So I might have to play with it a bit. Do you ever look at your clock outputs? Just curious what yours looked like. I don't really have much control over those so not sure how I can make them better.
Use the board I shared the link of, you can use external supply for and it has a onboard 5 to 3.3 volt regulator
Or get a Hifibberry dac pro PCM5122 which has a headphone and RCA out,
If I am not wrong whichever dac you use it will give full volume out unless you control it via its i2c bus or put a pot on output.
I have one of those DAC HATs actually, I don't think it would work. It is meant to run as a I2S master, not a slave. If you look at the driver for it (which I have), it uses GPIO pins to configure which clock to use on the DAC HAT So I'm not sure it would be easy to hook up. I'll use one of those cheaper boards that have a simple pin out, also based on a similar chip. I'll let you know how it goes.