I know what it said, and understood what the member was trying to get at. If a technical term was used loosely as words sometimes are, most of us can still figure out what the person was trying to say, or else ask for further clarification. Some people use 'jitter' as a catch-all word for problems that result in perceptual effects that sound like jitter sometimes can.
I have heard differences between the source OS, its parameters or the choice of sbc in systems isolated/reclocked by WaveIO and/or FIFO. I no longer chase this stuff, but I do find it curious that the theory that OS interrupts still cause sound differences even though the data will be the same and the clock comes from the re-clocker downstream. In my theory there are 3 possible paths for SBC noise to impact the sound.
1. The isolator in the FIFO is not fully effective,
2. The noise propagates throughout the ground plane, or
3. The noise propagates via radio transmission/emi
My hunch is it likely #3
Andre criticized Ian's design asserting that he had the Rpi too close and without sufficient shielding. Ian responded with StationPI. In my system StationPi made an improvement even though my Rpi/FIFO stack was already shielded from the DAC and output buffer.
So, out of curiosity, I ask Blitz how he has laid out the system to shield the SBC from the rest of the system?
BTW, while I have reached the level Blitz describes where I no longer am concerned with OS differences, I do have a flaw in my system that the RJ45 cable has to be routed with care to avoid noise. So clearly there is an antenna somewhere tuned to that frequency confirming my assertion that everything matters.
#3 is certainly possible especially if RPi without proper casing is used. The shielding in StationPi seems inadequate.
But it should be fairly easy to verify this. Switch from RPi to a battery powered laptop and use async UAC2 with an USB-I2S board. Move laptop as far from FiFo & dac as possible. If you still hear noise the reason is probably not radiated RFI/EMI from host.
Please do report on the battery supply.
I am actually looking at the lower 3.3V because I have a line stage w/ a TVC, so I like to keep the output rather down (at least in this system).
If anyone has a hint of which would be better on Vref, UltraBib1.3 or Reflektor for 3.3V I'd love to hear about it.
Or: is there any news from Andrea regarding the Vref experiments he wanted to perform?
Agreed bohrok2610. But I am sticking with the IAN FIFO StationPi because it fits into my available space, and everything is a compromise. If I were starting from scratch for the SOTA build, I'd likely give Andre's DAC/Fifo/clock a go with lots of Ultracap PS. But I am past all that and content to watch with interest on the side lines.
Like Blitz, one of my all-time favorite SBC choices was the Alex 1D which was housed in its own little metal case that sat outside the metal case containing the WaveIO/DAC assembly.
Like Blitz, one of my all-time favorite SBC choices was the Alex 1D which was housed in its own little metal case that sat outside the metal case containing the WaveIO/DAC assembly.
Andrea has suggested to have the Rpi as far as possible from the Fifo/Dac, I have the feeling too this might accounts to (many?) reported differences. I am using a 3m USB cable from the Rpi to the USBtoI2S/FIFO.
Other than this, Andrea mentioned too the FIFO light, is not the ultimate (Sonic Empire) solution. For me, it is good enough thou.
You are right.
The only jitter we are interested in is the jitter at the input of the DAC chip. ( WCLK' jitter for some old chips and MCLK' jitter for almost all the rest)
In isochronic USB communication with asynchronous synchronization, during the normal operation, this jitter totally depend of a oscillator's quality, oscillator's power supply quality, oscillator's placement at the PCB and layout.
And it is totally independent from the PC/OS/USB-host. Otherwise, something is not working right.
Regardless of how large the FIFO buffer is there are always jittery input signals present as old data is being clocked out, can't see how this doesn't have potential to cause correlated interference of some kind.
Is there a theoretical advantage to continually increasing size of buffer?
If you were to buffer an entire track before playback, then the input could be disconnected, there would be no source activity and truly no possible way for it to cause interference during playback, not sure if that would still be considered a FIFO, it would need total redesign.
I2S stream would no longer be an inappropriate input method and you would need a large, indeterminate amount of memory to store entire tracks.
Is there a theoretical advantage to continually increasing size of buffer?
If you were to buffer an entire track before playback, then the input could be disconnected, there would be no source activity and truly no possible way for it to cause interference during playback, not sure if that would still be considered a FIFO, it would need total redesign.
I2S stream would no longer be an inappropriate input method and you would need a large, indeterminate amount of memory to store entire tracks.
Maybe someone can help with this:
I was about to put together DRIXO 5.6MHz but notice the chokes I have do not match the current BOM
Mine:
B82134A5301M000 (210uH 0.3A)
B82132A5401M000 (50uH 0.4A)
BOM:
B82111E0000C026 (220uH 0.5A)
B82111E0000C024 (56uH 1.5A)
When I upload the BOM to mouser it to shows up as upper one , but viewing BOM in spreadsheet shows the lower one.
What part is everyone else using in their DRIXO? If you uploaded BOM to Mouser you may have the same ones (or maybe you noticed the potential error unlike me)
I was about to put together DRIXO 5.6MHz but notice the chokes I have do not match the current BOM
Mine:
B82134A5301M000 (210uH 0.3A)
B82132A5401M000 (50uH 0.4A)
BOM:
B82111E0000C026 (220uH 0.5A)
B82111E0000C024 (56uH 1.5A)
When I upload the BOM to mouser it to shows up as upper one , but viewing BOM in spreadsheet shows the lower one.
What part is everyone else using in their DRIXO? If you uploaded BOM to Mouser you may have the same ones (or maybe you noticed the potential error unlike me)
