Ok. I now have half of my DAC working; to be specific, the left channel. The right channel also "works", but there is spurious output; it is a scratchy-sounding, digital click that is seemingly randomly spaced throughout the audio.
It isn't truly random, because when I play digital silence there are no spurious tones. It is definitely signal related in some way. I am guessing this is spurious triggering of the high significance bits in the right channel?
I inverted LRCK and found that the spurious clicks moved to the left channel. I also built another copy of just the DAC portion of my circuit and the behavior was identical. I also clocked the 44.1kHz output of my receiver into this copied DAC and got clean output on both channels.
This may be becoming an old saw, but I am using AD1896 to reclock my data. I am outputting at 192kHz, 24-bit right justified. My BCK is 12.288MHz. I have tried both 24.576MHz and 12.288MHz for MCK, behavior identical. I don't think there is a MCK signal integrity problem since BCK seems fine. Looking at LRCK on my scope shows a very clean trace, but my bandwidth is only 20MHz.
I have looked at the data outputs, triggering on LRCK. I created a test signal at -90dB, 16bit. I see the data on the input of AD1896 is clearly a single bit toggling. On the output, I see the 9 low-order bits toggling, as expected due to dither. I don't see any visible evidence of high order bits toggling, but I don't have a storage scope.
One interesting thing about this is that AD1896 appears to make some of the MSBs in the 32-bit frame high. I can't count the exact number, but it doesn't look like all 8. These shouldn't be clocked as audio data, but I wonder if I am skipping clock cycles and these are being clocked as MSBs of the 24-bit audio frame?
Anyone have any idea what the problem could be? Is this a signal integrity problem? A problem with my clocks? (all syncronous) The LRCK inversion seems telling, but I can't figure out what it means.
I am a bit at a loss. I would greatly appreciate anyone's input, especially if you've ever dealt with a similar problem with AD1853.
It isn't truly random, because when I play digital silence there are no spurious tones. It is definitely signal related in some way. I am guessing this is spurious triggering of the high significance bits in the right channel?
I inverted LRCK and found that the spurious clicks moved to the left channel. I also built another copy of just the DAC portion of my circuit and the behavior was identical. I also clocked the 44.1kHz output of my receiver into this copied DAC and got clean output on both channels.
This may be becoming an old saw, but I am using AD1896 to reclock my data. I am outputting at 192kHz, 24-bit right justified. My BCK is 12.288MHz. I have tried both 24.576MHz and 12.288MHz for MCK, behavior identical. I don't think there is a MCK signal integrity problem since BCK seems fine. Looking at LRCK on my scope shows a very clean trace, but my bandwidth is only 20MHz.
I have looked at the data outputs, triggering on LRCK. I created a test signal at -90dB, 16bit. I see the data on the input of AD1896 is clearly a single bit toggling. On the output, I see the 9 low-order bits toggling, as expected due to dither. I don't see any visible evidence of high order bits toggling, but I don't have a storage scope.
One interesting thing about this is that AD1896 appears to make some of the MSBs in the 32-bit frame high. I can't count the exact number, but it doesn't look like all 8. These shouldn't be clocked as audio data, but I wonder if I am skipping clock cycles and these are being clocked as MSBs of the 24-bit audio frame?
Anyone have any idea what the problem could be? Is this a signal integrity problem? A problem with my clocks? (all syncronous) The LRCK inversion seems telling, but I can't figure out what it means.
I am a bit at a loss. I would greatly appreciate anyone's input, especially if you've ever dealt with a similar problem with AD1853.
AD1853
No, I haven't had the same problem w. 1853, I've used 1852.
So the question is why do u use Righ-justified? Is 1853 set to RJ too???
I see the problem here. Try to set the control bits /in hardware mode/ of 1853 in a different way. I mean the input format and the interpolator as well. Do u have jumpers or DIPswitch for this? MY Experience w. 1852 showed a very strange relationship w. these set-up bits - The working variant was not the one it should be according to datasheets. I think the difference was in the interpolator coefficients - it was playing at 48k, but IT WORKED 😉 set at 96k or Something like this.
Just give this a try. But I use IIS format. Can u move to another format???
Success
No, I haven't had the same problem w. 1853, I've used 1852.
So the question is why do u use Righ-justified? Is 1853 set to RJ too???
I see the problem here. Try to set the control bits /in hardware mode/ of 1853 in a different way. I mean the input format and the interpolator as well. Do u have jumpers or DIPswitch for this? MY Experience w. 1852 showed a very strange relationship w. these set-up bits - The working variant was not the one it should be according to datasheets. I think the difference was in the interpolator coefficients - it was playing at 48k, but IT WORKED 😉 set at 96k or Something like this.
Just give this a try. But I use IIS format. Can u move to another format???
Success
I can set the INTERP multiplier easily but not the data mode; I chose RJ24 because it was the easiest to route...not an easy change now! (You were too late on this decision Jocko) It seemed to me too that I could set the oversampling lower than was spec'd at 44.1kHz but at 192 I am already at the lowest possible (2X). I am setting both in hardware mode.
I really don't understand what it could be; it can't be a problem with LRCK, because then reversing phase wouldn't have any effect. Could it be a problem with BCK? Double-clocking leading to early load of the MSBs? Why would it only happen in one channel though, and both on the PCB *and* with rat's nest wiring? I would think that a signal integrity problem would mean that the alligator-clip version wouldn't work at all.
I have a hunch that if I simply went to 20-bit the sound would go away, but I think that would just be concealing the problem. (not to mention the loss in quality) I'll be getting a faster storage scope next week; anyone have any suggestions?
I really don't understand what it could be; it can't be a problem with LRCK, because then reversing phase wouldn't have any effect. Could it be a problem with BCK? Double-clocking leading to early load of the MSBs? Why would it only happen in one channel though, and both on the PCB *and* with rat's nest wiring? I would think that a signal integrity problem would mean that the alligator-clip version wouldn't work at all.
I have a hunch that if I simply went to 20-bit the sound would go away, but I think that would just be concealing the problem. (not to mention the loss in quality) I'll be getting a faster storage scope next week; anyone have any suggestions?
Status update
Well, I'm no closer to a solution, but I do have more information now that I have a faster scope.
The phase relationships of all of the clocks and the data are fine; the transitions are right where the datasheet says they should be.
The AD1896 definitely marks the first 8 bits of each frame high.
My next step if no one has any bright ideas is to desolder the 49.152MHz clock and replace with 24.576MHz...I figure this will give me more of a timing margin if it really is a signal integrity problem. Even if it works, though, I'm still no closer to a solution.
Well, I'm no closer to a solution, but I do have more information now that I have a faster scope.
The phase relationships of all of the clocks and the data are fine; the transitions are right where the datasheet says they should be.
The AD1896 definitely marks the first 8 bits of each frame high.
My next step if no one has any bright ideas is to desolder the 49.152MHz clock and replace with 24.576MHz...I figure this will give me more of a timing margin if it really is a signal integrity problem. Even if it works, though, I'm still no closer to a solution.
- Status
- Not open for further replies.