Jump to content
  • The Computer Audiophile
    The Computer Audiophile

    A Conversation About Network Audio, AES67, Ravenna, and Merging Technologies

    At the Munich High End show this year, I talked to Merging Technologies' Dominique Brulhart about network audio, AES67, Ravenna, and many other items. Needless to say, I learned quite a bit and was really impressed by what is happening in this area of HiFi. After our conversation I asked Dominique if he would be willing to help educate the CA Community on all of this stuff. Dom was 100% on-board and agreed that we didn't even have to discuss Merging Technologies products, as long as we could educate the community. 

     

    Thus, last week I (virtually) sat down with Dominique via Skype and we talked about all things network audio. I couldn't resist asking some questions about the new Merging Technologies ZMan module and a few other items that I thought were too cool to pass up. 

     

     

    Here is the recording of our conversation.

     

    Links:

    AES67

    Ravenna

    Merging Technologies
     

     

     

     




    User Feedback

    Recommended Comments



    1 minute ago, rickca said:

    You're out of date.  He's already rated something at 500+.

    Right you are.  That was the secret one he is withholding details of from us.

     

    I wonder how you can characterize the sound difference between 40 and 500?

    Share this comment


    Link to comment
    Share on other sites

    9 hours ago, rb2013 said:

    Yes I did - and you did the interview - yet seem to to have a deep lack of understanding of AES67 judging from your posts.  I see why you are 1 yr late to the game.  And you call this 'Computer Audiophile' - shame on you 

    Wow. 

     

    I said Ravenna is far better than standard AES67. If that shows a deep lack of understanding, I don't want to understand. 

     

    1 year late to the game? I've been talking Ravenna since I first heard it in a Merging component in 2011 - https://www.computeraudiophile.com/forums/topic/4937-merging-technologies-mykerinos/#comment-77816

     

    Share this comment


    Link to comment
    Share on other sites

    Ravenna is not specific for Merging but the Z-Man  is. In his discussion Dominique Brulhart was mostly explaining all the possibilities of Ravenna and said this is the main reason for using Ravenna. He also stated that theoretically all ways to send digital data should/could give equivalent results. I am not quite understanding this. Gordon Rankin explains “To summarise: the problem with USB Audio is that Isosynchronous USB frames are not error correcting. Therefore the sonic outcome of any USB system is dependent on the host to device differential.” http://www.digitalaudioreview.net/2016/05/gordon-rankin-on-why-usb-audio-quality-varies/

    When I was talking to Merging at this years HighEnd they stated that the Ravenna protocol provides error correction and thus would have a higher sound quality potential.

    Share this comment


    Link to comment
    Share on other sites

    19 hours ago, jabbr said:

    Actually the Zynq chip has an integrated ARM & FPGA... I've been working with this device also, and agree that its ideal as Ethernet interface. The chip runs Linux and communicates with the FPGA by on die AXI channels. On thing that's trivial is to use the ARMHF build of @Miska's NAA (networkaudiod).

     

    I don't have experience with Xilinx Zynq (or much of any Xilinx, because I've always used Altera instead). But I do have experience running Linux on Altera Cyclone V SoC. It would run the same networkaudiod binary just fine.

     

    19 hours ago, jabbr said:

    In any case my approach is to create an ALSA driver for the AXI DSD interface ... which I'm slowly trying to figure out ... painful for me because all the samples that aren't USB are for PCM only :( 

     

    Botic driver can output DSD up to DSD512 from BeagleBone Black (pins, not USB), no FPGA needed. The programmable audio serial interface on the TI SoC is clever enough. Maybe you could take a look at it?

     

    19 hours ago, Superdad said:

    However, NAA, Roon RAAT, etc. are closed in their own ways (even if they might prove to sound better--for unknown reasons--than the Ravenna/AES67 stack and VSC).

     

    I don't like the VSC approach because it would then be again constrained by the idiosyncrasies of the OS audio architecture and the driver stack. Like lack of DSD support in macOS and such. By using NAA protocol between HQPlayer and the DAC I can do anything I want, precisely in a way I want, whenever I want. Not being restricted by someone else.

     

    networkaudiod currently supports ALSA, CoreAudio, WASAPI and ASIO backends, but I can easily add more or create completely custom ones.

     

    This method also allows avoiding double layers, like for example annoyances that would emerge by combining ASIO + CoreAudio (local/remote).

     

    Share this comment


    Link to comment
    Share on other sites

    3 hours ago, Miska said:

    I don't like the VSC approach because it would then be again constrained by the idiosyncrasies of the OS audio architecture and the driver stack. Like lack of DSD support in macOS and such. By using NAA protocol between HQPlayer and the DAC I can do anything I want, precisely in a way I want, whenever I want. Not being restricted by someone else.

     

    networkaudiod currently supports ALSA, CoreAudio, WASAPI and ASIO backends, but I can easily add more or create completely custom ones.

     

    This method also allows avoiding double layers, like for example annoyances that would emerge by combining ASIO + CoreAudio (local/remote).

     

    Hi Jussi:

    Thanks for jumping in.  I readily acknowledged that I do not have an engineer's understanding of this stuff.  But I do have an understanding of product appeal--both from the user and the DAC designer sides--and barriers to such.

     

    Your NAA/networkaudiod is no doubt small enough and flexible enough to run on many SoM offerings--which could readily be incorporated as the Ethernet input component of new/old DAC designs.

     

    But until you tell us otherwise, it is my understanding that usage of NAA is dependent upon user licensing and use of HQ Player Desktop.  And that with the notable exception of the integration you have offered with Roon (plus some noble scripting efforts by Geoffrey Armstrong for iTunes)--both of which require an HQP license--it is not possible for any desktop OS to simply send audio to an NAA device as if it was a directly attached "sound card."

     

    That limitation--the fact that a user can not just play YouTube, or iTunes, Windows Media Center, or JRiver, or Foobar, etc. to a DAC on the network--is THE thing holding the market back.  I suppose that if you offered OEM licenses to both NAA (maybe you do and that is what you call HQPlayer Embedded?) for the DAC side module AND a version of HQP Desktop that was a pipeline that any music player app would stream through and out to the NAA, then that would have appeal for DAC makers and users.

     

    I do recall that you have explained the performance limitations of such an approach and how it would compromise your HQP>NAA architecture.  But the lack of that sort of solution is the sole reason why the market window is wide open for Merging to step in with their VSC>Zman offering.  

    Regardless of whether or not it will technically offer the best sonic performance for purist audio, it will (given reasonable module costs and s/w licensing--plus ongoing upkeep of the VSC s/w as popular operating systems change) result in more rapid adoption by DAC manufacturers and the public.

     

    I'll close with a somewhat opposite yet obvious example, one that is very illustrative of market forces at play both for developers and end users:

    ROON.  There you have a desirable piece of somewhat pricey s/w with a great player experience (sorry, I'm an HQ Player devotee for your filters not for your UI).  Roon put together both their RoonReady partner program and the RAAT protocol, and audio manufacturers large and small flocked to it.  In fact, Roon garnered far more consumer market support in 18 months than AES67/Ravenna has in all its years.

     

    It has never been a secret that this is an area of great interest for me (has been for a dozen years; Chris and I met for the first time in 2005 when I was at Hovland trying to bring out an Ethernet DAC/CDP based on CompuLab module and John was trying to make netJack work for it).  

    So I hope this discussion will continue and that many will point out and explain where I am entirely wrong.  But I want to hear about the avenues and alternatives to go forward.  I think the jury is still out as to whether Merging's Ravenna>VSC>Zman is going to be open enough to achieve hegemony in the audiophile market.

     

    --Alex C.

     

     

    Share this comment


    Link to comment
    Share on other sites

    4 hours ago, Miska said:

     

    I don't have experience with Xilinx Zynq (or much of any Xilinx, because I've always used Altera instead). But I do have experience running Linux on Altera Cyclone V SoC. It would run the same networkaudiod binary just fine.

     

    Yes I presume, I think this is the general architecture of the type of ARM <-> FPGA I am discussing.

    4 hours ago, Miska said:

     

     

    Botic driver can output DSD up to DSD512 from BeagleBone Black (pins, not USB), no FPGA needed. The programmable audio serial interface on the TI SoC is clever enough. Maybe you could take a look at it?

     

    Thanks! Will do. This is an educational experience for me. FPGA is not strictly needed. We will see if there are actual benefits ;) At the very least I will have written an ALSA driver as well as an IP module or two for an FPGA :)

     

     

    4 hours ago, Miska said:

     

     

    I don't like the VSC approach because it would then be again constrained by the idiosyncrasies of the OS audio architecture and the driver stack. Like lack of DSD support in macOS and such. By using NAA protocol between HQPlayer and the DAC I can do anything I want, precisely in a way I want, whenever I want. Not being restricted by someone else.

     

    networkaudiod currently supports ALSA, CoreAudio, WASAPI and ASIO backends, but I can easily add more or create completely custom ones.

     

    This method also allows avoiding double layers, like for example annoyances that would emerge by combining ASIO + CoreAudio (local/remote).

     

    Good point. Presumably there could be a common design pattern that would allow translation of CoreAudio or ASIO to ALSA but of course that would be only for PCM (as with AES67 as well) -- DSD is its own thing and even if the network protocol understands it, the OS audio architecture would also need to.

    Share this comment


    Link to comment
    Share on other sites

    1 hour ago, Superdad said:

    NAA/networkaudiod is no doubt small enough and flexible enough to run on many SoM offerings--which could readily be incorporated as the Ethernet input component of new/old DAC designs.

     

    As I see it, NAA is no more and no less than what is needed for stereo or multichannel home audio incorporating both PCM and DSD. It doesn't need the complexity of AES67 which doesn't itself natively do DSD (though Ravenna is extended to allow).

     

    1 hour ago, Superdad said:

    ... But the lack of that sort of solution is the sole reason why the market window is wide open for Merging to step in with their VSC>Zman offering.  

    Regardless of whether or not it will technically offer the best sonic performance for purist audio, it will (given reasonable module costs and s/w licensing--plus ongoing upkeep of the VSC s/w as popular operating systems change) result in more rapid adoption by DAC manufacturers and the public.

     

     

    Haha well let's see what the actual cost of Zman as well as the ease of adapting it to an arbitrary DAC actually is ;) Does anyone know a price? ... and what type of socket does it plug into? Do you thing Merging has the goal of allowing you to produce a better/cheaper DAC than their own by employing Zman? Who knows?

     

     

    1 hour ago, Superdad said:

     

    It has never been a secret that this is an area of great interest for me (has been for a dozen years; Chris and I met for the first time in 2005 when I was at Hovland trying to bring out an Ethernet DAC/CDP based on CompuLab module and John was trying to make netJack work for it).  

    So I hope this discussion will continue and that many will point out and explain where I am entirely wrong.  But I want to hear about the avenues and alternatives to go forward.  I think the jury is still out as to whether Merging's Ravenna>VSC>Zman is going to be open enough to achieve hegemony in the audiophile market.

     

    What happened to your netJack effort? The advantage of netJack is that, as open source, it could always be extended/forked to do what ever was needed e.g. there are already netJack1, netJack2 why not netJack3...

     

    I think that until a de facto standard arrives for "ALSA on the network" it will be much easier for a DAC manuf to provide Windows/OSX/Linux network drivers (e.g. custom VSC) than implement Ravenna.

    Share this comment


    Link to comment
    Share on other sites

    46 minutes ago, jabbr said:

    I think that until a de facto standard arrives for "ALSA on the network" it will be much easier for a DAC manuf to provide Windows/OSX/Linux network drivers (e.g. custom VSC) than implement Ravenna.

     

    All great points as usual Jonathan.  But as for your last quoted, I presently don't see anyone stepping up to do either. :(

    That's why I keep hoping that someone like Miska--who has pieces already part way there and knows how to burrow into each of the major OSs--will get inspired (maybe by you) to get the elements in place for some clean and simple OEM solutions.

    The hardware SoMs are plentiful and cheap.  Proper clocking interfaces need to be minded.  But otherwise, aside from the big issue of VSC, a more open and audiophile oriented alternative standard could be developed.

     

    If that does not happen, then maybe the choice for manufacturers who don't want to embrace Ravenna will be some other, non-Ethernet interface entirely. :ph34r:

     

     

    Share this comment


    Link to comment
    Share on other sites

    18 hours ago, Superdad said:

    If that does not happen, then maybe the choice for manufacturers who don't want to embrace Ravenna will be some other, non-Ethernet interface entirely. 

     

    In your dreams :) 

    Seriously I think John's original inclination for netJack was along the right lines, but perhaps you just didn't carry it through for whatever reason. Some ideas are "too early".

     

    I also think @Miska's ideas about Ravenna are spot on (hey you know I've been working with the Zynq, so have thought this through a bit) Part of my delay has been the original "snickerdoodle" hardware ($55) never shipped (and I'm still waiting for my board ... :( But no big deal because avnet to the rescue :)  ... I'm looking at this because all of the stuff that sits on one chip ... yep including fiber interface!... and dev costs are much much less than the equivalent Altera for me :/ 

     

    In any case we need to get away from thinking about the protocol as hardwired. These days Ethernet etc is essentially built into the chips and the TCP/IP level is just software. Everything above TCP/IP on the stack is software. Even the "hardware" on the FPGA is software and reconfigurable on the fly (yep!) ... so whatever, I have a DAC whose external interface consists of one chip... and its entirely reconfigurable.

     

    Now @Miska has nothing to worry about regarding Ravenna from a technical POV, but RAAT/RoonReady is certainly getting market notice, and if they release an SDK which allows client as well as server implementation, that might become the defacto standard. Opening NAA protocol would allow a DAC to offer an NAA based VSC so that you could just listen with iTunes or whatever. Heck I'd personally buy an HQPlayer license to go with my new DAC if it allowed that functionality. It would be really really cool if the HQPlayer "VSC" would automagically upconvert from iTunes on the Mac the same way as Roon is doing this for me now (using HQPlayer). Maybe the HQPlayer embedded license would enable that... I'd go for that :cool:

     

     

    Share this comment


    Link to comment
    Share on other sites

    14 minutes ago, jabbr said:

     

    Now @Miska has nothing to worry about regarding Ravenna from a technical POV, but RAAT/RoonReady is certainly getting market notice, and if they release an SDK which allows client as well as server implementation, that might become the defacto standard. Opening NAA protocol would allow a DAC to offer an NAA based VSC so that you could just listen with iTunes or whatever. Heck I'd personally buy an HQPlayer license to go with my new DAC if it allowed that functionality. It would be really really cool if the HQPlayer "VSC" would automagically upconvert from iTunes on the Mac the same way as Roon is doing this for me now (using HQPlayer). Maybe the HQPlayer embedded license would enable that... I'd go for that :cool:

     

    Yes: Choice, flexibility, and performance.  That's what we are all seeking!  :D

    Share this comment


    Link to comment
    Share on other sites

    5 hours ago, jabbr said:

    Now @Miska has nothing to worry about regarding Ravenna.

     

     

    True.  You can use HQ Player with a Ravenna-equipped DAC like the NADAC or NADAC Player and it works fine ! 

     

    Share this comment


    Link to comment
    Share on other sites

    23 hours ago, jabbr said:

     

    @MiskaOpening NAA protocol would allow a DAC to offer an NAA based VSC so that you could just listen with iTunes or whatever. Heck I'd personally buy an HQPlayer license to go with my new DAC if it allowed that functionality. It would be really really cool if the HQPlayer "VSC" would automagically upconvert from iTunes on the Mac the same way as Roon is doing this for me now (using HQPlayer). Maybe the HQPlayer embedded license would enable that... I'd go for that :cool:

     

     

    My point was to avoid the VSC and instead use what ever source. Source doesn't even know that the audio goes through this "DSP box". Sure, iTunes, Spotify, Tidal, etc. work. So does the old CD spinner playing the old silver discs. This also makes distinction how the source is connected and how the DAC is connected, can be different technologies.

     

    Of course DSP and the DAC could be built into the same box too, but it is sort of irrelevant from this perspective.

     

    Share this comment


    Link to comment
    Share on other sites

    On 7.7.2017 at 5:01 AM, jabbr said:

    What happened to your netJack effort? The advantage of netJack is that, as open source, it could always be extended/forked to do what ever was needed e.g. there are already netJack1, netJack2 why not netJack3...

     

    Me being one of the JACK developers, I can tell that it doesn't really fit audiophile use cases. It is designed to work as an inter-application audio patchbay for studio use. And it works very well for that purpose. But it also creates quite a bit of limitations. One is connection establishment logic that needs to be somewhere - telling how the patchbay is to be set up. Another is that it is very latency driven (like Ravenna too), because you need low delay from mic to the monitors. But one of the biggest things is that has been designed to run at one single constant sampling rate (not a problem with HQPlayer, because HQPlayer is most usually used that way).

     

    And it won't do DSD in a sensible way.

    Share this comment


    Link to comment
    Share on other sites

    On 7.7.2017 at 2:43 AM, Superdad said:

    Your NAA/networkaudiod is no doubt small enough and flexible enough to run on many SoM offerings--which could readily be incorporated as the Ethernet input component of new/old DAC designs.

     

    NAA is just a network audio endpoint, designed to perform that for HQPlayer. I don't see why it should be used for anything else... Other possible use cases are zero benefit/interest for me.

     

    On 7.7.2017 at 2:43 AM, Superdad said:

    But until you tell us otherwise, it is my understanding that usage of NAA is dependent upon user licensing and use of HQ Player Desktop.

     

    Yes, HQPlayer in general, Desktop or Embedded.

     

    On 7.7.2017 at 2:43 AM, Superdad said:

    And that with the notable exception of the integration you have offered with Roon (plus some noble scripting efforts by Geoffrey Armstrong for iTunes)--both of which require an HQP license--it is not possible for any desktop OS to simply send audio to an NAA device as if it was a directly attached "sound card."

     

    No no, that is completely different. Roon doesn't understand anything about NAA and never talks to it. All those cases talk exclusively to HQPlayer, which may, or may not, output to a NAA.

     

    On 7.7.2017 at 2:43 AM, Superdad said:

    That limitation--the fact that a user can not just play YouTube, or iTunes, Windows Media Center, or JRiver, or Foobar, etc. to a DAC on the network--is THE thing holding the market back.  I suppose that if you offered OEM licenses to both NAA (maybe you do and that is what you call HQPlayer Embedded?) for the DAC side module AND a version of HQP Desktop that was a pipeline that any music player app would stream through and out to the NAA, then that would have appeal for DAC makers and users.

     

    HQPlayer Embedded is like HQPlayer Desktop, but with all the graphical interface replaced by network control interfaces. So you use either HQPlayer Desktop or HQPlayer Embedded, either one can output to a NAA.

     

    Embedded just has an additional feature that it can also take realtime audio inputs from various sources and perform all the processing on those.

     

    On 7.7.2017 at 2:43 AM, Superdad said:

    But the lack of that sort of solution is the sole reason why the market window is wide open for Merging to step in with their VSC>Zman offering.  

    Regardless of whether or not it will technically offer the best sonic performance for purist audio, it will (given reasonable module costs and s/w licensing--plus ongoing upkeep of the VSC s/w as popular operating systems change) result in more rapid adoption by DAC manufacturers and the public.

     

    I have no problem with this... I don't think much about markets or such, I only think about what is technically best for the things I want to technically achieve.

     

    On 7.7.2017 at 2:43 AM, Superdad said:

    Roon put together both their RoonReady partner program and the RAAT protocol, and audio manufacturers large and small flocked to it.  In fact, Roon garnered far more consumer market support in 18 months than AES67/Ravenna has in all its years.

     

    I don't have problem with this either. :)

     

    I'm also pretty sure both companies have way more manpower to deal with all those companies. But neither one stops me from continuing on my technical path.

     

    From a different point of view, I was certainly happy with the Estelon LYNX launch at Munich (not related to NAA though)!

    https://parttimeaudiophile.com/2017/05/26/high-end-2017-estelon-introduces-the-lynx/

     

    Share this comment


    Link to comment
    Share on other sites

    I’m arriving late too the party. Everybody has already gone home. But I still like too contribute my daily experience as a Ravenna and Merging Hapi user because I didn’t read much input from daily users.

     

    For me connecting a computer to a DAC/Audiointerface through an ethernet (IEEE 802.3) connection is just one of many possibilities to connect a computer. Just as PCI(-E) OEM card solutions, Firewire, USB or Thunderbold can provide an audio connection.

     

    In the past there where overheated discussions on that there could be absolutely no audible effects between different cables used to make a connection through USB or firewire because ‘bits are bits’. Today almost everybody knows that USB and Firewire connections for audio purposes need careful engineering to make them sound good. Like: asynchronous transfer, XMOS chips, DICE chips, carefully designed divers, firmware and software, carefully designed hardware, special purpose designed mini/micro computers (microRendu’s and others), ect.

     

    Same is true for audio-over-ethernet (IEEE 802.3) connections. It needs careful engineering to get the best from it for audio. However not everybody is still convinced yet. On Archimago’s Musings you can still find ‘bits are bits’-style blogs about audio over ethernet.

     

    In daily use the Ravenna-on-ethernet-(IEEE 802.3) connection between my computer (Mac mini) and the Merging Hapi is just like any other connection.

    (Mac mini -> UTP cat 6 cable that came with the Hapi -> Merging Hapi).

    I installed the software and selected the Hapi for sound output. That’s it. There is no steep learning curve (IMO). It has same user simplicity as an USB-connection.

    Ravenna-on-ethernet-(IEEE 802.3) offers much more distribution options (which I don’t use yet). USB cable length is limited to 5 meters but for UTP Cat 6 cable this is 100 meters. So there is much more flexibility where too put the computer and the DAC. Very high quality DAC’s can also be found inside speakers, so I would surely try a Zman module if it could be installed inside my PMC TwoTwo.8 speakers.

      

    * Ravenna-over-ethernet-(IEEE 802.3) sensitivity for UTP LAN cable.

    With the Zman module in mind, I was curious how sensitive the Ravenna-on-ethernet-(IEEE 802.3) connection would be for different types of UTP cat 6 or 7 cable?

    For this too try I swapped out the UTP cat 6 cable that was provide by Merging (came with the Hapi inside the box) and replaced it with a DIY Belden ISTP 1885ENH ‘Cat 7’ with Telegartner plugs. 

    I could not hear no audible difference. Although some times I thought it sounded slightly different. But I friend of mine found that both LAN cables sounded the same.

     

    So in my simple test Ravenna and Merging Hapi showed no sensitivity for different types of UTP cable and RJ45 connecters.

     

    How very much different this turned out too be in other area’s and parts of my home LAN (Mac Mini included)

     

    * Other very surprising sound quality related findings on audio over Ethernet (IEEE 802.3).

    First some history en info on my home LAN.

    In 1999 I installed no-name brandless UTP cat 5e cable with brandless RJ45 krimp-on connecters too every room in my home. Livingroom got 2 UTP cat 5e cables.

    From 2007 I used this LAN too connect a NAS (inside the meterboard down the hall) to a dedicated multimedia computer in the living room for playing audio and video

     

    In Jan 2017 I applied a tweak by disconnecting twisted pairs numbers 3&4 in the RJ45 connecter on the UTP cable too the Mac mini. This tweak forces the hardware speed down from 1000Mb/s to 100 Mbs. Just as described on audio forums this tweak gave a very pleasant jump in sound quality.

     

    Because of this tweak I decided to re-place all the no-name UTP cat 5e cable in my home LAN with Belden ISTP 1885ENH cat 7 cable with Telegartner connectors. Again there was a nice jump in sound quality and much to my surprise: there was no longer was any difference in sound quality between 1000Mb/s and 100Mb/s speed !

     

    * Audio-over-Ethernet (IEEE 802.3) sensitivity for (Mac mini) tweaks.

    First some more info on my setup:

    The meterboard down the hall houses the cable-modem too switch & the NAS too switch

    Switch = Netgear Managed Switch GS108Ev3 (LAN cable shield earthed to real earth)

    Switch -> 20 m ISTP belden Cat 7 -> thunderbold LAN adapter -> Mac mini

    Mac Mini -> Supra 2.0 usb -> Crane Song Solaris -> Vovox cable -> PMC TwoTwo.8

    Mac mini -> build in LAN port -> Ravenna UTP cat 6 -> Merging Hapi -> Vovox cable -> PMC TwoTwo.8

     

    In this setup, I applied several tweaks to the Mac Mini.

    * Audio-over-Ethernet (IEEE 802.3) sensitivity for disabling hardware inside the Mac mini.

    I physically disconnected the SSD power cable and SATA cable from the Mac Mini Motherboard. I also physically removed the WiFi module from the Mac Mini Motherboard and copied the OSX-operating system too a SD-card.

    These tweaks gave a profound jump in sound quality as recommended by ‘Superdad’ (Alex Crispi, Uptone audio)

    Although the Solaris and the Hapi sound somewhat different, too my ears the sound quality increased equally on the USB connection as well as on the Ravenna connection.

     

    * Audio-over-Ethernet (IEEE 802.3) sensitivity for improved power supply too the Mac mini.

    Two weeks ago I removed the original SPSU from the Mac mini and replaced it with a Uptone DC-Conversion / Linear Fan Controller Kit (MMK) powered by a HDPLEX 200W Linear Power Supply.

    Again there was a nice little sound quality improvement on the usb -> Crane Song Solaris connection.

    But – all to my surprise- the sound quality massively improved on the Ravenna UTP cat 6 -> Merging Hapi connection.

    I got I huge smile on my face from this MMK/linear PSU improvement on the Ravenna ethernet connection too the Hapi. It completely (!) changed the sound from my system.

    With these tweaks in my setup the Hapi now sounds better (too my ears) than the Solaris.

    Before the MMK/linear PSU tweak the Hapi and the Solaris sounded both equally very good.

     

    * What too learn from these tweaks?

    Merging did a very good engineering job and designed an audio-over-ethernet product that is not sensitive for LAN cable-tweaks in my setup. The Ravenna protocol and the Merging Hapi are great concepts/products with excellent sound quality. Too my ears the Hapi price/performance ratio is among the very best available (same is true for the Crane Song Solaris as an ‘USB-product’)

     

    But that’s surely not the case for other parts of my audio-over-ethernet home infrastructure.

    The sound quality coming from the Mac mini when using audio-over-ethernet appeared too be very sensitive for hardware and PSU tweaks. It looked like that audio-over-ethernet through a Mac mini is even more sensitive for tweaks than audio-over-USB through a Mac mini.

     

    Also other parts of the audio-over-ethernet infrastructure in my home where very sensitive too tweaks.

    Using Belden ISTP 1885ENH cat 7 cable with Telegartner connectors throughout the audio-over-ethernet infrastructure in my home had a significant impact on sound quality.

     

    So all in all there’s really nothing much new. It’s the same as with sound quality through USB or Firewire. Hard- and software has too be properly designed and engineered too get best results from audio-over-ethernet. Standard no-name UTP cat 5e cable and standard no-name RJ45 krimp-on connecters and a standard Mac Mini are clearly not designed with best audio-over-ethernet performance in mind.

     

    Just like audio-over-USB and audio-over-Firewire there now is a heated debate about audio-over-ethernet not  being sensitive for this-and-that because ‘bits-are-bits’. But just like audio-over-USB and audio-over-Firewire its needs proper hardware, design and engineering too get best audio results from it.

    Share this comment


    Link to comment
    Share on other sites

    Great post. How nice to get real life experiences instead of theory without experience.

     

    At first I thought that my Rednet D16 ethernet to SPDIF converter made tweaks on my PC less effective but I found that the effects just migrated to make different things more important. For me the big strides now have been in power isolation and minimizing ground current per some of John Swensons suggestions.

     

    One thing you might try is using a pair of Fiber Media Converters to connect optical fiber for the direct connection between your computer and DAC. It really helped make my background blacker and bring out details. I even replaced the NIC in my Windows based PC with a PCIE fiber card.

    Share this comment


    Link to comment
    Share on other sites




    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now




×
×
  • Create New...