Why doesn't MicroRendu have built-in I2S output?

[Milt99]

Apologies in advance if this shows my ignorance.

I'm in the process of putting together a NAS-based all digital source for my 2-channel system.

Plan on a Synology NAS going to a MicroRendu feeding a Singer SU-1 to a Halo Spring.

Since the consensus seems to be that the I2S input to the Halo Spring is the "best" input,

why doesn't the MicroRendu have USB & I2S outputs?

It seems it would have simplified the connection chain greatly.

I can also see that it would have made the MicroRendu more complicated and expensive given the theories

about the issues with the USB protocol and audio data transmission.

I just have an inherent belief that the fewer devices\connections in the signal chain the better.

Trust me, I'm not criticizing Sonore or anything of that nature.

I'm just trying to educate myself and better understand the intricacies of digital-based audio.

[CrushingIt]

I'll take a stab. I2S was developed by Philips as a way to move digital signals inside a cd player and maybe whatever other digital equipment existed at the time. They never intended it to be anything else. 

Some high end manufacturers along the way thought it would be better than spdif so they started using it but almost always as a way to connect their transports to their dacs. 

As such everyone used their own physical system. I think I've seen three or four different implementations  over the years.There is no standard so what works for you and your Halo won't work for the guy down the street. 

 

Please anyone correct me if I'm wrong.

Steve

 

 

[Holzohr]

16 hours ago, Milt99 said:

Since the consensus seems to be that the I2S input to the Halo Spring is the "best" input,

why doesn't the MicroRendu have USB & I2S outputs?

I guess Sonore doesn't want any "cannibalism" between the µRendu and the Signature Rendu.

 

Signature Series Rendu

[4est]

56 minutes ago, CrushingIt said:

I'll take a stab. I2S was developed by Philips as a way to move digital signals inside a cd player and maybe whatever other digital equipment existed at the time. They never intended it to be anything else. 

Some high end manufacturers along the way thought it would be better than spdif so they started using it but almost always as a way to connect their transports to their dacs. 

As such everyone used their own physical system. I think I've seen three or four different implementations  over the years.There is no standard so what works for you and your Halo won't work for the guy down the street. 

 

Please anyone correct me if I'm wrong.

Steve

 

 

 

 

I2S is actually a standard: https://en.wikipedia.org/wiki/I²S

 

There are others such as EIAJ, but i2s seems to have risen to the top in PCM. The "other" i2s would be balanced, coined LVDS, and this is what confuses people as there is no standard way of doing this that I am aware of. Manufactures seem to have differing methods of using the HDMI cabling.

 

 

[JohnSwenson]

18 hours ago, Milt99 said:

Apologies in advance if this shows my ignorance.

I'm in the process of putting together a NAS-based all digital source for my 2-channel system.

Plan on a Synology NAS going to a MicroRendu feeding a Singer SU-1 to a Halo Spring.

Since the consensus seems to be that the I2S input to the Halo Spring is the "best" input,

why doesn't the MicroRendu have USB & I2S outputs?

It seems it would have simplified the connection chain greatly.

I can also see that it would have made the MicroRendu more complicated and expensive given the theories

about the issues with the USB protocol and audio data transmission.

I just have an inherent belief that the fewer devices\connections in the signal chain the better.

Trust me, I'm not criticizing Sonore or anything of that nature.

I'm just trying to educate myself and better understand the intricacies of digital-based audio.

First off, is it really I2S that you want? I2S itself is PCM, but it seems like many people are talking about DSD, which either means DoP or something else. There are several different "standards" for using I2S wires to transfer DSD data directly, but they are all different and no clear "standard" in the marketplace right now. This makes it very difficult to produce a piece of hardware not tied to a specific DAC.

 

Even if you relegate this to just PCM I2S output it would cost a LOT more money to do it RIGHT. The I2S implementations have the clocking coming over the wires, that means that for the BEST quality the I2S source has to have extremely good clocks at the audio sample frequency families. These are not cheap.

 

Next is getting the I2S out of the processor. The iMX6 used in the microRendu has a built in I2S generator, but it is only good up to 192, it simply does not work properly at higher sample rates. (I know I tried for years to get it to work at 384). It could be possible to add an FPGA and connect that to one of the high speed buses, but again that adds cost and takes a significant amount of software work to develop a custom driver.

 

So upshot, adding I2S done WELL would add a LOT to the price, make it much larger, and add a lot of time to the development.

 

Sonore made the decision that the extra cost and development lead time was not appropriate. Those that wanted I2S out are a very small percentage of the potential users of the product, and making everybody pay a much higher price for something most would never use was deemed not to be a good idea.

 

John S.

 

 

 

 

[plissken]

Isn't I2S inherently, and specifically designed, for short haul PCB traces and the like? It's a chip to chip interface. 

[Milt99]

Thanks for the replies.

Sincerely, much appreciated.

I did do some research prior to my post and yes, I2S was originally designed for trace circuits on PCB.

Like I said originally, I'm trying to educate myself on the various transfer protocols for digital transmission.

I have no personal experience\education or bias on what is "the" best method if there is such a thing.

As Emil Faber said, "Knowledge is Good. That's all I'm seeking.

Again, I do appreciate the responses and look to learn more.

You guys have helped a lot.

[Superdad]

On 3/31/2017 at 0:33 PM, plissken said:

Isn't I2S inherently, and specifically designed, for short haul PCB traces and the like? It's a chip to chip interface. 

 

Yes, that's why the right way to "transport" that signal externally between two boxes is with balanced differential lines--LVDS (low voltage differential signaling).  Of course that then requires driver/receiver chips at both ends.

 

And as we have pointed out before, almost nobody really does the clocking ideally--which would be for the DAC to send its master clock out to slave the source.  As it is presently, the source (say an external USB>I2S box) has to have really good clocks because those generally become the master (other than in DACs that asynchronously recheck everything anyway).

 

I have found one instance in which this is a good thing:  The Singxer SU-1 converter has much better clocks (the lovely ultra-low-phase-noise Crystek CCHD-575) than the Holo Spring DAC I am using, and only via the I2S connection do those good clocks take over as master.  The improvement is quite worthwhile.

 

But in the end we are all better off having the conversion from Ethernet or USB to I2S/DSD take place on an input board inside the DAC--again with the DAC's good clocks being the master.

 

Sorry if this is all off-topic to the microRendu's output.  John already covered that definitively just above.

[ted_b]

To the OP and others, it's "Holo" not "Halo".

 

The microRendu was a brand new USB implementation from the ground floor up, with the help of folks like John, Alex, Barrows, etc.  It includes several playback modes and makes networking your computer audio signal chain fairly simple.  If you want I2S then go the Signature Rendu route, or the SIngxer SU-1 (while still using the microRendu as the USB vehicle and NAA).  As Alex points out, the Su-1 gives you better clocking, which should improve over Holo's USB input.  I have done some A-B'ing this weekend (since I got the SU-1 firmware to do DSD512, albeit not with the microRendu right now) and the preliminary results are that the Singxer via I2S slightly improves on all sample and bit rates, including DSD512.  YMMV.

 

 

[miguelito]

On 3/30/2017 at 8:03 PM, Milt99 said:

why doesn't the MicroRendu have USB & I2S outputs?

You could ask why it doesn't have a AES or SPDIF output as well. 

 

A device is tailored to a configuration and a price point. Plus adding more options increases the device's complexity and possibly reduces the sound quality.

[Kirbyt]

Back up a sec...  is the firmware update to dsd512 for the su-1 available publicly? 

[ted_b]

No, as pointed out in numerous other postings, the firmware is in early beta, is not intended to work for anything but the Holo, and will be released when handshakes to other players (like Roon) get fixed.

[Kirbyt]

Thanks, I dunno how I managed to miss that whole thread on the matter... 

[Forehaven]

11 hours ago, ted_b said:

To the OP and others, it's "Holo" not "Halo".

 

The microRendu was a brand new USB implementation from the ground floor up, with the help of folks like John, Alex, Barrows, etc.  It includes several playback modes and makes networking your computer audio signal chain fairly simple.  If you want I2S then go the Signature Rendu route, or the SIngxer SU-1 (while still using the microRendu as the USB vehicle and NAA).  As Alex points out, the Su-1 gives you better clocking, which should improve over Holo's USB input.  I have done some A-B'ing this weekend (since I got the SU-1 firmware to do DSD512, albeit not with the microRendu right now) and the preliminary results are that the Singxer via I2S slightly improves on all sample and bit rates, including DSD512.  YMMV.

Awesome Ted!  Though a bit surprised at only "slightly improves".  I guess it shows we're doing a pretty decent job of cleaning up the USB signal.

11 hours ago, ted_b said:

 

 

[Milt99]

ted_b, yes Halo was a typo on my part. I tried to correct it but the edit timeout occurred before I noticed it.

I do well realize that almost all implementations contain compromises and design goals except when you get into the stratosphere of price and even then decisions are driven by design philosophy.

 

From my readings about various transport methods over the years, many experts extolled the virtues of I2S and

I greatly appreciate the clear explanations of the aspects and realities of this.

 

[ted_b]

16 minutes ago, Forehaven said:

Awesome Ted!  Though a bit surprised at only "slightly improves".  I guess it shows we're doing a pretty decent job of cleaning up the USB signal.

 

Chris,

My results are preliminary and involve some other things I'm doing.  Once I get the variables eliminated (except for USB vs I2S) I will be in a better place.  However, "slightly improved" is a good win, as we've done a hell of a lot to think we can ask for huge shifts in qualitative sq.  I am excited about "slightly". 

[davide256]

I suspect USB3 would be a far better hardware change for any generation 2 microrendu. i2s is a definite minority for hardware in market, even my inexpensive iFi Nano has a USB3 input

[JohnSwenson]

11 hours ago, davide256 said:

I suspect USB3 would be a far better hardware change for any generation 2 microrendu. i2s is a definite minority for hardware in market, even my inexpensive iFi Nano has a USB3 input

I'm not quite sure why USB3 would be any better. USB3 includes all the lower lower speeds in addition to super speed. The "old" high speed is fast enough to handle anything audio needs, so there is no need to use Super Speed. It actually makes many things worse. Anything about cables and such are much worse at super speed, the packet nature is even worse.

 

There are only really two advantages to USB3, super speed uses two unidirectional pairs, which makes isolation VASTLY easier, and USB3 supports more current over the VBUS, thus it can support a VBUS powered DAC which uses more than 0.5A.

 

No DACs yet use super speed so there is no advantage for any source to support super speed. In a DAC super speed USB devices use significantly more current than high speed devices, thus noise from the packets nature of USB audio will be much worse.

 

Now it turns out that the high speed section of some USB3 chips actually sounds better than some USB2 only chips, that is an implementation detail of the high speed circuitry in the USB3 chip rather than an inherent advantage of USB3.

 

BTW all USB3 chips have two completely separate sections, the super speed section and the everything else section. When you use such a chip in high speed mode the super speed section is turned off and the everything else section handles the high speed protocol.

 

John S.

 

 

[Forehaven]

Darn good point Ted.  We really have come a long way...better USB signal (Intona), Galv Isol. (MicroRendu), cleaner power (LPS-1) and of course, the fiber implementation.  Throw in the SU-1 to achieve a I2S...so I agree, I'll take 'slightly' now anyday

 

Great explanation John on USB 3 benefits/limitations.

[davide256]

8 hours ago, JohnSwenson said:

I'm not quite sure why USB3 would be any better. USB3 includes all the lower lower speeds in addition to super speed. The "old" high speed is fast enough to handle anything audio needs, so there is no need to use Super Speed. It actually makes many things worse. Anything about cables and such are much worse at super speed, the packet nature is even worse.

 

There are only really two advantages to USB3, super speed uses two unidirectional pairs, which makes isolation VASTLY easier, and USB3 supports more current over the VBUS, thus it can support a VBUS powered DAC which uses more than 0.5A.

 

No DACs yet use super speed so there is no advantage for any source to support super speed. In a DAC super speed USB devices use significantly more current than high speed devices, thus noise from the packets nature of USB audio will be much worse.

 

Now it turns out that the high speed section of some USB3 chips actually sounds better than some USB2 only chips, that is an implementation detail of the high speed circuitry in the USB3 chip rather than an inherent advantage of USB3.

 

BTW all USB3 chips have two completely separate sections, the super speed section and the everything else section. When you use such a chip in high speed mode the super speed section is turned off and the everything else section handles the high speed protocol.

 

John S.

 

 

In my former hat as a product manager I don't see a long market future for USB2 only devices. USB3 will continue to improve, no one will spend a dime on USB2 improvement.

[gstew]

Interesting thread!

John's explanation of why the MicroRendu doesn't do I2S output is clear (and John knows I know that story too!).

AND to feed the Holo DAC, you really need I2S over HDMI, PS Audio Format I believe.

Of course the Sonore Signature Rendu does that and does it well, so for the Holo, that is likely the current optimal solution.

BUT as far as an Ethernet input -> I2S output device, there is a huge opportunity for a device that would work at the MicroRendu / SMS200 level yet output I2S... as an alternative device for the Raspberry Pi as an NAA.

The Pi does a pretty fair job as an I2S source feeding commercial DAC HATS and for DIY applications. AND its low price point has spawned a number of specialized audio playback distros with options available for most any taste and usage. BUT it is still a low-budget ($50) device with hardware power and clocking limitations. Luckily, the Allo.com Kali I2S reclocker does wonders for the SQ out of the Pi-attached DACs.

What about a MicroRendu equivalent to the R-Pi? A good clock chip, good regulators, John Swenson-level design, with the only constraints of:

1. Using the same core processing, I/O, & memory devices to keep it hardware compatible with the existing R-Pi's and retain compatibiity with the variety of R-Pi audio playback distros.

2. Maintaining the physical interfaces (expansion header, USB / Ethernet / Audio / Monitor connectors, etc) and physical compatibiity to accommodate existing add-ons.

While I cannot see doing a device like this with the same footprint as the existing R-Pis (though the MicroRendu is amazingly small... someone like John may be able to pull this off), as long as the interfaces and interfacing is maintained, a larger board footprint could be accommodated.

HW-wise, I expect it would be roughly cost-comparible to the MicroRendu. BUT by maintaining compatibility with the wide variety of SW suites available for the Pi, the whole SW development and maintenance effort required for something like the MicroRendu is side-stepped.

AND to keep this on-topic, an I2S->LVDS I2S R-Pi HAT could make this work with DACs like the Holo.

John, Alex, Ted, others, thoughts?

Greg in Mississippi