I just got a reply from the AliExpress seller, he claims the product is 100% genuine LHY Audio product (the seller stocks all available LHY products and has a bunch of positive reviews).
In regards to specs, he claims the product is a 4GB Raspberry Pi with a 32GB SD card. So all good for now.
Now waiting for Beatechnik to confirm this is a LHY product before placing an order.
Curious to know whether youāve tracked CPU usage with top or similar. The reason I ask is that AudirvÄna as you know does any sample rate conversions, then places the result in RAM, repeating this step as often as necessary. The CPU usage is considerably higher for me when doing the conversion than when playing from RAM. With more RAM, more of a given track is spent in a lower CPU usage condition.
It hardly uses CPU, only when indexing local folders. Hardly is between 0,5 and 2,5 %
Hi Angelo, Filippo (aka AntonelloCaroli) is the creator/developer of GentooPlayer and yes, heās Italian
Iām assuming no sample rate conversion. My use case is very different - conversion to DSD512 - and thus my concern about more RAM.
No, I do not use conversion, upsampling or any plug-ins. Upsampling works fine with a 2GB Pi for those who wonder.
I have no use case for DSD conversion, so I donāt know if that works with a 2Gb Pi.
Guys, which SD cards do you recommend? Should speed be the determining factor? Does storage size matter at all?
It is a bit of a gamble, since I have two cards with the same speed indication, in practice there is a notable difference. The one that works best for me is Transcend MicroSDHC UHS-I Class 1 32GB, but it depends on your local availability. I just picked a random one from the list at a low price, it is not a very deliberate choice. The other one is the one branded as a Raspberry Pi recommended one, but that is notably slower when scrolling in Audirvana in the app.
If you folks are hanging your hat on performance of the Audirvana/OS/platform synergy, and audio quality is the primary focus, then the bus-speed of these SD Cards is a jokeā¦ An M2 chip (SoC) Mac Mini has a memory bandwidth speed of 100GB/s
Faster bus speed correlates to better sound quality?
The short answer: Yes
High-speed bus transfers reduce CPU interrupt and system topology latencies due to wait times and buffer slew-ratesā¦ Any DSP will require buffering and basic application performance is intrinsically tied to CPU interrupts and memory bandwidth speedā¦ A basic axiom: āMore RAM is Betterā and bus-speed is intrinsic to performance quality.
The switch and server are asynchronous by virtue of the operational mechanics of Ethernet transmission protocol, so there would be nothing gainedā¦ Now, if you were connecting a DDC to a DAC then having a master clock source makes senseā¦
Just to put expectations into contextā¦ The B&O Beolab 28 speakers support up-to 24 bit/48kHz LPCM signalsā¦ What you are configuring has the potential to produce a high-quality 24/48 LPCM signal output to the speakersā¦ However, there is an intrinsic point of diminishing returns given this reality and the stereo configuration where the two speakers are paired/connected with yet another Ethernet connectionā¦
Just to be sure: I am talking about the responsiveness of the Audirvana app communicating with Audirvana Core. How fast is scrolls through an album list for instance. Any other claim is up to someone elseās words.
The DAC inside the Beolab 28 supports up to 24/192.
As for the rest of your remarks, I cannot comment on those. All I can say is that each network tweak I did (LPS on the switch, fiber optical isolation) brought an audible SQ improvement. And I certainly intend to push further in order to discover the upper limit of improvements.
The master clock on the RPI4 may be an overkill, but since I intend to get two SW6 switches (as many have reported SQ uplifts), a master clock may as well help there.
Finally, I may end up with a DDC and use optical to the speakers.
I was using this information from page 7 of the Technical guide:
2.2 Stereo Pairing
Two Beolab 28s can be connected as a pair of loudspeakers for 2-channel reproduction using a network link. This connection not only contains the audio information, but also āmetadataā about the loudspeakersā configurations to ensure that their parameters (such as Beam Width) are matched.
In its factory-default configuration, the Stereo Pairing audio signal is encoded using the LC3plus high resolution mode software licensed by Fraunhofer IIS1. This is a CODEC running at 48 kHz, 24-bits and a bitrate of 1 Mbps. This is to ensure that a high quality signal can be delivered with a minimum of service interruptions caused by network traffic. In installations with adequate bandwidth in the network connections, the signal can be changed to uncompressed LPCM running at 48 kHz, 24 bit. In both settings, the input-to-output latency of the audio signal is approximately 300 ms to provide adequate buffer time to recover and correct audio dropouts that may occur due to network traffic.
It should be noted that Stereo Pairing does not work for Power Link or Wireless Power Link inputs.
However, the DAC in the speakers have no support for external clockingā¦ they synchronize with themselves via IIs protocol over the symbiotic RJ45 connection.
You are quoting the stereo pairing parameters for communication between the left and right speaker that works either via WiFi or via wired Ethernet connection, but it has nothing to do with the maximum input signal of the built-in DAC which accepts up to 24/192 .
It basically goes like this - digital signal (via Ethernet or WiFi) - DSP (beam width, room correction, etc.) - DAC - class D amplification per each driver. The same goes if the signal is transmitted via optical.
If the input signal is analog (for example if an external DAC is employed), then there is an extra step of digitization of the signal (ADC, or analog to digital conversion), then DSP, then back to analog (DAC), then amplification.
This is a CODEC running at 48 kHz, 24-bits and a bitrate of 1 Mbps. This is to ensure that a high quality signal can be delivered with a minimum of service interruptions caused by network traffic. In installations with adequate bandwidth in the network connections, the signal can be changed to uncompressed LPCM running at 48 kHz, 24 bit.
If the speakers are paired for stereo it looks like 24/48kHz is the maximum sample-rate/bit-depthā¦ I donāt see where they describe anything other than a 24/48kHz operational state in the marketing rhetoric, technical operational guide and User Manualā¦
You may be able to send 24/ 176.4kHz or 192kHz to the system, however, it looks like this signal is decimated to 24/44.1 or 48kHz for playbackā¦
Yes, I am aware of that. I am talking about reclocking of the signal before it enters the DAC.
I understand this has been the nature of your playback strategyā¦
From what I see in the devices you are investing-in, is that they all re-clock the signal with highly accurate and stable devices and employ LPS devicesā¦ Do you really think that running them at 10MHz is going to make a tangibly appreciable improvement in sound-quality over what they will produce inherently, outside of other tweaks like cable, power-supplies, etcā¦? ā¦ The accumulation of noise related jitterā¦āJitter Stewā is the issueā¦ Clocking the topologies of these components at a higher frequency does nothing to guarantee less noise or improve data integrity, in the context of Ethernet transmission protocol as the devices are not synchronized, by nature of the protocolā¦
Your system is at the mercy of the IIS protocol implementation that synchronizes your stereo pair of DACās + amps/speakers and the intrinsic jitter of that system.
What I see with trying to run Audirvana on these IoT devices is, this is an interesting project, but these things are far from running Audirvana on a true high-end Linux-based server platform, with a high-speed CPU with high-speed memory bandwidth with onboard storage SSD memory and plenty of RAMā¦
Hi Stefano, thank you.
So could I trying Audirvana on my RPI 4 with 4gb?