Entry-level digital scopes usually have a noise floor of only 60-70dB. So just don't take the scope measurements seriously. Most DAC ICs would easily beat such scopes in terms of noise.
BTW, did you manage to get rid of the 10 minute signal dropout ?
BTW, did you manage to get rid of the 10 minute signal dropout ?
I'm pretty impressed with that chip so far. It seems to be working pretty good.. Almost too good in that I've had to adjust the audio sync on my Amazon Firestick as far as it can go just to match to the video properly. My Denon amp audio is lagging behind the STA310, meaning the STA310 is really low latency. I looked in the STA310 docs, and it doesn't look like there's anyway to adjust it. It's ok now, but if Firestick let me nudge it a bit more, I probably would a tiny bit.. But it's mostly sync'ed.
So, now that your basic thing is working, you might want to look into any format detection / discerning problems that you faced, like DTS vs. AC3 vs. PCM.
The format detection seems to work mostly. I’ve only seen DTS once though. Sometimes when I play a DTS audio stream the decoder doesn’t execute a callback and still says it’s decoding ac3. But it still decoded. For all I know maybe the Firestick is transcoding it. But I coded that callback and have done my part at least. PCM to AC3 and back is always detected. But DTS programs don’t seem to trigger it. But like I said maybe the hardware in between is transcoding it. I haven’t had any audio dropouts since that original day. I think maybe a ground wire was loose and just causing a reset occasionally. But I’ve cleaned up some of the wiring and it’s been stable since. I’ve also made code
Improvements so the start up sequence is reliable now. Today I’ll probably test running the audio from it to the lm3886 power amplifiers, but using a 3.5mm cable. On the weekend I may try to hook them up directly, but I want to play with the volume levels and what not to calibrate the volume knob and initial settings first.
Improvements so the start up sequence is reliable now. Today I’ll probably test running the audio from it to the lm3886 power amplifiers, but using a 3.5mm cable. On the weekend I may try to hook them up directly, but I want to play with the volume levels and what not to calibrate the volume knob and initial settings first.
Attachments
PCM to AC3 and back is always detected. But DTS programs don’t seem to trigger it.
I never had any issues with DTS detection, or status information. What DTYPE do DTS streams show while decoding ? Do you have the same issue with DTS Audio CDs / DVDs & BDs, besides the streamer ?
And, what values are you using for
1) The autodetect-related registers ?
2) The number of sync words before lock ?
Try reading the status registers after a 100ms delay.Sometimes when I play a DTS audio stream the decoder doesn’t execute a callback and still says it’s decoding ac3. But it still decoded.
Last edited:
1) I haven't looked at the DTYPE, I can take a look. Is that what you recommend? I saw a note somewhere that the decodesel/streamsel is 0/5 for Dolby, but 3/6 or 6/3 for DTS. I did see that one time when I hit a breakpoint, but haven't seen it since. The Application Notes says that for DTS it should show a value of @0x4C = 3, @0x4D = 6. But I don't see that. I can check DTYPE though, maybe it's showing there.
2) I used the examples, which were just 1 of each (I think a value of 0).
// Enable auto detection on the stream
mDevice->writeRegister( DolbyDecoder_STA310::AUTODETECT_ENA, 1 );
// Set SPDIF auto-detection sensitivity
mDevice->writeRegister( DolbyDecoder_STA310::AUTODETECT_SENS, 0 );
// Only 1 packet needed to synchronize stream
mDevice->writeRegister( DolbyDecoder_STA310:😛ACKET_LOCK, 0 );
// Only 1 packet for synchronization lock
mDevice->writeRegister( DolbyDecoder_STA310::SYNC_LOCK, 0 );
3) I actually have an event firing every 5s that checks the status of everything, and for a DTS stream, at least when I read DECODESEL/STREAMSEL, it still shows 0/5.
2) I used the examples, which were just 1 of each (I think a value of 0).
// Enable auto detection on the stream
mDevice->writeRegister( DolbyDecoder_STA310::AUTODETECT_ENA, 1 );
// Set SPDIF auto-detection sensitivity
mDevice->writeRegister( DolbyDecoder_STA310::AUTODETECT_SENS, 0 );
// Only 1 packet needed to synchronize stream
mDevice->writeRegister( DolbyDecoder_STA310:😛ACKET_LOCK, 0 );
// Only 1 packet for synchronization lock
mDevice->writeRegister( DolbyDecoder_STA310::SYNC_LOCK, 0 );
3) I actually have an event firing every 5s that checks the status of everything, and for a DTS stream, at least when I read DECODESEL/STREAMSEL, it still shows 0/5.
I never had any issues with DTS detection, or status information. What DTYPE do DTS streams show while decoding ? Do you have the same issue with DTS Audio CDs / DVDs & BDs, besides the streamer ?
Dude, I haven't used a CD, Blue Ray, or a DVD in years 🙂 I have the units somewhere in boxes. When I moved from Canada to Spain I had to leave most of my stuff behind.
Your autodetect values are all OK.
Don't keep polling every 5 secs like that. Instead, enable the HDR interrupt and when it strikes, disable it and read the DTYPE and other status regs (after 100ms) to get the format, channels, bitrate etc. You can print them later, after leaving the ISR.
DTYPE is where you get the format information, not DECODESEL. STREAMSEL = 3 means elementary stream (header ignored), You need the DTS along with all the header information.
The STRSEL / DECODESEL is 5/0 for not only AC3, but DTS and 48kHz LPCM also !!!
Don't keep polling every 5 secs like that. Instead, enable the HDR interrupt and when it strikes, disable it and read the DTYPE and other status regs (after 100ms) to get the format, channels, bitrate etc. You can print them later, after leaving the ISR.
DTYPE is where you get the format information, not DECODESEL. STREAMSEL = 3 means elementary stream (header ignored), You need the DTS along with all the header information.
The STRSEL / DECODESEL is 5/0 for not only AC3, but DTS and 48kHz LPCM also !!!
Ok thanks. I had HDR interrupt set, but I noticed it was firing endlessly, so I removed it. If you disable it though, how do you handle learning the format for a stream change? Do you just read the HDR information when you get the interrupt for a stream change as well, or do you re-enable the HDR interrupt there, and then disable it again when it fires later?
The STRSEL / DECODESEL is 5/0 for not only AC3, but DTS and 48kHz LPCM also !!!
Ok thanks.. But the application notes say something slightly different, which is why I was waiting for that. It does mention the DTYPE, but it also shows a different STREAMSEL/DECODESEL for DTS. 6/3 FOR SPDIF input and ES. I'll try it your way.
Attachments
Since you need only one HDR per detection, you turn that off inside the its own ISR, which guarantees exactly one firing. When the next format is detected, you'd be soft resetting and repeating the whole init sequence anyway and within that the HDR would also get enabled, isnt it ?
The document is correct in that STREAMSEL / DECODESEL for DTS is 3/6 (ES) or 5/6 (SPDIF), but a value of 5/0 also seems to successfully loads the DTS decoder, and that is the value that the inbuilt autodetect puts into these registers.
The actual datatype is in DTYPE, which appears to be pulled out of the SPDIF header directly (see attachment). Wait 100ms after HDR interrupt to read the status regs (bitrate etc.).
The document is correct in that STREAMSEL / DECODESEL for DTS is 3/6 (ES) or 5/6 (SPDIF), but a value of 5/0 also seems to successfully loads the DTS decoder, and that is the value that the inbuilt autodetect puts into these registers.
The actual datatype is in DTYPE, which appears to be pulled out of the SPDIF header directly (see attachment). Wait 100ms after HDR interrupt to read the status regs (bitrate etc.).
Attachments
How are you capturing a secondary change from ac3 to dts though? It doesn’t register as a stream change for me (streamsel and decodesel are the same), but now the hdr interrupt is off isn’t it? Seems like in this scenario you’d have to poll, no? Or does it register as a change even if those two don’t change?
Last edited:
Like you’ve received AC3 the first time, processed the HDR, and now turned off the HDR interrupt. And let’s say you start watching DTS. So DTYPE changes to DTS, but you may not get a callback since sta310 still is in the same streamsel and decodesel, no? Nothing has changed but the header, but now the interrupt is off.
If I remember correctly, the RST interrupt strikes when DTS/PCM is detected, and inside its ISR, all interrupts including HDR are enabled again.
A small correction here:
Correction : Wait 100ms after LCK or RST to read DTYPE (if HDR) and status regs.Wait 100ms after HDR interrupt to read the status regs (bitrate etc.).
So I just tried again.. I find that interrupt a bit sporadic as in I don't really get when it fires. If I switch the audio source to PCM and to Dolby and back, it always fires. But moving from DTS to AC3 it doesn't fire. And in all scenarios it reports DTYPE of 1, which is Dolby Digital. So maybe my Firestick and/or HDMI audio extractor are somehow limiting it to Dolby Digital.
I managed to force Plex to send DTS, and I can verify it's sending DTS. The STA310 reports a DTYPE of 0, which is PCM. So I'm guessing either the firestick or HDMI extractor are converting it.
UPDATE: if I hook my Denon up, it reports the Audio as Dolby Digital as well. So I suspect Firestick is transcoding. Apparently it doesn't support DTS passthru.
UPDATE: if I hook my Denon up, it reports the Audio as Dolby Digital as well. So I suspect Firestick is transcoding. Apparently it doesn't support DTS passthru.
Last edited:
- Home
- Amplifiers
- Chip Amps
- LM3886 5.1 build