Taiko Audio SGM Extreme : the Crème de la Crème
- Thread starter CKKeung
- Start date
Hi all, and sorry to seem coming out of the blue but, I see at the active pool that 17% of Extreme owners connect them to their DACs by Ethernet cable. I thought that TAS only enable USB connection to the DAC.
What have I missed?
Thank you.
What have I missed?
Thank you.
TAS can drive Ethernet DACs using the ASIO protocol, like Ravenna used by for example Merging DACS. The vast majority of Extreme owners use Roon, TAS is BETA software and is installed on a limited number of Extremes. Furthermore that poll dates back 2.5 years and is unlikely to be representative of actual usage today. Back then Ethernet was marketed to immunize DACs of source quality. I think it's safe to say that concept has been antiquated now.
Of course Emile, my bad. I just forgot that Roon existed in my life 3 years ago. Such a poor SQ. I didn’t even used it in my previous server as it was easily surpassed by MPD. After TAS there’s only moving forward in this direction.
I understand and agree that Ethernet isn’t any more a cure for servers faults, because my MSB Renderer v2 was also surpassed by recent USB implementations. But, now with TAS, will it have in the future UPnP or other similar protocol to bring the MSB Renderer, and others, into the game again?
As your signature notes "Afterdark Switch 2xBuffalo" you are clearly aware of ethernet not being "transparent"
Our stance is the additional overhead of the Ethernet protocol, netting to higher data rates and increased processing requirements in the endpoint, and the need for an operating system, with TCP/IP stack, which is not immune to network data unrelated to audio, increases data processing even more with all its associated noise, all inside your DAC, over interfaces like USB, AES/EBU / SPDIF / I2S etc. With USB you have other concerns but that has become easier to manage then Ethernet, often outperforming AES/EBU et al.
We could consider that, but I'm confident that Ethernet will always be behind other interfaces.
Thanks very much. I appreciate your thoughts.
For many years I was very fond of using USB, as this interface enables the full range of oversampling for example.
With Ethernet, I have indeed found that the devices with the lowest latencies (Solarflare), galvanic isolation and high-quality clocks (Afterdark Buffalo Switch) work best for me.
Without hijacking your thread my thoughts to NAA (Network Audio Adapter) from HQPlayer. My T+A SDV 3100 HV have integrated NAA from Signalyst and I guess some Extreme Owner have the T+A DAC. Jussi writes:
Source: https://www.signalyst.com/custom.html
Conclusion
As is so often the case, it depends on the interaction between the devices and the quality of the implementation. I think Taiko Audio is always at the forefront and that's why I'm reading here with great interest.
Yes quite a few, they do all prefer USB, but you could generate a plethora of theories as to why it would perform better in their case.
Ultimately all digital interfaces have their problems, one of them being the requirement to be universal. If you create a proprietary interface "doing a better job" you end up with a product incompatible with non compliant sources. MSB has done an admirable job there with their MSB Pro USB/ISL interface there, IMHO ofcourse.
For those who have a little to harsh / thin presentation when using TAS on extreme,
or prefer a touch more relaxed presentation.
In TAS in Server settings there is a NETWORK icon, once you select it you can change the network buffer that is by defult 3 seconds to a higher number.
This increases network buffer and makes miracles in my system.
The change from 3 to 4 is already a big step up. ( max is 30) .
Not sure if Emile plans to incorporate in final version of TAS ( this will have no logitech media sever part) a similar control over the network buffer.
That could give us a tool for fine adjustment in systems requreing more work ( like mnie)
to get perfect SQ from extreme.
or prefer a touch more relaxed presentation.
In TAS in Server settings there is a NETWORK icon, once you select it you can change the network buffer that is by defult 3 seconds to a higher number.
This increases network buffer and makes miracles in my system.
The change from 3 to 4 is already a big step up. ( max is 30) .
Not sure if Emile plans to incorporate in final version of TAS ( this will have no logitech media sever part) a similar control over the network buffer.
That could give us a tool for fine adjustment in systems requreing more work ( like mnie)
to get perfect SQ from extreme.
Looked for this and I couldn't find any network icon in server settings, just the word network. Under that the only buffering is radio station buffer which was set at 3. I tapped the three dots in the upper right corner and went to server settings. Am I looking in the right place?
I see a 3 second default value for the "radio station buffer". Does this impact streaming services like qobuz as well?
If this impacts streaming SQ, I'd imagine it (or something equivalent) will be kept in the TAS release.
It defines the delay in seconds for radio stations, it buffers 3 seconds of the radio stream before starting playback by default. This is to prevent dropouts when your internet connection is dodgy. It has no effect on Tidal/Qobuz or local file playback. However increasing the value will pre allocate a bit more memory, and although it will be unused it can have an effect on SQ, it would increase noise, but interestingly increasing noise can sometimes be perceived as sounding “better”. Controversially, a similar mechanism can be observed from various tweaks which in fact increase noise but can be perceived as increasing net sound quality.
I can’t see how it’s usb then network then usb and so on. to add to it at each turn we are told this is best and not look back.
at this price point I would think a few output methods should be available. same for usb cards used. for me network for non critical systems is the min standard. just saying.
at this price point I would think a few output methods should be available. same for usb cards used. for me network for non critical systems is the min standard. just saying.
You are free to pick your preferred interface. We offer the following 4:
1) USB
2) Networked, copper RJ45 and/or fiber SFP
3) AES/EBU, single and/or dual wire
4) SPDIF
It's great that you have so many choices. Might I suggest adding I2S as I find at least with my Aqua Formula via the LinQ I2S is easily noticeably better than USB which seems to be your focus.
Yes you can use them all with the exception of AES/EBU and SPDIF which are additional options to be purchased. Ethernet and USB are both available as standard options.
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.
Last edited:
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.
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.
