I was not referring to your product, I was referring to DLNA. As far as I know the DAC does not own the clock when DLNA is utilised.
yup: never got that part about RAAT and DAC
there are three devices between my Roon Server and DAC, each one doing its own reclocking and… RAAT bypasses them all and only “trusts” the DAC (that it doesn’t even see)? :-/
(devices are a RoonReady device, a USB Regen and an S/PDIF converter)
This is the microRendu General Thread after all and I already said that this is not true. The Sonore Signature Series Rendu is a DLNA renderer and it is an asynchronous end point. The microRendu also properly works with asynchronous USB DACs in DLNA/MPD output mode.
SONORE computer audio - Rendu | microRendu | Sonicorbiter SE
You are mixing things up. RoonReady devices and Regens are not re-clockers. Chances are your USB SPDIF converter is not a re-clocker either, but it could be. Anyway, none of this has to do with the streaming protocol. Also, it does not appear to be related to the microRendu so please start new thread.
SONORE computer audio - Rendu | microRendu | Sonicorbiter SE
1 Like
My statement was in reference to:[quote=“fritzg, post:142, topic:8219, full:true”]
I get that DACs have different sounds, they are after all “converters”. But the others are just transports. How does the software protocol change the sound?[/quote]
He is talking about Airplay and Songcast. He then says, “In the case of your Linn devices in a linked situation, the clock is owned by the DS, but that’s because you are still using UPnP instead of Songcast to get media into the Linn DS”
SONORE computer audio - Rendu | microRendu | Sonicorbiter SE
It actually does have to do with the Rendu. I still don’t understand how the streaming protocol produces a different bit perfect sound with the Rendu.
Some are claiming sound quality improvements while using Roon and HQ Player (with bit perfect setup) with the microRendu in NAA output mode. If you compare Roon with the microRendu in RoonReady output mode to Roon / HQ player with the microRendu in NAA output mode you will notice two things: 1. The microRendu hardware is fixed. 2. The mciroRendu output protocol used is variable. I did not write either protocol so I can’t comment as to why they might sound different.
SONORE computer audio - Rendu | microRendu | Sonicorbiter SE
Well, we know that HQ Player upsamples and uses user-defined filters on the software end before it reaches the DAC. It’s my understanding Roon and DLNA are both transport protocols and don’t alter the music as HQplayer does, so it is still a question as to why there is a difference in sound quality between Roon and DLNA on the Rendu.
HQ Player can do that, but that is not what I said. What I said was, “…HQ Player (with bit perfect setup)…”
SONORE computer audio - Rendu | microRendu | Sonicorbiter SE
Hey Everyone,
Just a friendly reminder to keep the discussion about microRendu.
If you want to go off topic, feel free to start a new thread.
Cheers, Greg
Thanks. I thought I was keeping the subject about the Rendu. The review Sonore’s founder posted is the one that claimed a sonic difference with Rendu when comparing DLNA to RAAT.
I do agree with @Jesus_Rodriguez here. Even though I’d love to agree wtih an article that puts Roon in a favorable light, I’m unsure what’s going on.
That said, I am willing comment on this why they might sound different: people hear what they want to hear.
If you get the bits to the microRendu accurately, and you do it in a way that pulls the content so the device owns the clock (Roon Ready, UPnP, and “bit-perfect HQP NAA” all pull in the only way that matters), and the bits are the same, then all should sound the same.
There are complexities here, but it’s all completely unknown without real forensic analysis … which no one is doing.
Finally, the reviewer in this case states:
After about a month, I switched over to the Roon protocol, simply by downloading and installing Roon on my Mac Mini, and switching over to the Roon app on the microRendu. The last piece of the puzzle was getting the Roon app for the iPad Air. My overall impression is Roon was slightly superior to DLNA sonically. It was not a landslide, there was just a bit more refinement to my ears. This may be due to the way Roon supposedly simplifies the audio chain, as many claim DLNA is a complicated protocol. I stuck with Roon, and continue to use it.
(I’ve bolded the part I think is most important)
When I read this, I take this meaning “The experience was better with Roon, the sound was still perfect, my overall happiness was greater, it might be ears or my brain but i don’t know… I just know I like what I hear… I’m sticking to it.”
The best thing is to take all reviews with a grain of salt and try it out yourself.
The microRendu does a lot of great things that are well known to lead to better audio reproduction.
Try it out! It is an awesome product and I doubt you will feel any other way about it yourself once you’ve lived with one.
1 Like
Not wishing to sound like a troll, but could you elaborate on this please? No offense to Jesus, but I’m genuinely interested to hear an expert independent view on why the mR could be a £500 (plus £££ psu) upgrade from my existing RPi3 running Roon Bridge. Thanks.
1 Like
I’m not familiar with your equipment, but I am extremely happy with the sound quality performance of the microRendu. I also have a Bryston BDP-1 and IMO the microRendu is as good as or better than the retrofitted Bryston. Both are darn good. There are a couple of extensive reviews on the microRendu out there. At the price, a game changer.
http://www.computeraudiophile.com/content/705-sonore-microrendu-review-part-2/
http://www.computeraudiophile.com/content/698-sonore-microrendu-review-part-1/
1 Like
Thanks Robert. I’ve read quite a bit about the mR from various sources (including CA) and I’m old & ugly enough to take such things with a dose of salt most of the time (confirmation bias is a powerful thing). I’m not saying it isn’t a wonderful device (I’ve not heard it), but the cost of mR + worthwhile PSU doesn’t allow a casual suck-it-and-see approach, it’s just too expensive for that (for me), particularly when my existing (inexpensive) RPi3 offers excellent performance in my fairly revealing headphone system.
I’d love to do an A/B test of mR v RPi3 and if the mR is significantly better then I’ll be only too happy to put my hand in my pocket, but I don’t see how I’d get that opportunity. Which brings me back to @danny’s statement that “The microRendu does a lot of great things that are well known to lead to better audio reproduction.”. I’m genuinely interested in what these things are 
3 Likes
The Hardware Details section in part 1 of Chris Connaker’s review linked above sets out the various design features intended to improve audio reproduction in the mR.
I’ve enjoyed having the mR in my system, and think it has benefitted from a good burn in, but I’m very suspicious of confirmation bias and couldn’t say that the difference between the previous CuBox and the mR was jaw dropping. An incremental improvement at most for me. I’m only using the iFi linear PS however.
Edit: As Jesus points out below, the iFi is an SMPS supply, not linear.
2 Likes
Thanks for the honest reply, Andy
The microRendu works well with the $50 iFi power supply. The device is a dandy even with the low end supply. If you are satisfied with your Roon ready device - no need to change. I bought the uRendu when Bryston was trying to figure out the Roon RAAT certification, otherwise I probably would have stuck with only the Bryston as a Roon endpoint. I’m happy with both units and utilize both of them. One other point on the uRendu is the ability to use HQPlayer NAA mode to shape, filter, and upsample. You can make stuff sound better (or worse) using HQPlayer, depending on your settings.
1 Like
@Jesus_Rodriguez can elaborate more than I can, but the things I saw immediately:
- not using an overpowered (noise) or underpowered CPU (dropouts)
- using a well known, tested, and supported SoC (iMX6)
- no wifi (more reliable networking, less noise)
- multiple levels of isolation between the power and the noise critical ICs – the PHY and USB
- using an external clock (as opposed to sharing one with the CPU)
- disabling stuff normally that is normally on and idle on the reference system for that ARM board
- no switching power path to the USB – only uses switching for the CPU side of things
- the USB signal on it uses the same principles as many of the USB filters out there, but all built in. this is about as clean of a USB port as you will find
2 Likes