Questions about DS input processing


#1

Hi @tedsmith. As a music lover, I’m thoroughly enjoying your creation and spending way too much time in the sweet spot when there are other things I ought to be doing. As a geek, I’m fascinated by how you managed it. Hoping you’ll be able to shed a little more light on how exactly the data coming from external sources gets loaded into the FPGA for processing.

In particular I’m curious about the significance of the “170MHz Input Processing” described on the product website (which I suspect is a rounded-up 169.344MHz?) and exactly how and where the 32-bit subframes of SPDIF data become 24-bit samples. Is it simply that the FGPA is sampling a serial data stream at ~170MHz such that it has at least three cycles to detect each of the bi-phase mark transitions for stereo SPDIF data with a 352.8kHz sample rate? Or do you have external SPDIF decoding and then I2S lines coming into the FPGA?

And how does “native” DSD over I2S fit into this?

I understand that some things have to remain confidential for commercial reasons, and apologies if I’ve missed where this is already explained elsewhere, but whatever you can share would be appreciated.

Thanks!


#2

Indeed it is 169.344MHz, tho I’ve used plenty of other similar rates.

I don’t attempt to recover the incoming clocks from I2S, S/PDIF, AES/EBU, TOSLink, etc. Instead I sample all incoming digital inputs at the 169.344MHz rate and look for patterns in the bits. For I2S it’s pretty simple - I watch for the first high clock after a low clock and then I use the corresponding LR clock and the Data samples. For raw DSD over the HDMI connectors I use the left and right samples when I first see a high clock.

The Bi-Phase Mark encoded signals are decoded by noticing whether a transition is missing compared to the recent history of the signal.

The whole point is to not be held hostage by the jitter, bugs and sample rate restrictions that exist in S/PDIF receiver chips, etc.

It’s quite simple: the more accurately you track an incoming clock the more of it’s jitter you are letting thru, so I ignore the timing of their edges entirely.


#3

OK, that makes total sense to me for SPDIF. I think you mentioned somewhere before that the USB input actually relays SPDIF (inc DoP) to the FPGA, yes?

With PCM over I2S, you mention “first high clock after a low clock”. Which clock line are you referring to there? Can you get away with just two lines coming into the FPGA: L/R clock and data?

And last one, is there a standard way to encode DSD on I2S lines? I have been searching but can’t find one. Mostly wondering what kind of patterns you’d be looking for to detect native DSD and whether those same two lines would be sufficient.


#4

USB and the bridge send I2S to the FPGA. The FPGA sees 4 I2S inputs and 3 S/PDIF like inputs.

I2S has a master clock (which we don’t use at all), a bit clock, L/R clock and data. There’s no advantage to reverse engineering clock transitions from the data/L/R clock, tho it could be done. We don’t look at the edges of the clock so we’d be getting the same info from data/LR but with extra work.

There’s a semi standard - some ESS chips can accept raw DSD over the same digital input lines as they do I2S. Since many people just echo those pins to the interface there are more and more devices which advertise raw DSD support over their I2S inputs. We switched around the NPC and DS to use those pinouts when Jesus pointed out that we were “backwards”.

The L/R clock has a very precise waveshape that’s definitely different than a channel of DSD data. Once again you could infer the DSD clock from the left and right channels, but there’s no reason to not watch sampled clock transitions (as opposed to clock edges.)


#5

My DS has an empty expansion slot (sorry, the current Bridge isn’t appealing to me) so of course I’m wondering about what other things could theoretically occupy that space in the future.

If you’re willing and able to say…

  • How many signal lines from the expansion port currently carry I2S to the FPGA? (Physical traces, even if not processed such as the MCLK.)

  • What is the maximum baud rate each of those lines could carry?

Just in case you’re concerned about what I have in mind, I’m wondering whether those same lines could be used for multiple additional SPDIF inputs, and if so then at what rate. I think we’d need about 45MHz to carry DSD128 as DoP in raw SPDIF, which is probably asking too much.

Obviously the other option is to have SPDIF decoded to I2S on the expansion card. But direct lines might be cheaper and simpler if they worked…


#6

Any such changes would require new FPGA release which isn’t as simple as one would like.

Anyway there are three wires from the bridge expansion slot that make it to the FPGA. (The MCLK is just terminated in hardware and doesn’t go to the FPGA.)

With the current FPGA code a 192k sample rate is the maximum rate supported over S/PDIF wires - it’s theoretically possible to do a higher rate with FPGA modifications, but it wasn’t needed so it wasn’t implemented. Any such changes would likely lead to a lower sound quality: the faster the clocks the more noise/jitter that will be generated and the current S/PDIF/I2S sampling clock is a nice multiple of the other clocks present - going to a slightly faster clock would cause more beating between the clocks…


#7

Thanks again, Ted. Gives me something to noodle over.