Sonore microRendu

[vortecjr]

Leave the intellectual property out of it. I'm not looking for secrets. I want to know what it actually does. Asking whether it changes the data packet in any way doesn't give away intellectual property. The physical components of the device speak for themselves. I'd like to know what the software is doing to the packets if anything at all.

 

This is complex project made up of open source and closed source components. There are also agreements in place with some of the developers so there is only so much we can talk about. I can tell you we are not intentionally changing anything. Our job is to receive the data from a remote server and pass it along to your DAC.

[Johnseye]

This is complex project made up of open source and closed source components. There are also agreements in place with some of the developers so there is only so much we can talk about. I can tell you we are not intentionally changing anything. Our job is to receive the data from a remote server and pass it along to your DAC.

 

Thanks for the response. When you say you're not intentionally changing anything I have to assume you're referring to the packets as the intention of the device itself is to change something. Also assuming that's the noise, I'll interpret that as the software is not making any changes to the data input source at the packet level. If the packets aren't being modified then noise filtering is the only benefit provided by the microRendu.

 

Sorry to be trying to read into what's actually being done by the device, but I was hoping for some detail. When I get it I expect I'll hear what it does, and hope the data packets aren't being modified unintentionally.

[firedog]

Leave the intellectual property out of it. I'm not looking for secrets. I want to know what it actually does. Asking whether it changes the data packet in any way doesn't give away intellectual property. The physical components of the device speak for themselves. I'd like to know what the software is doing to the packets if anything at all.

 

As far as I can tell, the device isn't changing anything. It's a low noise device that only does audio related functions - and only the ones needed for whichever of it's modes it is in. It does have USB "cleanup/regeneration" similar to a USB Regen, but that's also not changing the packets, if I understand what you are asking.

So low noise, and clean, regulated power for the USB.

[vortecjr]

Thanks for the response. When you say you're not intentionally changing anything I have to assume you're referring to the packets as the intention of the device itself is to change something. Also assuming that's the noise, I'll interpret that as the software is not making any changes to the data input source at the packet level. If the packets aren't being modified then noise filtering is the only benefit provided by the microRendu.

 

Sorry to be trying to read into what's actually being done by the device, but I was hoping for some detail. When I get it I expect I'll hear what it does, and hope the data packets aren't being modified unintentionally.

 

I think you won't be satisfied until I tell you that we can make the fat lady sing better than she really can by manipulating network packets:)

 

One benefit which you leave out when use the word "ONLY" is that the microRendu allows streaming from a remote source in the first place. That in itself is a major feature of the product. This idea being that you can use a standard computer or NAS and you don't need a full blown computer in the audio room.

[Johnseye]

I think you won't be satisfied until I tell you that we can make the fat lady sing better than she really can by manipulating network packets:)

 

One benefit which you leave out when use the word "ONLY" is that the microRendu allows streaming from a remote source in the first place. That in itself is a major feature of the product. This idea being that you can use a standard computer or NAS and you don't need a full blown computer in the audio room.

 

I actually don't want the packets changed. Well, not unless it makes things sound like the musicians are playing right in front of me. I'm a purist and unless the sound was modified on the A to D conversion, I want to hear the same way it was played by the musicians.

 

The tiny footprint of the device, providing an ethernet to USB interface is a benefit, and part of the reason I bought it. You still need another computer running the media server however. I take it there's no way to isolate the noise generated from the computer unless it's a completely separate device? The sonicTransporter is the other piece to this and I will assume SGC has put some attention to the components. I would buy the sT if it had a little more under the hood. Any plans to build a custom device like the sT that can host JRiver and HQPlayer, or is that more of a question for Andrew Gillis?

[ElviaCaprice]

Looks like your not getting any answers, Johnseye. Glad your asking. With that I shall remain on the sideline with mR. If you can't understand it, stay away, plus it doesn't fulfill me media needs. Although I may go back to trying HQP for audio along with JRiver for video. Meanwhile looking for clear better direct USB solutions for all media playback.

 

More importantly, that PC should be powered properly, that is the current limitation.

[tboooe]

I'd also like to stream my library outside of my home LAN and JRiver is the only thing I've found that can do it.

A little off topic but check out Subsonic. I've been using that to stream my music to my phone or any computer from the internet for 5 years now! There is a very good mobile app called Dsub. You can also share your music library with people so they can listen too via a username and password. It even allows you to upload files to your library remotely too.

[Johnseye]

Looks like your not getting any answers, Johnseye. Glad your asking. With that I shall remain on the sideline with mR. If you can't understand it, stay away, plus it doesn't fulfill me media needs. Although I may go back to trying HQP for audio along with JRiver for video. Meanwhile looking for clear better direct USB solutions for all media playback.

More importantly, that PC should be powered properly, that is the current limitation.

I got a better explanation in another post. John S. clearly explains what the mRendu is doing. I think you'll find it helpful.

 

http://www.computeraudiophile.com/f10-music-servers/microrendu-nuc-jriver-and-roon-31537/index2.html

[vortecjr]

I moved the server posts to this thread:

http://www.computeraudiophile.com/f26-sonore-sponsored/sgc-roonify-your-universal-serial-bus-industry-standard-cables-connectors-and-communications-protocols-between-computers-and-electronic-devices-drive-or-network-attached-storage-sonictransporter-28288/index10.html

[hicr49]

Hi Jesus,

I would like to know if there's anyway I can use a "dual end" USB cable (such as an Audience au24 dual end Usb cable where its power and data are separated into two connectors) with mRendu? My DAC works fine with just connecting the data end directly to the computer but it will not work with my mRendu when just connecting the data end. Is there any work around with such cable and mRendu? Thanks.

[JohnSwenson]

Leave the intellectual property out of it. I'm not looking for secrets. I want to know what it actually does. Asking whether it changes the data packet in any way doesn't give away intellectual property. The physical components of the device speak for themselves. I'd like to know what the software is doing to the packets if anything at all.

 

The only data change that would be happening in the microRendu itself is volume control. The control app can tell the player what volume to use, if you set the volume to 100% no change happens to the audio data.

 

If the volume is set to less than 100% exactly what happens is determined by the output mode you are using (ie the network audio protocol you are using) and your DAC. Some DACs will tell the software that they can control the volume, in which case the microRendu does not change the audio data but sends the volume level to the DAC and lets IT apply the volume setting. If the DAC does not tell the microRendu that it can do this, the particular software for the chosen mode will do the volume operation.

 

John S.

[Johnseye]

The only data change that would be happening in the microRendu itself is volume control. The control app can tell the player what volume to use, if you set the volume to 100% no change happens to the audio data.

 

If the volume is set to less than 100% exactly what happens is determined by the output mode you are using (ie the network audio protocol you are using) and your DAC. Some DACs will tell the software that they can control the volume, in which case the microRendu does not change the audio data but sends the volume level to the DAC and lets IT apply the volume setting. If the DAC does not tell the microRendu that it can do this, the particular software for the chosen mode will do the volume operation.

 

John S.

Thanks again John. I always have my software volume set to 100% so no concerns.

Can you explain how the microRendu differs from the LANRover if you're familiar with that device? Both provide separation from the media server via ethernet. The microRendu offers a media server endpoint and I would suspect added filters as you've explained in the other thread, but I don't know what kind of filtration the LANRover provides other than the separation.

[ted_b]

Johnseye, please do not discount the microRendu's renderer capabilities. You keep asking to compare it against filters and reclockers (like LANRrover) but it is an actual ethernet endpoint for Roon, Squeezebox, HQplayer NAA, and a DLNA or MPD renderer. Yes, it has a USB interface built from the ground up, but it replaces a renderer such as a laptop or other computer renderer device. That is no small task! You'd still need to buy a renderer if using a LANRrover.

[Johnseye]

Johnseye, please do not discount the microRendu's renderer capabilities. You keep asking to compare it against filters and reclockers (like LANRrover) but it is an actual ethernet endpoint for Roon, Squeezebox, HQplayer NAA, and a DLNA or MPD renderer. Yes, it has a USB interface built from the ground up, but it replaces a renderer such as a laptop or other computer renderer device. That is no small task! You'd still need to buy a renderer if using a LANRrover.

Based on what I've read, the LANRover converts the signal from USB to ethernet and back to USB. It's just passing the media server data, regenerating, "cleaning" and reclocking it, to the DAC. I don't see any mention of a need for a renderer beyond the media server itself. I'm being simplistic and know very little about the LANRover, but don't want to get into a discussion about it specifically. I'm just wondering what the differences are between it and the microRendu. I already pointed out that it has an endpoint, so I'm not discounting that.

[ted_b]

Wait, you asked how it is different, but don't want to discuss the renderer side. Hmm...where would you run a DLNA renderer if you had a LANRover? Or an HQPlayer NAA? The comparison seems apples and oranges, or more accurately like comparing a Porsche 911 to a Cleveland 500 engine. One is a full automobile, the other is simply a very powerful engine, maybe even more powerful than the 911 engine, but requires lots more hardware to make it an actual car.

[Johnseye]

Wait, you asked how it is different, but don't want to discuss the renderer side. Hmm...where would you run a DLNA renderer if you had a LANRover? Or an HQPlayer NAA? The comparison seems apples and oranges, or more accurately like comparing a Porsche 911 to a Cleveland 500 engine. One is a full automobile, the other is simply a very powerful engine, maybe even more powerful than the 911 engine, but requires lots more hardware to make it an actual car.

I didn't want to discuss the LANRover because I wanted to focus on the microRendu and didn't want Jesus to cut this out of the thread which was done the last time conversation got off topic.

 

Why couldn't the media server/host/PC/Mac/Core send the music straight to the DAC? Why is another renderer or end point even needed?

[JohnSwenson]

Based on what I've read, the LANRover converts the signal from USB to ethernet and back to USB. It's just passing the media server data, regenerating, "cleaning" and reclocking it, to the DAC. I don't see any mention of a need for a renderer beyond the media server itself. I'm being simplistic and know very little about the LANRover, but don't want to get into a discussion about it specifically. I'm just wondering what the differences are between it and the microRendu. I already pointed out that it has an endpoint, so I'm not discounting that.

 

The LANRover takes USB audio packets in, takes the audio data out of the packets, puts the audio data into an Ethernet packet and puts the packet on the wire. The other side does the reverse, it reads in the Ethernet packet, strips out the audio data, puts it in a USB audio packet and sends that out over the wire. That's it. Both the USB and Ethernet streams in this case are just audio data. Because both the input and output are USB, it doesn't have to actually look at the data or know anything about it, it just copies the USB audio data from one end to the other. It doesn't have to know what the sample rate is, what the bit depth is or anything else bout it, it doesn't have to know how to read USB audio format, it just copies over whatever is at the input to the output.

 

The microRendu reads network audio protocols that are much more complex. They are not just a stream of audio data, there is a lot more in there, this takes a more complex program to read the protocol and extract the audio data out of it. The complexity is not in altering the data, it is in reading a more complex stream that has a lot of other stuff in there so it can find the actual embedded audio data and extract it. It has to know how to fully read the protocol, extract the samples, then format them as a USB audio stream. This is a WAY more complex task.

 

The different protocols are very different so exactly what has to happen in the microRendu varies radically from protocol to protocol, which is why they are implemented as separate programs.

 

The term "render" seems to trip people up and means different things to different people. For AUDIO, it mostly means extracting the audio from the network protocol and maybe applying volume changes, that is it. For VIDEO the renderer is usually doing significantly more stuff. How much work it takes to read the protocol and extract audio data varies from protocol to protocol, some simple, some complex. I personally hardly ever use the term because it is so vague.

 

 

John S.

[barrows]

I didn't want to discuss the LANRover because I wanted to focus on the microRendu and didn't want Jesus to cut this out of the thread which was done the last time conversation got off topic.

 

Why couldn't the media server/host/PC/Mac/Core send the music straight to the DAC? Why is another renderer or end point even needed?

 

One can do this, of course. The point of using a purpose built renderer like the µRendu is that you remove very noisy consumer grade commercial computer products from the vicinity of the high end audio system. When you remove the very noisy consumer grade computer products from the vicinity of the audio system, you achieve much better sonic performance from the audio system.

Sonore started out by making high end custom servers, and the server got more and more sophisticated (addition of specialized USB audio cards, specialized power supplies, specialized OS) all in the name of increasing sonic performance, mostly through the reduction of noise. But ultimately, getting the noisy consumer grade computer stuff physically away from the audio system made for an even bigger step up in performance. With µRendu in the audio system, all the ordinary consumer computer gear can be located far away from the audio system (hopefully on the opposite phase of the AC wiring as well) where its inherent electrical noise will not affect the audio system.

The reason for the existence of the µRendu is to improve sound quality, in addition to providing a very flexible endpoint capable of operating in a number of different modes to suit the needs and preferences of different users.

[Johnseye]

The LANRover takes USB audio packets in, takes the audio data out of the packets, puts the audio data into an Ethernet packet and puts the packet on the wire. The other side does the reverse, it reads in the Ethernet packet, strips out the audio data, puts it in a USB audio packet and sends that out over the wire. That's it. Both the USB and Ethernet streams in this case are just audio data. Because both the input and output are USB, it doesn't have to actually look at the data or know anything about it, it just copies the USB audio data from one end to the other. It doesn't have to know what the sample rate is, what the bit depth is or anything else bout it, it doesn't have to know how to read USB audio format, it just copies over whatever is at the input to the output.

 

The microRendu reads network audio protocols that are much more complex. They are not just a stream of audio data, there is a lot more in there, this takes a more complex program to read the protocol and extract the audio data out of it. The complexity is not in altering the data, it is in reading a more complex stream that has a lot of other stuff in there so it can find the actual embedded audio data and extract it. It has to know how to fully read the protocol, extract the samples, then format them as a USB audio stream. This is a WAY more complex task.

 

The different protocols are very different so exactly what has to happen in the microRendu varies radically from protocol to protocol, which is why they are implemented as separate programs.

 

The term "render" seems to trip people up and means different things to different people. For AUDIO, it mostly means extracting the audio from the network protocol and maybe applying volume changes, that is it. For VIDEO the renderer is usually doing significantly more stuff. How much work it takes to read the protocol and extract audio data varies from protocol to protocol, some simple, some complex. I personally hardly ever use the term because it is so vague.

 

 

John S.

Thanks again John. In my realm rendering has typically related to video or graphics. I had to make the translation to audio. Good to know it exactly what it's doing in the audio realm. If both devices are extracting the audio data, is the difference that the mRendu analyzes the packet data to present it to the Roon or other applications running on the mRendu?

[JohnSwenson]

I didn't want to discuss the LANRover because I wanted to focus on the microRendu and didn't want Jesus to cut this out of the thread which was done the last time conversation got off topic.

 

Why couldn't the media server/host/PC/Mac/Core send the music straight to the DAC? Why is another renderer or end point even needed?

 

Most of the protocols are complex because they had rampant creeping featurism. They want to do everything. The essentials for audio are the actual audio samples, but that alone is not all that useful, you also need to know the sample rate and bit depth, so that has to come at the beginning of each track, but that then means you need to have the concept of "track", which then morphed into sending track data, such as name, album, artist, then once you had that why not a picture of the album cover art, then information such as how long the track is and where the current play time is in the length of the track.

 

Network players had displays that could display all this so the protocols got increasingly complex. Then with the advent of smart phones things went the other way and people wanted to use the phones as the control and display and the "renderer" became a black box. But the protocol stayed the same with all the complexity.

 

There are some new protocols which are designed to be used with black box players (such as NAA) but they are nowhere near as widespread as the complex protocols.

 

John S.

[ted_b]

One can do this, of course. The point of using a purpose built renderer like the µRendu is that you remove very noisy consumer grade commercial computer products from the vicinity of the high end audio system. When you remove the very noisy consumer grade computer products from the vicinity of the audio system, you achieve much better sonic performance from the audio system.

Sonore started out by making high end custom servers, and the server got more and more sophisticated (addition of specialized USB audio cards, specialized power supplies, specialized OS) all in the name of increasing sonic performance, mostly through the reduction of noise. But ultimately, getting the noisy consumer grade computer stuff physically away from the audio system made for an even bigger step up in performance. With µRendu in the audio system, all the ordinary consumer computer gear can be located far away from the audio system (hopefully on the opposite phase of the AC wiring as well) where its inherent electrical noise will not affect the audio system.

The reason for the existence of the µRendu is to improve sound quality, in addition to providing a very flexible endpoint capable of operating in a number of different modes to suit the needs and preferences of different users.

 

+1 Moreover, in my case I purposefully built a very powerful and somewhat noisy (not really, but wasn't a concern) main server to do heavy lifting for HQPlayer (lots of upsampling, etc). Luckily, I did this knowing that it would not only be away from my listening room (thanks to HQP's NAA architecture), but electrically isolated too. So the microRendu acts as the NAA, housing simply a Linux driver (I also have a Windows-based NAA for those dacs that don;t agree with UAC2 Linux; in this Windows world they are also isolated and small, housing simply the NAA executable and a list of DAC ASIO drivers, once again using minimalism as a value add). Other Linux NAAs were available, but I chose the microRendu especially because they took huge care of the USB handshake. It didn't hurt that the microRendu can also serve as a DLNA renderer if needed (running control points Like Kazoo on my iPad), or Roon endpoint. But the HQPlayer NAA capability sealed it.

[jaapdeventer]

. If both devices are extracting the audio data, is the difference that the mRendu analyzes the packet data to present it to the Roon or other applications running on the mRendu?

 

You should keep the functions server, control point and renderer apart.

 

A pc can be all three. For example using iTunes and connecting pc usb to dac.

 

MicroRendu reliefs the pc from the rendering task. As dedicated renderer microRendu is very successful. It sounds much better than most pc's and most other renderers.

 

Like me using a dedicated renderer you can leave the pc out of the chain and use a NAS (as server) instead.

 

In any of the above options you can add usb isolation in the chain.

 

Unless you already own a very optimized audio pc I would put my money on microRendu. In fact I did and I'm very happy with the result.

 

Synology NAS, LPS-1, microRendu, Job INTegrated, Penaudio Cenya.

[Johnseye]

One can do this, of course. The point of using a purpose built renderer like the µRendu is that you remove very noisy consumer grade commercial computer products from the vicinity of the high end audio system. When you remove the very noisy consumer grade computer products from the vicinity of the audio system, you achieve much better sonic performance from the audio system.

Sonore started out by making high end custom servers, and the server got more and more sophisticated (addition of specialized USB audio cards, specialized power supplies, specialized OS) all in the name of increasing sonic performance, mostly through the reduction of noise. But ultimately, getting the noisy consumer grade computer stuff physically away from the audio system made for an even bigger step up in performance. With µRendu in the audio system, all the ordinary consumer computer gear can be located far away from the audio system (hopefully on the opposite phase of the AC wiring as well) where its inherent electrical noise will not affect the audio system.

The reason for the existence of the µRendu is to improve sound quality, in addition to providing a very flexible endpoint capable of operating in a number of different modes to suit the needs and preferences of different users.

 

 

Yes, but the LANRover allows for this as well, so no differences between the two to note on that topic.

 

+1 Moreover, in my case I purposefully built a very powerful and somewhat noisy (not really, but wasn't a concern) main server to do heavy lifting for HQPlayer (lots of upsampling, etc). Luckily, I did this knowing that it would not only be away from my listening room (thanks to HQP's NAA architecture), but electrically isolated too. So the microRendu acts as the NAA, housing simply a Linux driver (I also have a Windows-based NAA for those dacs that don;t agree with UAC2 Linux; in this Windows world they are also isolated and small, housing simply the NAA executable and a list of DAC ASIO drivers, once again using minimalism as a value add). Other Linux NAAs were available, but I chose the microRendu especially because they took huge care of the USB handshake. It didn't hurt that the microRendu can also serve as a DLNA renderer if needed (running control points Like Kazoo on my iPad), or Roon endpoint. But the HQPlayer NAA capability sealed it.

You do realize the LANRover is designed to isolate the media server from the DAC right? That's its entire purpose. I'm just trying to understand the difference between the two devices. I have never said I like one over the other. In fact I bought a microRendu. John clarified some of the differences, but they both provide separation from the media server that's doing the heavy lifting, upsampling, crunching the numbers, creating all the noise.

 

MicroRendu reliefs the pc from the rendering task. As dedicated renderer microRendu is very successful. It sounds much better than most pc's and most other renderers.

Unless you already own a very optimized audio pc I would put my money on microRendu. In fact I did and I'm very happy with the result.

I do have a very optimized, dedicated audio PC. Not sure I see any benefit in an endpoint render over a PC media server render. As John S. just explained, an audio render mostly means extracting the audio from the network protocol and maybe applying volume changes, that is it.

[vortecjr]

Johnseye this not the place to seek out comparisons between the microRendu and the LANRover. We know a lot about it and there also a lot we don't know about it. However, that does not mean that we are prepared to critic it or compare it for you in an open forum. If you want to know more about the LANRover you should ask PS Audio. The specifications for the microRendu are on our website. If there is anything about them that is not clear perhaps we can discuss them here. In short, the microRendu is a renderer and an endpoint for various streaming applications. The microRendu is a Roon to DLNA bridge (bata) and a server. The microRendu works in combination with a computer, NAS or mobile device. The microRendu is an Ethernet to USB interface.

[Johnseye]

Johnseye this not the place to seek out comparisons between the microRendu and the LANRover. We know a lot about it and there also a lot we don't know about it. However, that does not mean that we are prepared to critic it or compare it for you in an open forum. If you want to know more about the LANRover you should ask PS Audio. The specifications for the microRendu are on our website. If there is anything about them that is not clear perhaps we can discuss them here. In short, the microRendu is a renderer and an endpoint for various streaming applications. The microRendu is a Roon to DLNA bridge (bata) and a server. The microRendu works in combination with a computer, NAS or mobile device. The microRendu is an Ehtenet to USB interface.

I get it Jesus, I tried to stay on topic with the microRendu if you read my posts. I appreciate your, and John S's input.