Taiko Audio SGM Extreme : the Crème de la Crème

Lojay said:

Hi Emile, kudos to you and your team for the achievement. May I just ask, will XDMS have support for wv files (which will be important for some PGGB file users)?

Click to expand...

heebrog said:

Hi Emile.

Are room correction convolution filters a possibility in XDMS?

If not, is HQP integration an option?

G

Click to expand...

Taiko Audio said:

XDMS update:

As we are receiving a significant volume of enquiries as to where we are at with TAS we have decided to post regular updates in this thread as all of the TAS BETA testers are following us here.

The TAS BETA and the XD direct and XD batch players are end of life, they are not going to be reused in the next generation of our playback software suite which is now named XDMS for Extreme Direct Media Server and XDMSPlayer for Extreme Direct Media Server Player, which have been rewritten from scratch.

Our internal designation is currently at ALPHA version 0.3. This will need to be at least at a BETA stage before we will start rolling it out to the current BETA tester group.

What we have accomplished so far:

First of all, it's important to note the fact that every single change in the code is being evaluated for impact on Sound Quality where the hard line of approval is set from NO negative impact to positive impact. This does increase the total project time as after each code change, it needs to be evaluated, and subsequently adjusted if not approved, after which it needs to be evaluated again, etc.

1) Currently XDMS sounds better then the TAS BETA. It has a fuller low end and midrange, more air on top, is cleaner, more transparent with blacker backgrounds, has better 3 dimensional imaging and better flow.
2) We have gapless playback.
3) We have track pause and resume.
4) Track start/stop is instantaneous for normal sized files, like redbook and regular high res, large DSD256 files or 4Gb PGGB files can have 1-2 seconds of delay before playback starts, but will play gapless after that initial delay.
5) Track progress bar manipulation (move to different parts of the track while playing) is currently disabled due to SQ degradation, needs further investigation on how to implement harmless signalling between server and player.
6) We have a functional interface and media files scanner, the scanner supports all characters. The interface has 2 single page menus (browsing mode select and options), and 3 views, (media browsing, playing queue and playing now).

We currently do not have a set date for XDMS BETA rollout, and the possibility exists we may skip BETA testing rounds to go straight for a final release rollout.

Click to expand...

wil said:

Just my 2cents: Does anyone really care about track bar manipulation? It just strikes me as Roon froufrou that has nothing to do with actually listening to music. I just hate to see the Taiko team bogged down in this kind of stuff. Granted, I may a minority of one!

Click to expand...

dminches said:

I do. It isn't the highest priority for me and I would be fine if the first release of XDMS didn't have it but I would like it to be there eventually.

Click to expand...

dminches said:

I do. It isn't the highest priority for me and I would be fine if the first release of XDMS didn't have it but I would like it to be there eventually.

Click to expand...

kswanson27 said:

Will XDMS have a simple album delete function? Sometimes I'll have two versions of an album, say one DSD and one redbook, and after listening I'll want to delete one. Currently I have to go to Roon, delete it there and run a scan in TAS which doesn't always work. There may be other ways but a simple delete button would be nice.

Click to expand...

dminches said:

It sounds like you want the ability to manage your library from within XDMS.

One feature I would like is for there to be one library view with the user deciding, on the fly, if they want to include or exclude local files and streaming files (from each of the streaming services).

Click to expand...

Taiko Audio said:

I2S is actually not a suitable format to transport over a distance, every mm of circuit tracing diminishes performance (increases jitter). This is the main reason SPDIF and AES/EBU came into existence. If we consider a CD transport, you have a I2S output, which is then converted to SPDIF or AES/EBU to transport it over a distance in case of a separate D/A converter, then converted back to I2S. This was sufficient for Redbook playback resolutions, companies like Pacific Micronics and later DCS then started to utilize dual AES/EBU to increase sampling rate capability by splitting over 2 interfaces to get 24/192 capability. In fact, iirc, in the days of Pacific Micronics the limit was 24/88.2 and they used dual wire to get to 24/176.4. DCS initially used dual AES/EBU to get to 24/192 with the Elgar which evolved to 24/384 in later models. All this effort was made to minimize I2S transmission path length. Now obviously you can create an interface which can actually transport I2S over a distance and walk away "clean", but there is no standard for that. So these "good performing" I2S interfaces are then in a proprietary format which means you cannot just hook up any transport with an I2S output to any DAC with an I2S input. The best direct I2S implementation I have seen is the PRO ISL interface from MSB, but you can only use that with a MSB source, be it a MSB transport or their USB Pro ISL interface. Bottom line there is no such thing as a standard I2S output which you can offer to drive any DAC which claims to have a direct I2S input and have good performance. If you want to read up on I2S and it's issues as an interface this is a good read: Study: Is I²S interface better for DACs than S/PDIF or USB?

Looking at it from a server based source aspect, it is in fact very easy to implement an I2S output, there are a plethora of microcontrollers available with both a PCIe interface and I2S outputs, this is what you use to provide an SPDIF or AES/EBU output by adding an I2S to AES/EBU or SPDIF interface to that controller. So you actually have a lower part count board to provide a direct I2S output, but, there is no standard defining the interface. You can even use a 40 EURO Raspberry Pi which can run an OS and playback software or network endpoint software and it has direct I2S outputs. Something like this you'll find in many streamers or as a networked input in a lot of DACs. A more advanced implementation would add an I2S reclocker as the I2S output of something like this would not be very clean and high in jitter specs.

Knowing how sensitive the I2S stream is, which directly feeds into your DAC, the questions becomes where you actually want to generate the I2S signal. Using a PCIe card interface as an example for a separate server source you end up with the following options:
1) PCIe -> I2S - DAC (using I2S as a transport medium between Source/DAC)
2) PCIe -> I2S - AES/EBU -> I2S -> DAC (using AES/EBU as a transport medium between Source/DAC)
3) PCIe -> Network -> I2S -> DAC (using TCP/IP networking as a transport medium between Source/DAC)
4) PCIe -> USB -> I2S -> DAC (using USB as a transport medium between Source/DAC)

1) Gives you the most direct path, but is VERY sensitive to the interface and has poor isolation.
2) Adds 2 format conversions but less sensitive to the interface and depending on implementation better isolation.
3) Adds an interface before the I2S signal is even generated but the overhead is much larger then the other, a larger DataStream, and it requires an Operating System + services to run on a computer inside your DAC.
4) Adds an interface before the I2S signal is even generated, larger overhead then AES/EBU, but lower overhead then networked, and a much lower processing footprint inside your DAC.

Option 1) will almost always have to include a "reclocker" in the DAC, with a FIFO buffer, which then needs a microcontroller or FPGA. So this will actually give you the following path: PCIe -> I2S -> I2S ->DAC. That makes any of these options needing a microcontroller or FPGA inside your DAC. In the end they are all compromises.

Click to expand...

Steve Williams said:

Man this thread has always been like my morning dose of a double espresso and lately I have found myself having withdrawal symptoms as the thread has gone quiet until the past few days

I find it exciting to read what Emile has in store for us. All good things come to he who waits. Have patience little grasshopper as the end of the tunnel is in sight

Click to expand...

Taiko Audio said:

There's a lot going on here, I should post more frequent updates

We're installing a new CNC machine right now which will allows us to do all of our CNC machining in house, up till now we've only done prototyping and all copper and panzerholz parts ourselves with external aluminium chassis parts outsourced.

View attachment 81759

View attachment 81760

View attachment 81761

Click to expand...

marty said:

Everybody likes new toys. Some of us buy audio gear. Others buy CNC machines - and those don't play anything!

Click to expand...

wil said:

Just my 2cents: Does anyone really care about track bar manipulation? It strikes me as Roon froufrou that has nothing to do with actually listening to music. I just hate to see the Taiko team bogged down in this kind of stuff. Granted, I may a minority of one!

Click to expand...