To DSD or not to DSD?

[sandyk]

Have to say that upconversion of old 16/44.1 CDs to DSD256/512 does wonders ... really wipes away any digital harshness and lets the crappy recordings through

 

So does carefully ripping them and playing them through a good DAC that upsamples all material to 24/192 LPCM, provided that you don't use USB with all of it's well documented problems without correction.

[jabbr]

So does carefully ripping them and playing them through a good DAC that upsamples all material to 24/192 LPCM, provided that you don't use USB with all of it's well documented problems without correction.

 

Lisa Randall prefers >20 Mhz DAC, so if she's my step-date I'm sticking with DSD.

[Paul R]

So does carefully ripping them and playing them through a good DAC that upsamples all material to 24/192 LPCM, provided that you don't use USB with all of it's well documented problems without correction.

 

I expect the Gordon Rankin and other well respected and top flight engineers / Dac designers will disagree with your opinion of USB. No matter how many times you present it as a fact.

[firedog]

The usual subjective koolaid, either you ears or gear aren't up to the task of hearing the magic.

One of the most famous and respected digital engineers in the industry, Mike Moffat, has nothing to do with DSD and believes it to be a dead end. For every opinion presented there are others proclaiming the exact opposite.

If you believe you know the true path to Valhalla, have fun, I'll spend my time buying and listening to music.

 

Sal, it's great you have your opinion. Other people think they hear more than subltle differences by manipulating the signal in certain ways, and both theory and measurement back up their position. I don't know if you have tried to do the kind of upsampling and filtering that they have, but it isn't necessary to belittle what they hear.

 

Mike Moffat is very respected. His opinion in only one of many, and is irrelevant in this discussion. Everyone can bring their favorite engineers and producers to the discussion. Proves nothing.

[Solstice380]

So my posting of the facts expressed by other reputable engineers puts a few cracks in your DSD foundation and you want me to go shut up and go away? The subject of DSD is far from a closed issue and will go on with or without me. This is a honest and open forum for the views on both sides of many subjects. Buck up my friend.

 

Apologies, I must have been in a bad mood ... Kinda' harsh response.

 

I should have put it more politely for you. Referencing "reputable engineers" is the least probable way to get any serious consideration. YOUR impressions I will always respect, but name dropping gets you nowhere and absolutely no credibility. That's the method of low information folks.

 

Of course the "To DSD or not to DSD" is a wide open topic. But as Paul says, it comes down to each persons experiences and preferences. We have a saying in the scientific community: 1% of things are absolute and the rest is personal preference - respect both!

 

Relying on reputable engineers that you read about ( you don't know, haven't met, probably haven't read any of their "peer reviewed" papers and not they just their marketing hype) drops the "opinion" directly to the bottom of the pile.

 

Live and let live. Just don't try to tell people they can't like what they do like, all of the time. Peace.

[sandyk]

I expect the Gordon Rankin and other well respected and top flight engineers / Dac designers will disagree with your opinion of USB. No matter how many times you present it as a fact.

 

My view about the shortcomings of USB for Audio is supported by the large numbers of CA members who have felt the need to address it's shortcomings by purchasing expensive aftermarket USB cables and devices such as USB to SPDIF converters, Uptone Audio USB Regen. Intona USB Isolator , external low noise +5V linear PSUs, Paul Pang USB cards, jCat USB cards etc.etc.

In many cases the amount spent on correcting USB shortcomings exceeds the monetary value of the computer itself !

[Solstice380]

In many cases the amount spent on correcting USB shortcomings exceeds the monetary value of the computer itself !

 

I hear you on that one. I also think that's why the use of quiet Linux NAAs and the market niche and expectation for the mRendu exist. ??? It seems the stuff associated with the implementation of USB is the big issue for audio. USB 2.0 can easily handle the bits transfer end of things. It's main function in the world, however, was not audio so the implementations were not designed for us.

[firedog]

I hear you on that one. I also think that's why the use of quiet Linux NAAs and the market niche and expectation for the mRendu exist. ??? It seems the stuff associated with the implementation of USB is the big issue for audio. USB 2.0 can easily handle the bits transfer end of things. It's main function in the world, however, was not audio so the implementations were not designed for us.

 

Part of the "solution" is designing and implementing better USB sources and receivers. DACs are now coming out that are made with thought given to the USB input instead of just plugging in an off the shelf computer component, as was common just a couple of years ago. Sources like the microRendu - which has the Regen type USB improvements built into the circuitry - will also become more common. In the end, it's like everything in audio: any technology can sound good or bad - it's the implementation that matters.

 

People who dismiss a device just b/c it uses "X" technology miss out on some good sounding equipment.

[Paul R]

My view about the shortcomings of USB for Audio is supported by the large numbers of CA members who have felt the need to address it's shortcomings by purchasing expensive aftermarket USB cables and devices such as USB to SPDIF converters, Uptone Audio USB Regen. Intona USB Isolator , external low noise +5V linear PSUs, Paul Pang USB cards, jCat USB cards etc.etc.

In many cases the amount spent on correcting USB shortcomings exceeds the monetary value of the computer itself !

 

Your personal religious crusade against USB not withstanding, I suspect there are far more audiophiles using USB than not. It actually is one of the best and the most versatile interface available. Both for playback and for recording.

[Paul R]

I hear you on that one. I also think that's why the use of quiet Linux NAAs and the market niche and expectation for the mRendu exist. ??? It seems the stuff associated with the implementation of USB is the big issue for audio. USB 2.0 can easily handle the bits transfer end of things. It's main function in the world, however, was not audio so the implementations were not designed for us.

 

And the USB Audio Specifications were designed with audio in mind. That may or may not have been a good thing, since USB Audio essentially has the worst features of S/PDIF transmissions. (I.e. Timing, or the lack thereof...) Still it works at least as well as S/PDIF over optical or coaxial cables, and can be designed to sound better and accept far more kinds of audio. DSD and DoP being two examples.

 

I do think that ethernet connected DACs, wireless most probably, will replace USB dacs in the next 5 years. Which is probably a good thing, since that can eliminate the timing issues. Also eliminates the need to be physically close to each other, sp streqming and VMs innthe cloud can be music servers with no sonic impact. A few software innovations in players are needed to makeit happen though.

[pipis2010]

Part of the "solution" is designing and implementing better USB sources and receivers. DACs are now coming out that are made with thought given to the USB input instead of just plugging in an off the shelf computer component, as was common just a couple of years ago. Sources like the microRendu - which has the Regen type USB improvements built into the circuitry - will also become more common. In the end, it's like everything in audio: any technology can sound good or bad - it's the implementation that matters.

 

People who dismiss a device just b/c it uses "X" technology miss out on some good sounding equipment.

 

+1, amen to that!!!

[jabbr]

My view about the shortcomings of USB for Audio is supported by the large numbers of CA members who have felt the need to address it's shortcomings by purchasing expensive aftermarket USB cables and devices such as USB to SPDIF converters, Uptone Audio USB Regen. Intona USB Isolator , external low noise +5V linear PSUs, Paul Pang USB cards, jCat USB cards etc.etc.

In many cases the amount spent on correcting USB shortcomings exceeds the monetary value of the computer itself !

 

USB is either very cheap or very very expensive. Hard to know what the causes are. It mystifies me why USB cables might have a "sound" but indeed many people report this, and many people hear benefits from the USB widgets, so yes.

 

This is perhaps an evolution, and as newer DACs with improved input isolation compete in the marketplace, I expect that DACs will improve input isolation in order to stay in the game.

[Superdad]

And the USB Audio Specifications were designed with audio in mind. That may or may not have been a good thing, since USB Audio essentially has the worst features of S/PDIF transmissions. (I.e. Timing, or the lack thereof...) Still it works at least as well as S/PDIF over optical or coaxial cables, and can be designed to sound better and accept far more kinds of audio. DSD and DoP being two examples.

 

I do think that ethernet connected DACs, wireless most probably, will replace USB dacs in the next 5 years. Which is probably a good thing, since that can eliminate the timing issues. Also eliminates the need to be physically close to each other, sp streqming and VMs innthe cloud can be music servers with no sonic impact. A few software innovations in players are needed to makeit happen though.

 

Hi Paul:

 

Hard for me to agree with you on the point I put in bold above. S/PDIF's embedding of the clock in the data (yuck!) is among its worst flaws (along with the awful transmit and receive chips, PLLs, and sensitivity to impedance match and being prone to reflections). The packet-based USB system with an asynchronous implementation allows for (at least in fully-realized DACs) the master clocks to be the sole audio clocks. Even the popular USB>I2S input boards that DAC makers frequently punt with can have good clocks right there.

 

In the world of computer audio, S/PDIF is just another vestigial--and ugly--layer of conversion back and forth just to get an I2S/DSD signal to reclock. For grins, here is a thread I started on How to Banish S/PDIF Entirely over 11 years ago. To me, those who prefer using USB>S/PDIF converters are just admitting that their DAC's USB input was done so poorly as to allow an entire S/PDIF generate/receive chain to outperform it.

 

With regards Ethernet-connected DACs:

I too would like to see them take over (for both convenience and potential isolation reasons), but I don't think it will happen until there is truly open, multi-platform "virtual sound card" software--allowing any OS and player app to "see" the Ethernet-attached DAC. [i follow this area closely, and AES67/Ravenna could have that potential if both ALC Network and Merging would give away Ravenna Virtual Sound Card (for Windows and OSX CoreAudio respectively) along with the APIs for hardware developers to use.]

Until then, I think the closest we will get to "Ethernet" DACs will be with various CPU-based "renderers" and the range of server/control/rendering schemes available (DLNA, NAA, LMS, AirPlay, RoonReady, etc.). [bTW, the forthcoming Sonore microRendu makes all of those quite easy with well-tested s/w and a superior USB implementation--but it is still USB out to a DAC's USB input.]

 

Yes, some DAC developers are (and have been for a long while--Linn, Auralic, etc.) diving in and putting small computers into their DAC's, but to-date this means taking on a level of customer support that goes well beyond just selling a DAC that someone hooks up and can expect to be easy and trouble-free. Charlie Hansen relayed to me a story from a ex-Linn engineer friend of his who said they went from having 28 h/w engineers and 3 s/w engineers to having 5 hardware guys and 30 doing software (exact numbers unknown, but the gist is correct and he told it to me as part of a conversation about not wanting to have to become a software and support firm just to add an Ethernet input to their DACs).

 

So for now the only universally plug-and-play, and most direct, computer audio link that works on all platforms--and with ALL software--is still USB.

 

I realize that none of the above is telling anyone here anything they don't already know. I just get spun up when there is talk of going back to S/PDIF (more of that on Head-Fi than here). And sometimes people think that adding Ethernet input to a DAC is just a trivial matter--as easy as adding USB. We can be thankful that UAC2 (and ASIO) exists on/in most all computers and operating systems. But we have yet to arrive to the day when such ease exists for audio over Ethernet.

 

--Alex C.

[sandyk]

Hi Alex C.

You know that I fully support what John Swenson and yourself are doing, but by the time you factor in your JS2 Linear PSU, a decent aftermarket USB cable or 2 , your USB Regen AND your soon to be released very high quality mains isolated PSU to power it , or perhaps an Intona Isolator to get the best sound quality via USB from a Mac Mini , makes it a very expensive proposition when a decent internal soundcard via Coax SPDIF into a good DAC when playing from System Memory using A.S.I.O. can still equal or outperform it in many cases.

Even then, the USB Input implementation in the DAC is still likely to be the limiting factor, although this is slowly changing, mainly due to the ground breaking research by yourself and John.

Kind Regards

Alex

[Miska]

With regards Ethernet-connected DACs:

I too would like to see them take over (for both convenience and potential isolation reasons), but I don't think it will happen until there is truly open, multi-platform "virtual sound card" software--allowing any OS and player app to "see" the Ethernet-attached DAC. [i follow this area closely, and AES67/Ravenna could have that potential if both ALC Network and Merging would give away Ravenna Virtual Sound Card (for Windows and OSX CoreAudio respectively) along with the APIs for hardware developers to use.]

 

In my opinion, there is no single protocol that would suit all the use cases, and no need to. AES67/Ravenna suits pro-audio, but is overcomplex and tricky for plain playback.

 

USB Audio Class and USB itself is far from perfect too. If someone would make USB host adapter that can do USB Audio Class straight, it would be better. Now you need to burn CPU cycles creating USB audio packets and dealing with the asynchronous isochronous packets scheduling stuff (which different OS implement in different ways). USB bulk mode transfers are nicer in that sense, simpler and have better hardware offload support.

 

Now bunch of pro-audio companies are going to Thunderbolt which allows fast, light weight transfers up to 40 Gbps speeds now available on USB 3.1 Type-C connector...

[Paul R]

Hi Paul:

 

Hard for me to agree with you on the point I put in bold above. USB Audio essentially has the worst features of S/PDIF transmissions. (I.e. Timing, or the lack thereof...)

 

Believe it or not, we are essentially saying the same thing here. USB Audio is, like S/PDIF, is very sensitive to timing and has no provision for error correction.

 

However, if the DAC and the computer talked in bulk data transfer mode, none of that would be a problem.

 

 

In the world of computer audio, S/PDIF is just another vestigial--and ugly--layer of conversion back and forth just to get an I2S/DSD signal to reclock. For grins, here is a thread I started on How to Banish S/PDIF Entirely over 11 years ago. To me, those who prefer using USB>S/PDIF converters are just admitting that their DAC's USB input was done so poorly as to allow an entire S/PDIF generate/receive chain to outperform it.

 

With regards Ethernet-connected DACs:

I too would like to see them take over (for both convenience and potential isolation reasons), but I don't think it will happen until there is truly open, multi-platform "virtual sound card" software--allowing any OS and player app to "see" the Ethernet-attached DAC. [i follow this area closely, and AES67/Ravenna could have that potential if both ALC Network and Merging would give away Ravenna Virtual Sound Card (for Windows and OSX CoreAudio respectively) along with the APIs for hardware developers to use.]

 

To be honest, I don't want a "virtual" sound card, I want the DAC to get the data, and then accept control signals about what to do with it. Seriously, the computing power in a DAC is not far off from doing exactly that. Ethernet connected DACs generally do that today, though some depend upon the RTP and RTSP protocols.

 

Until then, I think the closest we will get to "Ethernet" DACs will be with various CPU-based "renderers" and the range of server/control/rendering schemes available (DLNA, NAA, LMS, AirPlay, RoonReady, etc.). [bTW, the forthcoming Sonore microRendu makes all of those quite easy with well-tested s/w and a superior USB implementation--but it is still USB out to a DAC's USB input.]

 

Yes, some DAC developers are (and have been for a long while--Linn, Auralic, etc.) diving in and putting small computers into their DAC's, but to-date this means taking on a level of customer support that goes well beyond just selling a DAC that someone hooks up and can expect to be easy and trouble-free. Charlie Hansen relayed to me a story from a ex-Linn engineer friend of his who said they went from having 28 h/w engineers and 3 s/w engineers to having 5 hardware guys and 30 doing software (exact numbers unknown, but the gist is correct and he told it to me as part of a conversation about not wanting to have to become a software and support firm just to add an Ethernet input to their DACs).

 

So for now the only universally plug-and-play, and most direct, computer audio link that works on all platforms--and with ALL software--is still USB.

 

I realize that none of the above is telling anyone here anything they don't already know. I just get spun up when there is talk of going back to S/PDIF (more of that on Head-Fi than here). And sometimes people think that adding Ethernet input to a DAC is just a trivial matter--as easy as adding USB. We can be thankful that UAC2 (and ASIO) exists on/in most all computers and operating systems. But we have yet to arrive to the day when such ease exists for audio over Ethernet.

 

--Alex C.

 

 

Yep - we dure do live in interesting times don't we?

[Superdad]

In my opinion, there is no single protocol that would suit all the use cases, and no need to. AES67/Ravenna suits pro-audio, but is overcomplex and tricky for plain playback.

 

I agree, and so does my partner John as he has looked deeply into the spec and the whole AES67 clocking scheme really is more appropriate for sync large numbers of devices.

 

But like you we are not fond of DLNA, etc. Of course with the NAA you just went ahead and created your own protocol--but you have not opened it in way that it could either become part of all major OS platforms or licensed for other players and DACs to support directly with drivers/APIs/whatever.

 

Of course things are beginning to change with VERY commendable approach that ROON is taking--both with their architecture and their open partnership program. Their RAAT seems like a more open form of NAA, AirPlay, etc. (And being that I am a BIG fan of HQ Player, it is delightful to see that their system is open enough to allow DSP engines to squeeze into ROON systems.)

 

 

USB Audio Class and USB itself is far from perfect too. If someone would make USB host adapter that can do USB Audio Class straight, it would be better. Now you need to burn CPU cycles creating USB audio packets and dealing with the asynchronous isochronous packets scheduling stuff (which different OS implement in different ways). USB bulk mode transfers are nicer in that sense, simpler and have better hardware offload support.

 

Sure, but bulk mode, while it includes error correction has its downsides as well. Latency and system loading sensitivity being primary. And bulk mode can be finicky in other ways as well. Just ask M2Tech. Didn't they start off with all their DACs and DDCs using bulk mode and switch over in the past year?

 

I can't say much, but John is working on other, 100% original hardware means to address USB shortcomings in a way that might eliminate all the upstream sensitivity once and for all. We'll see. And aspects of that could also be applied to our long back-burnered http://www.computeraudiophile.com/f27-uptone-audio-sponsored/uptone-swenson-universal-serial-bus-industry-standard-cables-connectors-and-communications-protocols-between-computers-and-electronic-devices-ethernet-audio-bridge-22849/ project--if we ever return to it.

 

 

Now bunch of pro-audio companies are going to Thunderbolt which allows fast, light weight transfers up to 40 Gbps speeds now available on USB 3.1 Type-C connector...

 

I am interested in learning about those. Can you provide some links? I am confused though: is it Thunderbolt or USB 3.1?

 

Regards,

--Alex C.

[Superdad]

To be honest, I don't want a "virtual" sound card, I want the DAC to get the data, and then accept control signals about what to do with it. Seriously, the computing power in a DAC is not far off from doing exactly that. Ethernet connected DACs generally do that today, though some depend upon the RTP and RTSP protocols.

 

I agree. All those protocols are far more than what is desired, though if one wants to have a computer find a DAC on a network through a switch, then some of those layers need to stay in place.

 

My main points were that:

a) we all want universal compatibility to use whatever player s/w we wish--and on whatever OS platform;

b) it would be really good if DAC manufacturers could easily and inexpensively incorporate Ethernet renderer modules as a choice of DAC input. Not that it can't be done now--just that it is neither easy nor inexpensive--and DLNA renderers just don't "make my socks go up and down." (a favorite expression of my wife's)

[jabbr]

I agree. All those protocols are far more than what is desired, though if one wants to have a computer find a DAC on a network through a switch, then some of those layers need to stay in place.

 

My main points were that:

a) we all want universal compatibility to use whatever player s/w we wish--and on whatever OS platform;

b) it would be really good if DAC manufacturers could easily and inexpensively incorporate Ethernet renderer modules as a choice of DAC input. Not that it can't be done now--just that it is neither easy nor inexpensive--and DLNA renderers just don't "make my socks go up and down." (a favorite expression of my wife's)

 

Agreed. From a technical perspective Ethernet is probably overall the best choice : AES/Ravenna is an application layered on Ethernet, as is HQPlayer/NAA as is (choke) DLNA, and is supported by a multitude of hardware boards/modules including open source.

 

I haven't been that impressed with Thunderbolt adoption although it is gaining support in the video community and I am sure that is what us driving adoption in the pro audio space -- do we really need >10gbs for audio??? But USB just isn't used too often in pro video and Thunderbolt has captured the mindset of FireWire ...

 

In an ideal world the NAA protocol would be open.

[Miska]

do we really need >10gbs for audio???

 

It is not about speed alone, but about efficiency. It is not unusual for studio to have 128 audio channels. If you want 128 channels at DSD256 (~1.4 Gbps) without spending notable CPU cycles on plain transfer, you are going to need a bit of bandwidth and proper DMA capabilities.

 

Thunderbolt is nice, because it is pretty much PCIexpress on a neat wire.

[Miska]

But like you we are not fond of DLNA, etc. Of course with the NAA you just went ahead and created your own protocol--but you have not opened it in way that it could either become part of all major OS platforms or licensed for other players and DACs to support directly with drivers/APIs/whatever.

 

Yes, because NAA is not licensed independently from HQPlayer. I thought that it would be best model not to ask money for each NAA separately but instead include it in HQPlayer license.

 

Of course things are beginning to change with VERY commendable approach that ROON is taking--both with their architecture and their open partnership program. Their RAAT seems like a more open form of NAA, AirPlay, etc. (And being that I am a BIG fan of HQ Player, it is delightful to see that their system is open enough to allow DSP engines to squeeze into ROON systems.)

 

I don't see how the licensing/whatever approach of RAAT would be different from NAA? Or can you use RAAT from some other piece of software than Roon?

 

Sure, but bulk mode, while it includes error correction has its downsides as well. Latency and system loading sensitivity being primary. And bulk mode can be finicky in other ways as well. Just ask M2Tech. Didn't they start off with all their DACs and DDCs using bulk mode and switch over in the past year?

 

M2Tech HiFace (1) is still one of the best interfaces and works like charm. Just give it's own USB bus. For the sake of comparison, compare the amount of code in UAC2 Linux driver vs HiFace Linux driver. System load is much smaller than UAC can do due to better DMA support. Latency is not an issue for music playback.

 

Now it's just yet-another-XMOS thing.

 

I am interested in learning about those. Can you provide some links? I am confused though: is it Thunderbolt or USB 3.1?

 

Both, on the same connector. See:

https://en.wikipedia.org/wiki/Thunderbolt_(interface)#Thunderbolt_3

https://en.wikipedia.org/wiki/USB_Type-C#Alternate_mode_partner_specifications

 

My Win10 machine main board has two of those:

GIGABYTE - Motherboard - Socket 1151 - GA-Z170X-UD5 TH (rev. 1.0)

[jabbr]

It is not about speed alone, but about efficiency. It is not unusual for studio to have 128 audio channels. If you want 128 channels at DSD256 (~1.4 Gbps) without spending notable CPU cycles on plain transfer, you are going to need a bit of bandwidth and proper DMA capabilities.

 

Thunderbolt is nice, because it is pretty much PCIexpress on a neat wire.

 

Yes but Xeon E5 has Intel's DDIO (NIC <-> cache) and ARM Axi/Amba so the network doesn't need to pass through the PCIe interface i.e. same efficiency -- flip side is that we don't necessarily want to require the DAC to implement PCIe...

[Miska]

Yes but Xeon E5 has Intel's DDIO (NIC <-> cache) and ARM Axi/Amba so the network doesn't need to pass through the PCIe interface i.e. same efficiency -- flip side is that we don't necessarily want to require the DAC to implement PCIe...

 

Cores and Xeons have number of PCIe lanes built-in. With PCIe you can get full scatter-gather busmaster-DMA support where the audio interface reads all samples straight from the main RAM by itself. You don't have any software touching or copying the data between the player application and final audio hardware... That's what you've got with internal sound cards since the early days. Then USB arrived and screwed up the model...

 

With ethernet, if you have good networking hardware that has full hardware offload (zero-copy networking), you can reach almost the same to much longer distances and distributed architecture. But the complexity is of course much higher.

[Superdad]

Yes, because NAA is not licensed independently from HQPlayer. I thought that it would be best model not to ask money for each NAA separately but instead include it in HQPlayer license.

 

I understand. My point (gently) was just that NAA is tied to HQ Player and not usable by other player s/w. If it was fully open then you might have a bunch of hardware licensees embedding into their DACs and devices.

 

 

I don't see how the licensing/whatever approach of RAAT would be different from NAA? Or can you use RAAT from some other piece of software than Roon?

 

You are right. RAAT is for Roon. But no offense, Roon has a UI (and other multi-device support) that HQ Player does not offer.

Not that I would ever suggest you even try to compete with Roon library management (look at the nightmare Damien went through building the A+ 2.x library management system as a one-person developer). It should be no secret, nor any shame, that 90%+ of HQP users love it for your wonderful SRC and SDM algorithms--and not for its interface.

 

 

M2Tech HiFace (1) is still one of the best interfaces and works like charm.

 

Until the OS changes and then it breaks...

 

 

Both, on the same connector. See:

https://en.wikipedia.org/wiki/Thunderbolt_(interface)#Thunderbolt_3

https://en.wikipedia.org/wiki/USB_Type-C#Alternate_mode_partner_specifications

 

My Win10 machine main board has two of those:

GIGABYTE - Motherboard - Socket 1151 - GA-Z170X-UD5 TH (rev. 1.0)

 

Thanks for the links!

 

AJC

[jabbr]

Cores and Xeons have number of PCIe lanes built-in. With PCIe you can get full scatter-gather busmaster-DMA support where the audio interface reads all samples straight from the main RAM by itself. You don't have any software touching or copying the data between the player application and final audio hardware... That's what you've got with internal sound cards since the early days. Then USB arrived and screwed up the model...

 

With ethernet, if you have good networking hardware that has full hardware offload (zero-copy networking), you can reach almost the same to much longer distances and distributed architecture. But the complexity is of course much higher.

 

The complexity is in compatibility! Are the Firewire DSD interfaces standardized? I assume Thunderbolt would use Firewire protocols for PCM (jack). Hopefully each DSD DAC won't want its own driver? Or are we back to DoP?