Interesting to note that within a fairly short amount of time several leading digital front end manufacturers have introduced new proprietary interconnection schemes:
WADAX Akasa Optical
Taiko XDMI (which appears to be supported by LampizatOr)
MSB ProISL
and now
dCS ACTUS
It will be interesting to see if market pressures drive this wave of innovation towards standardization, under the umbrella of something like AES67 or otherwise. If not, interoperability, and the ability to mix and match in digital audio could soon be a thing of the past.
Taiko is working with others than LampizatOr to use XDMI as the digital source to the DAC and MSB is working with other server companys than Taiko to adopt Pro-ISL.
Yes, all of them are trying to get others to legitimize their inventions. But encouraging others to support one’s proprietary IP is not the same as standardization. In this situation either the market remains fragmented or the solution from the company with the biggest market share usually wins (think Apple and, say, lightning) as opposed to creating a solution combining the best ideas from multiple players (such as USB-C).
In my humble opinion I dont think any of these proprietary connections will be so big that they will set a new standard and be adopted by the mass market. The future will tell
I agree, at least until the functionality they support trickles down to considerably higher volume segments of the market. So fragmentation and a lack of interoperability will be the likely status quo for the forseeable future.
I will be interested to hear why dCS didn’t think AES67 was a suitable standards platform for their next generation interconnect. They have historically been pro-standards, actively contributing to open standards with their own inventions. Presumably they feel it is lacking key functionality, it will be interesting to hear what.
When I can carve out the time, and I have no idea when this might be, I’ll be interested to read the claims of the manufacturers involved about what they feel is audibly deficient in existing/standard connection protocols and how they’ve addressed such shortcomings. In (post-streamer/ethernet) digital connections I see potential issues with data corruption (surely extremely unlikely), with jitter/timing, and with noise accompanying the digital signal. Am I missing anything?
I’m not sure how a proprietary solution might address these more effectively than a standard one… so I’m genuinely intrigued but also find myself approaching the topic with a surprising (to me!) degree of cynicism due to the history in the audiovisual world of abandoned wannabe standards, consequent obsolescence and a soupcon of vendor lock-in.
Off to poke around ACTUS as dCS have earned my custom and my trust…
I don’t know dCS’ perspective on this, but having looked at AES67 extensively in the past, the fundamental problem with it is that in order to (sonically) match a proprietary integrated solution like dCS, one would need to jump through many very complex hoops.
For example, just AES67 alone wouldn’t be enough, they’d need to implement AES70 for device signalling. And don’t even think about proper Clocking, you’d need to implement SyncE in combination with PTPv2 (and/or AVB/TSN) to even approach the level of clocking precision dCS implements.
Not impossible, but it doesn’t make sense for a single consumer system. AES67 only really makes sense for a complex distributed (and loosely-coupled) multi element professional system.
I personally am very pleased to see these new, proprietary optical connections. I’ve grown quite bored reading the endless Ethernet cable disputes, and am eager for some new entertainment…
Given the platform’s price point, we may not see as much debate, but I have no doubt some folks (especially those who can “hear” a difference between optical SFPs ) are up in arms about the “twisted-pair copper cables carrying a high-speed error-corrected asynchronous data stream.”
No, not Ethernet/TCP, although the description fits perfectly, I’m talking about ACTUS;
The ACTUS cable is made up of six twisted pairs of copper cable, carrying asynchronous & error corrected audio signals, control signals and a master clock signal sent via our patented dCS Tomix protocol.
Knowing audiophiles, some will even attempt to attach ferrite cores to the ACTUS cables and claim all manner of benefits
Jokes aside, spoke to the local reseller at the HK show today and apparently you can order custom length ACTUS cable runs, allegedly up to 100m length without loss or degradation so you could place the components apart eg the user interface module.
Hmmm, sounds a lot like Ethernet to me. It could be that a portion of Actus resembles ethernet, augmented by the Tomix clock lines which probably don’t.
(Haha, sorry, just saw you made that point a couple of posts up!)
Following on from the above, on the webinar David explained that the Actus interface consists of six twisted pairs:
One pair carries the 44.1kHz clock
One pair carries the 48kHz clock
Four pairs carry the audio, control and status signals
So the last part does indeed start to sound very similar to Ethernet. Interestingly the geometry of the socketry has been devised to keep the two sets of clock signals separately shielded from the audio & control lines:
David also mentioned that while the interface is proprietary dCS is open to licensing it, and will support third party cable manufacturers to whom they have already sent cable samples.
I am pretty sure some cable manufacturers will sell a set Varèse cables for 150.000 $ ( or more) but the sound quality will much better than dCS cables, of course…
) are up in arms about the “twisted-pair copper cables carrying a high-speed error-corrected asynchronous data stream.”
. Coincidentally or otherwise, thats the same as typical nominal maximum length for Ethernet CAT5/6 cables.