But it cannot correct for the fact that the RPi only has one oscillator and performs non-integer re-sampling in order to process both 44.1KHz and 48KHz data families - nothing to do with jitter.
I'm sure it 'works' fine, but have you compared the sound with and without the compromise in data integrity that using 'raw' RPi I2S output introduces?
The Raspberry Pi generate one of the audio clocks frequencies by doing non-integer division, which generate a clock with the correct frequency when averaged, but it is very jittery.... The dam's FIFO and reclocker can handle that correctly so all the audio bits arrive at the correct time and in correct order....
I haven't listened closely to it, but other people have reported success on the main dam1021 list....
Feel free to add what you want of reclocker, just as we're clear that's it's not Needed.
Last edited:
With precisely the correct value?
I have, a few years ago I heard a difference with a Beaglebone Black implementation, which has the same fundamental oscillator issue as the RPi.
Based on my experience I think we'll have to agree to disagree on whether there's a need.
Just to be clear, I'm not talking about the Soekris DACs and there is no impled criticism of them as I have personal experience of their excellence, rather this is just about applying clocking to the RPi to address it's clocking shortcomings.
Last edited:
My latest investigations and practical tests lead me to the position that the re-clocking mechanism in the DAM is not up to par with the products stated ambition - being...
SOTA.
Using toslink and adding IAN's re-clocker makes quite a difference - so to me, there is a need. Measurements show a lot of adjustments making the clock wonder about on a second time scale basis...
//
… maybe there is a precise reason, back in the 2014 (#566 and #567)
Reference DAC Module - Discrete R-2R Sign Magnitude 24 bit 384 Khz
Please, take a look at the Si514 datasheet, it says 0.25 ps RMS phase jitter of course, with an integration bandwidth 1.875 MHz to 20 MHz !!!!
It would be very curious to see the RMS phase jitter with the integration bandwidth starting from 1Hz, much close to the carrier, that's the real part we have to look in digital to analog conversion
Attachments
Regarding RPi and jitter in real world tests. Take it for what it is worth but here are 2 interesting links.
Archimago's Musings: MEASUREMENTS: Intel i7 PC and Raspberry Pi 3 B+ Audio Streamer - XLR / RCA, Noise and Jitter. Do digital transports / streamers really make a difference? Do USB cables?
Archimago's Musings: MEASUREMENTS: Raspberry Pi 3 as USB Audio Streamer (with recommended CRAAP config & TIDAL/MQA arrives)
A bit OT but since it has been much talk about it lately.
I could not hear any difference between those different transports/streamers I have tested into the dam1021. If there were any, I just prefer i2s direct into the DAM. (including USB from a transport into a Gustard U12 (with reclocker) and either spdif og i2s (LVDS) into a LVDS receiver to the DAM.
Archimago's Musings: MEASUREMENTS: Intel i7 PC and Raspberry Pi 3 B+ Audio Streamer - XLR / RCA, Noise and Jitter. Do digital transports / streamers really make a difference? Do USB cables?
Archimago's Musings: MEASUREMENTS: Raspberry Pi 3 as USB Audio Streamer (with recommended CRAAP config & TIDAL/MQA arrives)
A bit OT but since it has been much talk about it lately.
I could not hear any difference between those different transports/streamers I have tested into the dam1021. If there were any, I just prefer i2s direct into the DAM. (including USB from a transport into a Gustard U12 (with reclocker) and either spdif og i2s (LVDS) into a LVDS receiver to the DAM.
Just to pre-empt the standard responses...
Ah, but those are just measurements. You can't measure emotions.
Ah, but those are just measurements. You can't measure emotions.
Clearly your gear is not resolving enough, and your ears aren't up to the job...
Last edited:
These Si parts are really poor as audio Master clocks - -89dBc at 100Hz offset says it all really...
Another issue with these PLL type XTAL parts is leakage / Spurious products from the internal PLL Reference Clock which IIRC was around 20MHz - this "extra" unwanted frequency leaks everywhere over the phase plots...
Really Horrid parts for high performance audio...
I posted this link a while ago, comparing Si parts. The 570 is up to 20dB better than the 514.
Oscillator Phase Noise Lookup - Silicon Labs
What frequency is used for this part by the way?
Oscillator Phase Noise Lookup - Silicon Labs
What frequency is used for this part by the way?
The Si514 is actually not that bad, check it at:
Oscillator Phase Noise Lookup - Silicon Labs
The Si514 is perfectly fine for most applications, those who want products with better oscillator phase noise, I have both the dam1121-01 and dam19x1 series.
Last edited:
Ooops, I just posted the same link.... The oscillators in my boards run at 45/49 Mhz. The output are LVDS, but then it goes though the FPGA....
Last edited:
I wonder how one can say "The Si514 is actually not that bad", please see the phase noise plot at 22.5792 Mhz, -108 dBc at 100 Hz from the carrier is a bad performance.
The Crystek CCHD-957, not an Oscilloquartz BVA or a Wenzel ULN oscillator, performs 20 db better, while a good oscillator exhibit -125dBc at 10 Hz from the carrier and -145 dBc at 100 Hz.
The Si514 is perfectly fine for telecom application, not for audio.
Attachments
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.