I have a computer in another room running Audirvāna and sending the signal to a UPnP/DLNA endpoint in my system. There really should be no effect of noise in the computer running Audirvāna on what I hear from the system in the other room, yet I fancy I can hear a difference between two different minimized Linux OSs. Makes no sense at all and could be entirely subjective. But I like it and that’s what matters to me.
![]()
Well, he didn’t reply specifically, just gave me a generic answer whilst linking the Customer and Brand Protection page on his website.
So, on one hand he is exploring the possibility of installing Audirvāna on the LHY RPI streamer (which I find to be a sort of tacit confirmation such device does exist in the LHY portfolio), on the other hand he doesn’t say when and whether that unit will be available on his website, and then he bashes AliExpress in general.
The sellers on Ali swear it’s genuine LHY device, sourced from the factory. Funny business.
I have to mention Jos from Magna HiFi in the Netherlands with whom I exchanged several emails and who gave me some very elaborate answers as to why I shouldn’t waste my money on a fancy DLNA server. Brilliant and honest customer service, on a totally different level from some of the Asian dealers/sellers.
One of the AliExpress sellers replied this (when asked whether it’s a genuine LHY audio device):
Hello, friend. Let me ask technical worker , i will reply you once i got answer
Most of the electronic components of Tiger Fish are purchased from legitimate channels such as RS Oushi Electronics, Yinuomeng Element14, and Angshi Mouser
I guess “Tiger Fish” is what they call LHY audio.
Did you make these assessments of these systems playing files over the same playback audio-components in a common room (amps, speakers, etc, etc.) over the exact same network path?
… If not… all contextual comparative assessments and assertions made here are moot… It’s a given that all interpretations are intrinsically tied to the construct of “I like it and that’s what matters to me.” bias.
![]()
Was one of the answers that it’s not electrically connected to the DAC, so why worry?
My reading of his answer, which may or may not be correct, was that it was a question of first impression, he really didn’t want to spend a lot of time thinking about it, but he didn’t want to put you off entirely.
People here have run Audirvāna for Linux on the Pi and been happy with the results, so in effect you already have your answer.
Is there a reason for using the Pi in particular? Do you have other computers already that might be used?
The short answer to the long question is yes. ![]()
In essence, he says that networking and computer PSU’s cannot be ignored totally but there are no audio signals processed, only data and therefore the impact will not be huge. Optimizing the network can make a difference when you have everything done in your audio setup.
Hi @Amused011
Am I correct in assuming that the kit you’ve mentioned is based on a Rpi, housed within an LHY case?
Am I also correct in assuming that such a device is not currently being manufactured/sold by LHY, judging by Alvins earlier comments?
How can this be so when you are describing a computer in a different room ?? How could the network path-lengths be exactly the same?
![]()
It’s all about accumulated noise related jitter “Jitter Stew” … The digital-audio signals are electrical pulses of voltage potentials that represent the digital-audio code being transmitted across the system(s)… These signals compose the bits, bytes and packets that are flowing through the different component architecture topologies…
These electrical pulses can be corrupted anywhere along the transmission path, beginning from the storage device (where the ‘perfect code’ is encoded, no matter from where it emanates) all the way through to the analog outputs of any given DAC… What we assess is the result of that journey from the storage device, through our amalgamation of playback componen topologies, platform software, OS, etc, and transmission mechanism(s) that deliver the encoded file data, where the signals finally reach our ears and the cognitive-biases that influence our interpretations. It is a perilous journey to say the least.
![]()
I’m so glad that I can only hear what goes out from my speakers and not from my cables ![]()
Because both “paths” are the same path, from the computer in the other room. Perhaps you were confused about what I was describing, which is simply trying two different OSs on that computer and thinking one sounded better than the other.
After some effort I managed to install Audirvana on the Raspberry PI 4 4Gb.
Given that it is truly incredible that everything works perfectly and that the iPadOS interface is able to control every aspect of the program, I must however add that the result in terms of listening is not comparable with Audirvana Desktop on MacMini even though it is dated, late 2012.
I don’t know the reason but the music seems “off”, the transients are slow to attack and the upsampling, predictably, barely bearable up to DSD 128, becomes tiring at 256 and impractical at 512.
But I realize that it cannot be blamed to Audirvana what is a hardware limitation.
I’m currently sticking with Audirvana Studio on MacMini.
I follow the developments and appreciate the efforts of the developers.
Got it… ![]()
It’s a miracle of modern technological dogma and the state of reactionary implications of the contextual materials design and architecture… Otherwise these things are moot and we are left imagining what the encoded recording is and how it might sound in a real-time experiential time-slice… Why not just imagine your music library… It is a lot less expensive and and a lot less complicated…? Why be bound to the material world?
![]()
To each their own, but I can conclude from an extensive comparison I am conducting that there are significant differences between Linux OS version on the same device, different computers used with the same OS and power supplies connected to the same computer when listening.
There’s some more work to do in comparison, but somewhere in September I’ll be able to share results.
There is no doubt there will be differences… this is a given by nature of the different design topologies and intrinsic API limitations or attributes and the quality of the code that exploits them and the implementation of those contextual interfacing strategies…
![]()
For DSD upsampling, the hardware is probably not powerful enough.
But for PCM, there’s a difference in transients, but it very much depends on the power supply and the Linux version used (meaning: how much services are running, taxing the system).
There’s a load more to discover, but not when using DSD upsampling as standard, then you need more horsepower.