Jump to content

happybob

  • Content Count

    39
  • Joined

  • Last visited

About happybob

  • Rank
    Newbie

Recent Profile Visitors

2182 profile views

Bookmarks

  1. miska HQP developer says use high Sample rate PCM always with Chord and Mola Mola DACs
    The Mola Mola Tambaqui DAC
    On 3/31/2021 at 6:33 PM, ted_b said:

    Same goes for DSD files....thx

     

    Mola-Mola DACs convert DSD inputs to PCM. So if you use HQPlayer with those, it is best to always send highest possible rate PCM there and never DSD. (similar way as with Chord DACs)


  2. Tom at Reference Recordings on DXD vs DSD recordings
    Impressive DXD downloads

    Hi,

     

    Reference Recordings Fresh series are recorded by Soundmirror, and all but a portion of one album are recorded in DSD256. All these recordings are subsequently post processed, including editing, in DXD on a Pyramix DAW. The resulting DXD file is the album's edited master, which is uploaded to NativeDSD's ftp label server. 

     

    The two stereo and surround DXD edited masters are in the form of proprietary continuous 32 bit WAV files known as an MTFF (Merging Technologies File Format), which includes the track timing markers. These 32 bit PCM interstage edited masters are then run through Pyramix Album Publishing, producing the individual separate tracks in PCM 352.8KHz/24 FLAC, DSD256, DSD128, DSD64, plus a PCM 352.8KHz/32 WAV copy. I use that DXD/PCM 352.8KHz/32 WAV to produce the DSD512 in HQPlayer Pro.

     

    SInce the edited master IS the original generation of the assembled/edited takes and post processed sweetened recording, the Pyramix Album Publishing process of producing the deliverables is the most direct and least invasive process available. Whether the DXD FLAC, or the highest bitrate DSD that a customer's DAC can support is chosen, it is IMO, completely dependent on the customer's DAC type and conversion process. For DAC's who directly convert a PCM sample based stream of digital values, like a ladder DAC, then the DXD FLAC is optimal. For DAC's with Sigma-Delta modulator conversion, by and large, the DSD format is optimal.

     

    Regardless of the format chosen, I believe for now, this is the definitive Beethoven 9 reading for both artistic value, and certainly sound quality. I say for now, for while delayed from session recording in November last year, I'm hopeful the Budapest Festival Orchestra recording of this Ninth Symphony will occur yet this year. 

     

    Thanks,

    Tom   


  3. Nenon custom server solution Taiko ATX DIY server
    Building a DIY Music Server

    Hi everyone! I am building a computer for someone else and decided to share what I am doing with everyone. 

     

    Let me start with some of the high level requirements:

    • One box solution to eliminate some of the clutter.
    • Optimized for Streaming (Tidal / Qobuz).
    • The best quality USB output.

     

    I came up with the following specs:

    • Motherboard: ASRock Z390 Phantom Gaming ITX changed to ASUS Z390-I ROG Strix Gaming Intel LGA 1151 mini ITX motherboard
    • CPU: Intel Core i9-9900 changed to Intel Core i9-9900K
    • RAM: 2 x 4GB Non-ECC Apacer RAM (Apacer D11.2318FS.004) changed to 2 x 4GB ECC Apacer RAM (D31.23185S.001)
    • OS Drive: 32 GB Optane
    • Chassis: 2 x Streacom FC9
    • USB Output: PinkFaun USB Bridge with ultraOCXO clock
    • Network input: JCAT NET FEMTO
    • Operating System: Euphony running Stylus, switchable to Roon

     

    Some other specs:

    • 6-rails of DC power 
    • All wiring will be done with Mundorf silver/gold wire (and JSSG360 shielding where it makes sense)
    • Isoacoustics Gaia feet will be used on both chassis
    • Some but very little EMI absorbing material to be applied at strategic places.
    • All connectors will be treated with Walker Audio Quantum Silver Contact Treatment with Nanocrystal Technology.
    • Resonance controlling material will be applied on the chassis.

     

    Power Supply:

    Given the specs above, we came up with 6-rails - 3 for the ATX connector, 1 for the EPS connector, 1 for the PinkFaun USB card, and 1 for the JCAT NET card.

    He acquired a 4-rail Sean Jacobs power supply, which I customized for him. 3 rails used for the ATX connector and one rail for the PinkFaun USB card. 

    The EPS connector will be powered by another 12V Sean Jacobs DC3 LPS he already has.

    The JCAT NET card will be powered by various spare linear power supplies he has, tbd which works best. 

     

    There are two goals with the customization of the 4-rail LPS:
    1. Shortest possible cable path from the double regulators to the components powered.
    2. Good heat management to keep things cool.

    We decided to use two black Streacom FC9 chassis. One chassis would be hosting a big 400VA toroidal transformer, Schottky diodes for rectification, Mundorf caps, etc. The second chassis would be hosting the motherboard, CPU, RAM, etc. and some of the DC regulators. 

    I decided to install the regulators for the ATX connector in the motherboard chassis. That would meet the first goal.

    For the second goal, I left the regulators for the PinkFaun USB bridge in power supply chassis. I calculated that the path from the regulators would be almost the same length as if they were in the motherboard chassis. But we have an available heatsink to use in the power supply, so I opted for the better heat management. 

    This may resemble a little bit the power supply of the Innuos Statement described here - http://www.the-ear.net/how-to/power-supply-design-innuos-statement. 

    It’s not a coincident, and some of the ideas were taken from there.

     

    It’s also good to mention that Sean Jacobs would not do a power supply like this. Due to his contract with Innuos, he is not doing ATX power supplies. The only way to build his power supply inside a computer is to go the DIY route.

     

    This server will look a little like the Innuos Statement. But to be honest, I am aiming higher than that.

    One can buy a Statement instead, but there are a few things I don’t like about the Statement - the low powered CPU does not sound as good as this configuration; the SSD drives are too noisy, and I don’t want to have any in my servers; Apacer RAM is a must; the wiring (silver/gold wires used for everything) cost $1,500 alone… if the Statement had the same wires and cables, it would probably cost $5K more just for that… that’s not including the amount of time, it takes to do all the JSSG360 shielding and every small detail. And those cables make a big difference.  I’ve heard the Statement in a few occasions and liked what I heard. But I’ve never had one in my system to compare with a DIY server like this. 

     

    Stay tuned. I am planning to post a lot of pictures and comments as I make progress. 

     

    Here is the final result and a review from the new owner after a couple of weeks of listening to the new server:

     

    finished2.jpg.ba621e195a0cb04b67d7675de0f22afe.thumb.jpg.d67709e2dec2a7e92b2eef7a0c03f2cb.jpg


  4. balancing tradeoffs
    Chord Qutest

    @barrows is spot on.  It is all about balancing tradeoffs, since there isn't an ideal (yet).  

     

    The insidious thing is that a recipe/scheme that works astonishingly well for one person, may have marginal impact for another person.  The trends and tendencies and levers are pretty clear, but getting to the right balance is very much dependent on your system, your home, your environment, and your ear/brain.  

     

    For example, Rob has shared that when he got a new laptop, the balance and impact of toslink and USB changed for him.  Not a surprise, but very easy to forget when we're all scrambling to fit all these pieces together into something that works for us.

     

    I've learned (alas, and relearned again and again and again) to keep an open mind, be systematic, and after you make a major change, go back and revisit all the things that were obvious before.  Any (new) thumb on the scales shifts the balance of the entire system.  There was a time where TOSLINK was the end all for me (until I did upsampling differently), optical BNC (until I did upsampling differently), USB with regenerators (until I did my source differently), vibration absorption (until I did power differently), etc. etc.  

     

    All of those were local optimum points (the top of the hill).  However, there is always a new and different hill that may be higher still.  Best you can do is climb the hill with your own system, and look to ideas and experiences from others for new hills to explore (if you're so motivated...there is something to be said for parking a comfy chair on the hill you're on, and enjoying they view)


  5. Nenon on one box server vs server and streamer separate - great post
    Building a DIY Music Server
    17 hours ago, Foggie said:

    Understanding the logic you stated, but are you indicating that the mere presence of roon is creating noise / crap on the network and ultimately degrading sound even if your using a well isolated endpoint / HQP?

     

    No, not at all. 

     

    First, I don't really buy into the whole concept of a well isolated endpoint from the server. The idea sounds really good and logical but never worked well for me in practice. It's just like the concept that DAC manufacturers have been trying to convince us for years - the USB input is galvanically isolated and reclocked, so the quality of the server does not matter. No need to explain to the people following this thread that a well-designed source (server/endpoint/whatever you want to call it) makes a big difference. There is a really good reason servers like Innuos, Taiko, PinkFaun, Antipodes, etc. exist and cost so much. Arguably, they could make as much difference as a DAC (yes, even when connected to that same DAC with galvanically isolated USB input and reclocked signal). Anyone with a resolving enough system who has switched from a Mac MINI or a laptop to one of these well designed servers has experienced that. 

     

    So, if a galvanically isolated USB input with a reclocker does not work, why do we think that we can "isolate" a server from the endpoint and make the endpoint immune to the server quality? From all my experiments, the conclusion has always been the same: "we can't". I've tried everything I could think of - fiber ethernet, fiber ethernet with state of the art clocks, fiber ethernet with state of the art clocks and state of art power supplies... and state of the art switches... and network cards.... and cables... and power conditioners... and state of the art motherboard clocks, powered by state of the art power supplies and cables... and different transceivers... and so on and so on. 

     

    I don't know exactly why ethernet isolation does not work, just like I don't know exactly why a galvanically isolated and reclocked USB input on a DAC does not work as expected. But here are some examples that may give us a hint. Let's talk about an endpoint for a second - the last computer that is connected to the DAC. It may be receiving a data stream from the network (i.e. from a Roon Core) or playing music locally. 

    1. In many cases, my experience with local music playback has been that disconnecting the network cable leads to a sound quality improvement shortly after the disconnect. That suggests that some noise is getting into the server from the network.

    2. I have noticed that unnecessary network activity while playing music deteriorates the sound quality.

      2a. Euphony / Stylus caches the track you are playing and minimizes the network activity to a minimum. During some of my tests I noticed that opening multiple web browsers pointing to the Euphony page would degrade the sound quality. That was a very interesting experiment. The more web browser windows you open (pointing to Euphony), the easier it is to hear that. At some point I remember opening 50 windows on multiple computers. It turned out Euphony was using Ajax to update the time lapse interval display every second or so. That extra network traffic was enough to cause some sound quality degradation. BTW, I reported this to Euphony and they added an option to disable that traffic. 

      2b. When I isolated my endpoint to its own VLAN, I heard an improvement. Isolating to its own VLAN means that any broadcast traffic from my home network would not make it to my endpoint. I have a very small home network and have used a sniffer to see how much broadcast there is. It's very little, but yet enough to have an impact. 

      2c. I have tweaked how the NIC interacts with the CPU. You can configure the CPU interrupts and resources the NIC driver is utilizing, essentially how the NIC interacts with the OS. It's an interesting test. You configure it to use more resources and you get lower latency, but that comes with some side effects (i.e. your server becomes even more sensitive to any extra network traffic, thus making the network chatty Roon even worse). You make it use less resources, and you are more immune to all the network activity going on, but you increase the latency and that has other side effects. i will be writing more about this in the Windows LTSC guide later this year.

    All that tells me that that network activity on the endpoint impacts the sound quality. Even if you have the perfect server streaming the perfect stream over the perfect network to your endpoint, the fact that the endpoint is receiving and processing network packets (while playing) is not ideal and degrades the sound quality of the stream going to your DAC. 

     

    The ideal endpoint would be one that does not have a network connection at all. And this is where attention to detail in software that is designed with sound quality as top priority matters. I do expect to see some breakthrough innovations in the software in the near future. 

    But if that is the case, why so many people buy into the server/streamer concept and after trying many solutions including a single server/endpoint device, they prefer it (in many cases by a big margin)? I think the answer is twofold. One part has to do with upsampling and the other with the quality of the server. Let's cover those two:

     

    Upsampling:

    Many DACs work better when they are fed by an upsampled signal. Those are typically DACs that upsample internally. By feeding them with an upsampled signal they have to do less processing. That results in less processing inside the DAC, which results in less noise, which ultimately means better sound quality. Sparing the noise that tha DAC is producing during its internal upsampling in some cases is much bigger improvement than upgrading servers/endpoints upstream of the DAC. That is of course DAC-dependant and not always the case. But for these DACs it makes perfect sense to use software like HQPlayer that does the heavy lifting and offloads the DACs extra processing (and noise).

    What happens when you start doing heavy upsampling on your server that is directly connected to the DAC? Well, I mentioned above what the impact of the network/ethernet processing is, but that is nothing compared to the impact of the heavy processing that HQPlayer does. The noise generated from the upsampling process on the server is in orders of magnitude bigger than the negative effect of the network/ethernet processing. It's much better to isolate the upsampling noise from the endpoint and accept the network/ethernet noise / sound quality degradation. The net result is a big improvement in this case. And this is why many people prefer a two box solution - a server and a streamer. Sounds like a good compromise... but there are people like me who just can't settle with such a big compromise and kept looking. More on that later. 

     

    Quality of the server (in a single box solution):

    This is another aspect that we should not forget. When you have a single device that handles the server and the streamer part, it is directly connected to the DAC and its quality is crucial. Computers are noisy devices that were not designed for audio. But with a careful implementation and the right choice of software, hardware, power supply, etc. you can make a single box solution work better than anything else. You cache the tracks before playing, minimize the network activity, and take care of every detail, and you would be rewarded. 

     

    There is a saying that your system is only as good as the weakest link in the system. The same applies to the digital source. I look at it as a complex chain of components that interact in a very complex way.  There are different solutions for different people. For some people the benefit of the upsampling is so big, that they can live with the negatives of a server and a streamer solution. Other people have DACs that don't benefit from upsampling and settle for the best single box solution they can get. There are also people who like the small / low powered endpoints and can't understand why we do all that instead of buying a *Rendu for example - from my experience those are people with small systems, typically with bookshelf speakers who don't need the massive scale, dynamics, and everything else a server like the Taiko Extreme can do but like the low noise, dark background, small but holographic soundstage of these devices (and I completely understand their point of view as well). There is no universal solution that works best for everyone. 

    Here is what I do:

    I currently use the Chord DAVE DAC powered by a Sean Jacobs DC4 LPS. This DAC benefits from upsampling. It specifically benefits from being fed by 705.6/768kHz PCM. It also benefits from more taps, but that's outside of the scope of this post. As mentioned above a two server solution does not work for me. So I upsample my local music offline and store it locally. There are programs like HQP Pro and some others that can do that. I store the music locally on my NVME storage. Then I use HQP and NAA on the same server. I assign affinities for those processes on different physical CPUs (which also means they use different RAM modules). I have a CPU that is only responsible for the music processes (i.e. NAA in this case). The USB output is directly attached to that CPU. The other CPU handles all the network activity, OS activity, HQP part, etc. In a way, I get the best of both worlds and the net result is amazing. 

     

    Going back to the question about Roon. Roon does a lot of things that harm the sound quality. It performs constant network activity while you are playing, it has constant disk I/O activity, it does some processing that swings the CPU utilization, which causes noise that is audible in a resolving system. And the list goes on... Depending on whether you use a two box (a server and a streamer) solution or a single box solution like me it has different impact. But in any case, it would not be my choice for critical listening. Having said that Roon/Qobuz is the best tool for discovering new music for me. I so use it for that. 

     

    P.S. A note to myself - learn what a short reply means! 


  6. Roon replacement software that sounds better
    Building a DIY Music Server
    6 hours ago, drjimwillie said:

    Is Roon sending a stream when HQplayer is processing the file? Is HQplayer handling the whole processing of the file?

     

    Is it that Roon doesn’t serve up the URLs or that they will not give the URL out of principle?
    If the song you choose is on Qobuz, all it would have to do is point to that Qobuz file.

     

    and, I’m not talking about Roon talking to the endpoint it is communicating with the server.

     With Roon on my Nas and HQplayer on my server, HQplayer processes a file served up by Roon.  Or do I have it wrong?  


    Are  you saying that my Roon on my Nas is streaming a file it has processed and sending that to HQplayer on my server to process again?

     

    Roon does not just serve the URL to an external program. It does a lot more than that that deteriorates the sound quality no matter where you run it or how you isolate it. 

    Your idea to have Roon just handle the URL and shutdown any other activity is great. Unfortunately Roon has no desire to make such changes... or any changes that significantly improve the SQ. They have different priorities. Many of us have tried to convince them to do things to improve the sound quality but they have been ignorant and arrogant for the most part. That's their loss. New and much better software is coming up and replacing Roon in many high-end systems. The interface will slowly catch up over time.

     


×
×
  • Create New...