Introducing Olympus & Olympus I/O - A new perspective on modern music playback

For those who just started reading up on Olympus, Olympus I/O, and XDMI, please note that all information in this thread has been summarized in a single PDF document that can be downloaded from the Taiko Website.

https://taikoaudio.com/taiko-2020/taiko-audio-downloads

The document is frequently updated.

Scroll down to the 'XDMI, Olympus Music Server, Olympus I/O' section and click 'XDMI, Olympus, Olympus I/O Product Introduction & FAQ' to download the latest version.

Good morning WBF!​

We are introducing the culmination of close to 4 years of research and development. As a bona fide IT/tech nerd with a passion for music, I have always been intrigued by the potential of leveraging the most modern of technologies in order to create a better music playback experience. This, amongst others, led to the creation of our popular, perhaps even revolutionary, Extreme music server 5 years ago, which we have been steadily improving and updating with new technologies throughout its life cycle. Today I feel we can safely claim it's holding its ground against the onslaught of new server releases from other companies, and we are committed to keep improving it for years to come.

We are introducing a new server model called the Olympus. Hierarchically, it positions itself above the Extreme. It does provide quite a different music experience than the Extreme, or any other server I've heard, for that matter. Conventional audiophile descriptions such as sound staging, dynamics, color palette, etc, fall short to describe this difference. It does not sound digital or analog, I would be inclined to describe it as coming closer to the intended (or unintended) performance of the recording engineer.

Committed to keeping the Extreme as current as possible, we are introducing a second product called the Olympus I/O. This is an external upgrade to the Extreme containing a significant part of the Olympus technology, allowing it to come near, though not entirely at, Olympus performance levels. The Olympus I/O can even be added to the Olympus itself to elevate its performance even further, though not as dramatic an uplift as adding it to the Extreme. Consider it the proverbial "cherry on top".

 

I would use i2s if Emile designs a daughter card for the Olympus XDMI that is specific for the Horizon i2s since i2s is not standard. Then you would have all the advantages of transporting the signal from the Olympus processor to the output of the XDMI card, but not the advantages of the XDMI interface (that's why Emile talks about going with the handbrake on) since this requires a card XDMI on Server and DAC.

does i2s have the same limitations as aes/ebu wrt bit depth not going beyond 24/192 as well as no DSD or will i2s transmit everything native

 

Oh man, this is a lot to comprehend! With potential variations....

 

does i2s have the same limitations as aes/ebu wrt bit depth not going beyond 24/192 as well as no DSD or will i2s transmit everything native

No, i2s does not have those limitations but at distances even not very long it poses technical problems that Emile explained in a previous post. i2s is the interface between your USB receiver in the Horizon and the DAC chip in Horizon, it is designed for such short distances.

 

No, i2s does not have those limitations but at distances even not very long it poses technical problems that Emile explained in a previous post. i2s is the interface between your USB receiver in the Horizon and the DAC chip in Horizon, it is designed for such short distances.

I don't want to derail this thread too much... I2S was indeed designed for short distance digital signal transfer yet it can be used without issues on longer distances with proper care to the design.

 

does i2s have the same limitations as aes/ebu wrt bit depth not going beyond 24/192 as well as no DSD or will i2s transmit everything native

AES/EBU does not have the limitation of "no DSD". It will not transmit DSD natively however it will transmit a DSD stream intact using PCM frames. A PCM sample rate of 176.4 is sufficient for DSD64 via DoP. DoP does not "convert" DSD to PCM and back again.

So it is incorrect to say, "No DSD" with AES/EBU. Whether or not you choose to utilize DoP for DSD is up to you, your belief system and your DAC. Utilizing DACs designed by people intimately involved with the development of DSD and DoP (Playback Designs and dCS) I have never been aware of any sonic penalty from DoP.

Your mileage of course will vary.

Steve Z

 

I2S is less non standard than most seem to think, pin layout and connector (HDMI or RJ45) are not standardized and a few other specs (Emile mentioned those) may differ, yet manufacturers of DDC units handle this by using dipswitches. Surely this can be dealt with provided the volume is large enough, perhaps even in software rather than using the clumsy dip switches. The bigger issue is likely to get the DAC manufacturer to cooperate if the I2S output of XDMI differs from the format they chose (there might be valid reasons to do so).

I²S - Wikipedia

en.wikipedia.org

there indeed is no standard for I2S, yet from what I see there is sortof a consensus, perhaps you want to check with Pink Faun, they make an I2S output for various formats either using HDMI or RJ45 connectors
There are quite a few DAC's using the same principle, yet there may well be quite a few using some other output format...some DDC's use dipswitches to adapt, that may be a bit old school and can perhaps be handled with firmware/software?

The problem is that with the current implementations of I2S as soon as you use a cable (longer than 2 inches let's say) it becomes worse than a well implemented USB. There is only one high-end I2S PCIe card currently on the market that I am aware of, manufactured by PinkFaun that is using an outdated, unsupported, old chip that has a lot of limitations and underdeveloped driver that's incompatible with certain CPUs.
I've used that PinkFaun i2S bridge with their top ultraOCXO clock for years. Both (the clock and the card) were powered up by two separate top level linear power supplies. It gets you better than the average implemented USB. It did a very good job for me at the time. I was swearing that this is the best we can get out of digital.
This was also the time when my vinyl rig sounded way better than digital, and I would be in heaven if I found an extremely well recorded file that got me remotely close to my vinyl experience.
Nothing wrong with that pinkFaun solution, though - it has a very good performance for its price and is very enjoyable. What I did not realize at the time was that the top end of that performance spectrum ends way below what is being discuss here in this thread.
Let me clarify what I mean by that...

A well implemented USB like the Taiko USB card - Taiko USB driver - driven by XDMS-NSM to a JLSounds USB to I2S interface on the DAC, gets you much further than I2S. It's on a completely different level than the most you can squeeze out of the maxed out pinkFaun I2S implementation. And it's already better than my vinyl.

Taiko is pushing the boundaries well beyond that with XDMI, BPS, custom interface, custom firmware/drivers/software, and it seems like the new solution is much better than even the best implemented USB. Can't wait to hear that.

I don't expect XDMI to end on the Olympus server (or Olympus I/O) with a module to do I2S ( LVDS or similar ) over one of the commonly used cables such as HDMI or RJ45 ethernet. At least not in the traditional ways done today. That would ruin the entire concept. Manufacturers wanting to use I2S will have to use the newly developed I/O modules on the Olympus I/O to host XDMI inside the DAC. That won't be exactly cheap.
Or alternatively, Taiko will have to develop another interface to transparently transport the XDMI digital output to DACs (and a module for the DAC to convert to I2S) - no doubts that could happen.

In any way, IMHO the current I2S standards are irrelevant and outdated if you want to have top class digital experience (they were already outperformed by a well implemented USB). Even if Taiko did what pinkFaun did - create different I2S modules for different DACs, we will most likely find out that none of these DACs can compete with the and analog output of XDMI. And those I2S modules won't be very popular and probably a waste of time/money/resources. That's just an educated guess extrapolating from what I know about the new technology and my experience tweaking digital systems, since I have not listened to XDMI yet. In other words, I am making big assumptions, but I am convinced I am right . So convinced that I have placed my order for an Olympus XDMI.

 

My bet is on Lukasz. You got this. Very exciting. With a hint of progress toward compatibility with the Horizon via XDMI, I hope to order Olympus + XDMI to start. Can't imagine giving up everything the Horizon has to offer...

 

Come on Lukasz. You got this. Very exciting. With a hint of progress toward compatibility with the Horizon via XDMI, I hope to order Olympus + XDMI to start. Can't imagine giving up everything the Horizon has to offer...

Just a random thought for the Lampizator Horizon fans. I have a lot of respect for Lukasz! I've never had the chance to hear a Horizon in my system, but my guess is that it has an extraordinary tube-based analog section people love. A match in heaven for tube rollers....
I am a tube-gear fan myself, so it was unfortunate I've never had the opportunity to try a Horizon. But looking from the side here - have you guys considered using the XDMI analog output to a Lampizator Poseidon preamplifier instead? Get the best of both worlds type of thing...

 

does i2s have the same limitations as aes/ebu wrt bit depth not going beyond 24/192 as well as no DSD or will i2s transmit everything native

Hi Steve,

Let’s try to simply this as much as possible.

Let’s ignore music servers and go back in time to the era of CD players from where I2S, spdif, aes/ebu originate.

A CD player has a transport reading your CD.

This transport outputs a digital I2S datastream.

This digital I2S datastream feeds into a DAC chip.

The DAC chip converts the digital I2S datastream into an analogue waveform you can feed into your pre amplifier.

Now we are going to upgrade our CD Player to separate components, a CD transport and a DAC.

We then need a cable to connect the CD transport to the DAC.

This cable would need to conduct the I2S datastream from CD transport to DAC.

Now we run into a problem, I2S is very sensitive to jitter amongst others.

Sony and Philips develop the SPDIF interface being less sensitive, the SPDIF interface converts I2S to SPDIF in the CD transport, and then converts SPDIF back to I2S in the DAC. This ensures short I2S lines in both CD transport as DAC.

AES/EBU you can consider a balanced version of SPDIF, like unbalanced versus balanced (RCA versus XLR) interconnects.

So you could say SPDIF and AES/EBU only exist because it’s not that great of an idea to transport I2S over a distance, and that this is the reason they were created in the first place.

 

The problem is that with the current implementations of I2S as soon as you use a cable (longer than 2 inches let's say) it becomes worse than a well implemented USB. There is only one high-end I2S PCIe card currently on the market that I am aware of, manufactured by PinkFaun that is using an outdated, unsupported, old chip that has a lot of limitations and underdeveloped driver that's incompatible with certain CPUs.
I've used that PinkFaun i2S bridge with their top ultraOCXO clock for years. Both (the clock and the card) were powered up by two separate top level linear power supplies. It gets you better than the average implemented USB. It did a very good job for me at the time. I was swearing that this is the best we can get out of digital.
This was also the time when my vinyl rig sounded way better than digital, and I would be in heaven if I found an extremely well recorded file that got me remotely close to my vinyl experience.
Nothing wrong with that pinkFaun solution, though - it has a very good performance for its price and is very enjoyable. What I did not realize at the time was that the top end of that performance spectrum ends way below what is being discuss here in this thread.
Let me clarify what I mean by that...

A well implemented USB like the Taiko USB card - Taiko USB driver - driven by XDMS-NSM to a JLSounds USB to I2S interface on the DAC, gets you much further than I2S. It's on a completely different level than the most you can squeeze out of the maxed out pinkFaun I2S implementation. And it's already better than my vinyl.

Taiko is pushing the boundaries well beyond that with XDMI, BPS, custom interface, custom firmware/drivers/software, and it seems like the new solution is much better than even the best implemented USB. Can't wait to hear that.

I don't expect XDMI to end on the Olympus server with a module to do I2S ( LVDS or similar ) over one of the commonly used cables such as HDMI or RJ45 ethernet. At least not in the traditional ways done today. That would ruin the entire concept. Manufacturers wanting to use I2S will have to use the newly developed I/O modules on the Olympus I/O to host XDMI inside the DAC. That won't be exactly cheap.
Or alternatively, Taiko will have to develop another interface to transparently transport the XDMI digital output to DACs - no doubts that can happen.

In any way, IMHO the current I2S standards are irrelevant and outdated if you want to have top class digital experience (they were already outperformed by a well implemented USB). Even if Taiko did what pinkFaun did - create different I2S modules for different DACs, we will most likely find out that none of these DACs can compete with the and analog output of XDMI. And those I2S modules won't be very popular and probably a waste of time/money/resources. That's just an educated guess extrapolating from what I know about the new technology and my experience tweaking digital systems, since I have not listened to XDMI yet. In other words, I am making big assumptions, but I am convinced I am right . So convinced that I have placed my order for an Olympus XDMI.

Wow, thank you for sharing your knowledge. "so a well implemented USB like the Taiko USB card-Taiko Driver, Driven by XDMS-NSM to JL Sounds USB is hard to beat, I know I'm listening now. So in your opinion (and I realize this is only speculation) will AES/XDMI be many steps ahead in regards to improved Sound Quality vs the fore mentioned USB configuration? I also realize this is a difficult question to answer never hearing XDMI...If you don't render an opinion I certainly understand...You have a great way in explaining matters...

 

Now let’s forward to the era of music servers.

We need a new interface as SPDIF and AES/EBU have a bit/samplerate limit of 24/192.

The USB interface is modified to transport music data.

There are USB to I2S chips created which can be placed inside a DAC to convert USB data to I2S data.

So what we had before is:

source -> I2S -> SPDIF -> I2S -> DAC chip

now we have:

source -> USB -> I2S -> DAC chip

What is XDMI?

XDMI analogue = source -> I2S -> DAC chip
XDMI digital = source -> I2S -> SPDIF -> I2S -> DAC chip

 

Hi Steve,

Let’s try to simply this as much as possible.

Let’s ignore music servers and go back in time to the era of CD players from where I2S, spdif, aes/ebu originate.

A CD player has a transport reading your CD.

This transport outputs a digital I2S datastream.

This digital I2S datastream feeds into a DAC chip.

The DAC chip converts the digital I2S datastream into an analogue waveform you can feed into your pre amplifier.

Now we are going to upgrade our CD Player to separate components, a CD transport and a DAC.

We then need a cable to connect the CD transport to the DAC.

This cable would need to conduct the I2S datastream from CD transport to DAC.

Now we run into a problem, I2S is very sensitive to jitter amongst others.

Sony and Philips develop the SPDIF interface being less sensitive, the SPDIF interface converts I2S to SPDIF in the CD transport, and then converts SPDIF back to I2S in the DAC. This ensures short I2S lines in both CD transport as DAC.

AES/EBU you can consider a balanced version of SPDIF, like unbalanced versus balanced (RCA versus XLR) interconnects.

So you could say SPDIF and AES/EBU only exist because it’s not that great of an idea to transport I2S over a distance, and that this is the reason they were created in the first place.

SPDIF and AES/EBU were created to overcome the I2S limitations.

Then USB came in to digital audio to overcome the SPDIF and AES/EBU limitations.

Then I2S came back to overcome poorly implemented USB.

And then XDMI was born to take over...

 

SPDIF and AES/EBU were created to overcome the I2S limitations.

Then USB came in to digital audio to overcome the SPDIF and AES/EBU limitations.

Then I2S came back to overcome poorly implemented USB.

And then XDMI came to took over...

In a nutshell lol

 

Now let’s forward to the era of music servers.

We need a new interface as SPDIF and AES/EBU have a bit/samplerate limit of 24/192.

The USB interface is modified to transport music data.

There are USB to I2S chips created which can be placed inside a DAC to convert USB data to I2S data.

So what we had before is:

source -> I2S -> SPDIF -> I2S -> DAC chip

now we have:

source -> USB -> I2S -> DAC chip

What is XDMI?

XDMI analogue = source -> I2S -> DAC chip
XDMI digital = source -> I2S -> SPDIF -> I2S -> DAC chip

So what do we need:

A way to come as close as possible to this:

XDMI analogue = source -> I2S -> DAC chip

3 ways to achieve this:

1) place XDMI inside the external DAC
2) extend I2S, but it will be prone to the sensitivities described earlier
3) design something better to transport I2S over a distance

An example of 3) is MSB Pro ISL, there are more manufacturers who have designed proprietary I2S links, CH Precision for example. The problem with these is they are proprietary and only work with their own DACS and/or transports.

Ideally we create something like that which can utilise a small daughterboard to be placed in an external DAC as XDMI itself by now is not that small anymore, aka requires some space / real estate.

Aka this will all require some combined effort with a few willing DAC manufacturers, hence we are now launching XDMI with an analogue module, allowing you to hear it’s full potential, and a digital module with SPDIF and AES/EBU, which is supported by virtually any DAC, so you can use it with your own DAC brand, and still be able to hear a significant part of its capabilities.

 

[…] XDMI with an analogue module, allowing you to hear it’s full potential, and a digital module with SPDIF and AES/EBU, which is supported by virtually any DAC, so you can use it with your own DAC brand, and still be able to hear a significant part of its capabilities.

This is a little puzzling for me. Does this mean the digital processing prior to output of XDMI analog is superior to the somehow compromised processing for the forthcoming digital SPDIF and AES/EBU modules? (“full potential” vs. ”a significant part”) And is it correct to refer to those SPDIF and AES/EBU modules as XDMI?

 

This is a little puzzling for me. Does this mean the digital processing prior to output of XDMI analog is superior to the somehow compromised processing for the forthcoming digital SPDIF and AES/EBU modules? (“full potential” vs. ”a significant part”) And is it correct to refer to those SPDIF and AES/EBU modules as XDMI?

No that part is the same. The difference is that the resulting I2S signal directly feeds a DAC chip on the analogue module while on the digital module that same I2S signal is converted to SPDIF / AES/EBU, which is then converted back to I2S again inside your external DAC. So digital out has 2 more conversion steps then analogue out, but before that everything is the same.


XDMI analogue = source -> I2S -> DAC chip

XDMI digital = source -> I2S -> SPDIF or AES/EBU -> I2S -> DAC chip

To complete the picture:

USB = source -> USB -> I2S -> DAC chip

What does XDMI eliminate: USB

 

No that part is the same. The difference is that the resulting I2S signal directly feeds a DAC chip on the analogue module while on the digital module that same I2S signal is converted to SPDIF / AES/EBU, which is then converted back to I2S again inside your external DAC. So digital out has 2 more conversion steps then analogue out, but before that everything is the same.

Then if I understand correctly, while the 2 extra conversion steps may be perfectly lossless for the audio data, additional processing power would be required and therefore more noise generated. Is that the issue?

 

So what we had before is:
source -> I2S -> SPDIF -> I2S -> DAC chip

XDMI digital =
source -> I2S -> SPDIF -> I2S -> DAC chip

This seems to me to imply that if we are happy with 24/192 rate limitations (most of my music is 16/44 and I have no dsd), xdmi digital is basically the same as a well designed aes/ebu, both serving to transport the pdif signal.

The big difference in the future then is with Olympus having a better cpu, more cores to optimally distribute processes to, and a faster interface to the CPU....unless the xdmi internal card can further improve the aes/ebu output?

 

Then if I understand correctly, while the 2 extra conversion steps may be perfectly lossless for the audio data, additional processing power would be required and therefore more noise generated. Is that the issue?

No it does not require additional processing power, it just inserts 2 additional microprocessors in the digital signal path which are not noise free. But don’t place too much importance on that as the XDMI architecture advances are still all there.

 

This seems to me to imply that if we are happy with 24/192 rate limitations (most of my music is 16/44 and I have no dsd), xdmi digital is basically the same as a well designed aes/ebu, both serving to transport the pdif signal.

The big difference in the future then is with Olympus having a better cpu, more cores to optimally distribute processes to, and a faster interface to the CPU....unless the xdmi internal card can further improve the aes/ebu output?

There are plenty well designed AES/EBU cards available but they do not perform on the same level as XDMI. In fact they don’t even perform on the same level as our USB solution.