The company I work for has a whole team of software engineers for everything software related… 
Hey Chris, my apologies for the very late response to your questions! We typically do not venture much into the user forums and welcome any questions through Bricasti.com for immediate response.
- The M5 was designed for simple setup: there is no need to configure the M5 for the network, when used as a DLNA or UnPN device the server app will detect it as a compatible device to play to. That’s it.
The same goes for Roon as the idea of Roon Ready is to take away this kind of concern, have it ready to play to, so the device is known by the app and shows up ready to use. We currently don’t have a way to assign an ID as we have not found the need, but we’ll look into it.
-
The M5 software is updated with a mini SD card.
-
Roon software is done over the network as per Roon spec. We have the M5 running the RAAT protocol and are in the final official certification stage with the good people over at Roon.
-
Rendering is done completely in the M5 and the advantage to do this is the player is the M5 not the host computer. The host computer is just feeding the data to the M5 from anywhere in the network it is stored, we see this as a great advantage of the M5.
-
No additional driver is needed for the M5.
-
The USB section and the complete renderer is powered by our linear power supply so there is no reason to isolate it as there is no computer and switching power supplies to isolate it from in the M5. This is the reason why we made the M5 complete with a linear supply and USB power derives directly from the linear supply at 5V. in a PC you have switch mode regulators that take the 19V and regulate it for all that is needed in the computer, one of them is the 5V to power peripherals like the USB so the power has noise. Of course if that is still of some concern we isolate it in the M1 for that reason. The intention of this product is to take care of issues like power, but we find the advantage of the M5 is not to use USB but the AES or SPDIF to your DAC, then there are no issues with power and USB.
-
The USB section and the complete renderer in the M5 is powered by our linear power supply to eliminate the need from isolation as there is no computer with typical switching power supplies to isolate it from. In a PC you have switch mode regulators that take the 19V and regulate it for all that is needed in the computer, one of them is the 5V to power peripherals like the USB so the power has an abundance of noise. The intention of this product is to take care of issues like power but we find the true advantage of the M5 is the ability to access the passive audio connections of AES or SPDIF to your DAC, then there are no issues with power and USB.
1 Like
In reading the specs on the Bricasti site, I presume that using the AES or SPDIF to connect the M5 and DAC would limit the resolution and format of incoming audio data. Only the USB supports DxD & DSD. Therefore to support these the USB connection would be required. Correct?
Hello Damon,
I appreciate your reply.
A quick follow-up based on the answers you provided pertaining to item # 3 above:
I am a bit confused still on how the M5 is accomplishing this task. Based on the answer given I am led to believe that the M5 is running as a combined ROON Core & ROON Remote device. Is that correct?
My understanding of one of the many benefits offered by using a separate ROON Core & ROON Remote is that things like DSP Room Correction, Up sampling/Down sampling, Audio stream processing…etc all gets done on a piece of hardware far more “brawny/powerful” with lots of CPU/RAM and fast Local Disk more suited to handling that task. I know CPU and Disk access are biggies for the ROON DB and DSP from what I have seen.
In theory, having all these resource needs offloaded from the typically low powered ROON Remote/Endpoint will reduce CPU/RAM/DISK activity on that ROON Remote/Endpoint which is feeding and directly connected to the DAC.
Again, in theory, reducing the activity of all those previously listed resources on the ROOn Endpoint/Remote in turn reduces the load on its power supply which in turn reduces the heat build up within its chassis and ultimately is said to reduce the “noise output” to as low as possible on the device that attaches directly to the DAC.
On my ROON Core I have 32GB of RAM, the latest Intel i7 CPU and a Samsung NVMe M.2 SSD flash drive used for the ROON Database. If my understanding is correct with the response you have provided about where the heavy lifting is done while using an M5 with ROON then I’m curious how/why it could be considered a better work horse for the processing of audio streams data with the context here being as used with ROON? Its seems to go against the normal usage of the software.
Can you say what compute and disk resources the M5 has within its chassis that may be able to better the capabilities I have listed for my ROON Core example above?
In closing I will mention that I do like that the M5 is addressing the issues normally associated with powering most network audio players where multiple additional devices are needed each having its own power needs…etc. For me, this is a big win.
Thanks again for your time
I think in this case the term “render” refers to the conversion from packet-based network traffic to a USB connection and the Roon core is still remote running on the aforementioned beefier machine. Let’s see what he says.
Chris,
The M5 is an end-point renderer, so any digital signal processing of the audio i.e. up/down sampling or performing DSP room correction, EQ is all done on your Roon Core. The rendering portion performed by the M5 is done on our dedicated ARM processor so it does remove a small portion of processing from the core. In a purist approach where DSP is not involved, Roon core is simply spoon feeding the raw data from the network drive over to the M5 to render.
Damon,
OK so it sounds like we are getting closer to an explanation of what the M5 is doing in this ROON signal chain.
I’m willing to take into account that possible terminology differences are at play here which may be adding to at least my confusion so please keep that in mind while I am asking these questions.
The one piece of this puzzle that I feel is still unclear is where the “decoding” of the source audio file is being done while using the M5. If I have a .wav file sitting on a NAS drive that the ROON Core is pointing to and I select Play to listen to that track some device (ROON Core or the M5) needs to decode that .wav file into a PCM or DSD stream before it can be handed off to the renderer/endpoint/DAC.
In my understanding of what would normally happen in a ROON implementation, the ROON Core would “decode” that .wav file and then stream either PCM or DSD to the renderer/endpoint to then hand off to the DAC.
I am also aware that there are renderer/endpoints out there on the market which can “decode” a .wav file sitting on a NAS device directly without any existence of a ROON Core or ROON anything.
The two things that you mention (one in your first reply and another in your last) that are throwing me off are these to points that you say the M5 is or is doing:
-
“when used as a DLNA or UnPN device the server app will detect it as a compatible device to play to. That’s it”
-
“Roon core is simply spoon feeding the raw data from the network drive over to the M5 to render”
The first item mentions DLNA or UnPN which as far as I am aware are not supported in ROON. Unless things have changed that I am not aware of but the last post I read by a ROON staffer mentioned all the reasons why UnPN or DLNA would not be supported.
For the second item, if the M5 is just using the ROON Core as a “passthru” to receive the RAW 1’s & 0’s that make up the source .wav file sitting on the NAS drive then that means the M5 is doing the “decoding” and the “rendering” which is not typical as far as my understanding goes about what the ROON Core does and if that is the case then this decoding can start to shift the balance of potentially resource intensive activities to a device that may not be best suited to handle them.
I promise, I am almost done bugging you. Who knows, I may even purchase an M5 soon if I like what I hear 
Thanks again
No problem Chris and glad to shed some light on this topic.
The M5 is decoding the audio files and is dedicated to this task. For an example, we decode / play .wav files directly and do so for most all of about 100 common file types, DFF, AIFF, FLAC, ape etc. They’re not resampled to other formats like DSD, they are directly decoded and played in the original format in the M5. If the source is .wav on the drive and the server sends that file data unaltered we will play it and decode it natively. Or for example if the core / server modifies it to an MP3, then we decode and play that. In the best or least modified playback chain the files are simply passed from the storage drive to the M5 by the server / core unaltered and we do the decoding and real time audio streaming or play back.
It works the same for Roon using their RAAT protocol or other apps with DLNA. Of course Roon does not support DLNA, this is only an example of how the M5 works as a renderer with different apps.
The latest version does DSD 64 and DSD 128 over the USB output. Other outputs are “limited” to 24/192. Do you really need output at a resolution above DSD 128?