Microrendu vs SMS200

[Superdad]

SOtM's battery PSU mBPS-d2s is more or less tailor made to the sMS-200, and is stated at 9V/1.5A. Wouldn't that be a match with the mR as well? Battery power with these low power units seems like a glove-fit no less appealing than linear PSU's, and at a lower price.

 

Just to be clear, the SOtM mBPS-d2s base price of $450 is $55 higher than our UltraCap LPS-1, plus they charge a $17.55 fee for PayPal (UpTone does not, we absorb that), and their shipping charges are higher than ours.

There is also the cost to replace the batteries (their web site says once per year but I'm sure they last a bit longer than that).

 

What I find most odd, and maybe someone who owns one can clarify, is that the specifications for the mBPS-d2s say the output voltage ranges from 6V to 9V, but there are no switches to set that--inside or outside the supply as far as I can tell--nor is there discussion of that in the manual. So does the voltage just start out at 9V and drop to 6V as the battery discharges?

 

So far as I know, nobody has yet put an ammeter in line with the sMS-200 to see what it actually draws. At least a dozen people have sent us e-mails asking if our LPS-1 will handle the sMS-200, and the answer is "we still don't know."

[phusis]

6moons review of the sMS-200 (in conjunction with the battery PSU SOtM mBPS-d2s)

 

6moons audioreviews: SOtM sMS-200

[jaapdeventer]

Lousy review. As if sound quality isn't much of an issue with network players.

[davide256]

Lousy review. As if sound quality isn't much of an issue with network players.

+1

The reviewer appears to only have anecdotal knowledge of what happens with digital audio before it reaches a DAC, no actual practice

[tyvo]

So what happens to digital files before they reach the DAC?

[rickca]

Lousy review. As if sound quality isn't much of an issue with network players.

At least I didn't have to read this one 6times to figure out it was content-free.

[Pepsican]

So what happens to digital files before they reach the DAC?

 

 

It would depend on the audio chain. But let's assume we have a NAS, hooked up to a router, which has a UTP cable running to the SOtM device:

1. UPnP server picks up file selected in control point.
   
2. File gets send through ffmpeg for any processing (applying ReplayGain or conversion to WAV or L16).
   
3. File gets transmitted to router by server.
   
4. Router receives file, buffers it, reclocks the file when it send it on its way out.
   
5. SOtM receives file, buffers it, reclocks it.
   
6. The device interacts with the DAC and the DAC starts signalling what, when and how much data needs to be transferred. (assuming Asynchronous USB)
   
7. SOtM starts to process the file. This means it strips the container of its metadata and starts to assemble the LPCM bit stream.
   
8. The device interacts with the DAC and the DAC starts pulling in the bit stream.
   
9. The DAC buffers, reclocks, does sound modifications if it has filters, then converts to analogue.
   

 

Sure, the above is highly simplified and it is not meant as a technically accurate picture. But you get the idea that there is a lot going on.

[Audio_ELF]

File gets send through ffmpeg for any processing (applying ReplayGain or conversion to WAV or L16).

This is optional ... most servers don't do any processing on the file. ffmpeg is also only an example of the application which *may* do some processing.

File gets transmitted to router by server.

A "file" is not transmitted to a router. Network packets (in the abstract) are sent to a router. On an internal network though the network traffic won't even go anywhere near a "router"; a router is used to route data from one network (your home LAN) to another (the Internet "cloud").

 

Internal network traffic should only go through switches and (if on a wireless network) to a bridge device - now the switch, router and WiFi bridge might all be the same device. As far as the server is concerned, it is transmitting the data (not a file although the data is still in FLAC, WAV, etc. format) to the client; what happens between the network card of the server and the network card of the client is unknown by the server.

Router receives file, buffers it, reclocks the file when it send it on its way out.

Again, at this point it is no longer a file but data packets. Buffering is only momentary (unlike the next step) and done only to remove crashes when multiple devices are sending and receiving data at once and to allow the switch to read and decide the next step on the packet's journey. "Reclocking" is an irrelevant term here.

SOtM receives file, buffers it, reclocks it.

No, the SotM device receives the data packets, buffers them and reassembles them into a file. "Reclocking" is still an misused term here though should serve to indicate that the packets once received and assembled back into a "file" are independent from those sent by the server. This isn't the complete story though as the FLAC (or whatever) file can be started to be played before the complete file is received.

 

To use an over used (and not complete) analogy - if someone has a piece of paper with a number badly written on it, rings you up and read the number to you for you write it down; the number written on the piece of paper has as much to do with the original piece of paper as the file the SotM processes has to the file stored on the server.

Sure, the above is highly simplified and it is not meant as a technically accurate picture. But you get the idea that there is a lot going on.

That really is an understatement ... there is a lot going on yes ... but none of it is mystical or magical!

[tyvo]

Thanks!

Yes, I know a lot is going on for sure. The question was of course retorical in nature. What I meant was: What happens to the digital signal before conversion that has an actual measurable and audible difference?

 

2. File gets send through ffmpeg for any processing (applying ReplayGain or conversion to WAV or L16).

 

What? That one I was not aware of. As far as I know that does not happen in my system; NAS -> Computer/player -> DAC.

Replaygain is applied in the player if supported. And conversion to WAV - why? and I'm not sure you're right but I could be wrong

 

What could make an audible and measurable difference is noise from the computer output. But again, as I understand it, only if the DAC is badly isolated. Interesting points on that here:

 

Measurements of Sonore microRendu Streamer | Page 3 | Audio Science Review (ASR) Forum

 

It would depend on the audio chain. But let's assume we have a NAS, hooked up to a router, which has a UTP cable running to the SOtM device:

1. UPnP server picks up file selected in control point.
   
2. File gets send through ffmpeg for any processing (applying ReplayGain or conversion to WAV or L16).
   
3. File gets transmitted to router by server.
   
4. Router receives file, buffers it, reclocks the file when it send it on its way out.
   
5. SOtM receives file, buffers it, reclocks it.
   
6. The device interacts with the DAC and the DAC starts signalling what, when and how much data needs to be transferred. (assuming Asynchronous USB)
   
7. SOtM starts to process the file. This means it strips the container of its metadata and starts to assemble the LPCM bit stream.
   
8. The device interacts with the DAC and the DAC starts pulling in the bit stream.
   
9. The DAC buffers, reclocks, does sound modifications if it has filters, then converts to analogue.
   

[tyvo]

This is optional ... most servers don't do any processing on the file. ffmpeg is also only an example of the application which *may* do some processing.

 

A "file" is not transmitted to a router. Network packets (in the abstract) are sent to a router. On an internal network though the network traffic won't even go anywhere near a "router"; a router is used to route data from one network (your home LAN) to another (the Internet "cloud").

 

Internal network traffic should only go through switches and (if on a wireless network) to a bridge device - now the switch, router and WiFi bridge might all be the same device. As far as the server is concerned, it is transmitting the data (not a file although the data is still in FLAC, WAV, etc. format) to the client; what happens between the network card of the server and the network card of the client is unknown by the server.

 

Again, at this point it is no longer a file but data packets. Buffering is only momentary (unlike the next step) and done only to remove crashes when multiple devices are sending and receiving data at once and to allow the switch to read and decide the next step on the packet's journey. "Reclocking" is an irrelevant term here.

 

No, the SotM device receives the data packets, buffers them and reassembles them into a file. "Reclocking" is still an misused term here though should serve to indicate that the packets once received and assembled back into a "file" are independent from those sent by the server. This isn't the complete story though as the FLAC (or whatever) file can be started to be played before the complete file is received.

 

To use an over used (and not complete) analogy - if someone has a piece of paper with a number badly written on it, rings you up and read the number to you for you write it down; the number written on the piece of paper has as much to do with the original piece of paper as the file the SotM processes has to the file stored on the server.

 

That really is an understatement ... there is a lot going on yes ... but none of it is mystical or magical!

 

You beat me to it

[Holzohr]

Just a comment regarding PS;

The Uptone LPS-1 cannot be used to drive the SOtM-200 even if it can be run as low 6.5VDC (7VDC output from the LPS-1). The reason is that it pulls more than the max. allowed 1.1A. The nominal power consumption is rated to 15W.

This favors the üRendu to some extent.

 

It is by no means certain yet that the LPS-1 can't power an sMS-200. While the standard PS that comes with the sMS-200 may be rated at 15W, that tells us nothing about what the unit draws.

 

For example, our REGEN comes with a 22 watt/2.93 amp PS, but in reality draws between 0.05A-0.6A (depending upon the VBUS draw of the DAC). And I personally measured a microRendu's DC draw at about 0.4A.

 

So until someone either tries an LPS-1 with the sMS-200 or simply measures its actual DC draw (quite easy with a DC barrel plug extension cable cut in the middle to insert an ammeter/multimeter), nobody knows if an UltraCap LPS-1 can be used or not with the SOtM device.

 

 

Sorry for the amateur clip. I use my sMS-200 just as a Roon endpoint. So, no USB drives hooked. In this mode it draws a bit more than 0.03A (when the sMS-200 is booting it draws up to 0.14something A). The power consumption is about 3.6 -3.9W. Hope that helps a bit.

 

Mario

[tedwoods]

It's a pity the 6moons reviewer didn't test the sms-200 with HQ player as it sounds amazing through it!

 

Sent from my eSTAR BEAUTY HD Quad core using Computer Audiophile mobile app

[davide256]

This is optional ... most servers don't do any processing on the file. ffmpeg is also only an example of the application which *may* do some processing.

 

A "file" is not transmitted to a router. Network packets (in the abstract) are sent to a router. On an internal network though the network traffic won't even go anywhere near a "router"; a router is used to route data from one network (your home LAN) to another (the Internet "cloud").

 

Internal network traffic should only go through switches and (if on a wireless network) to a bridge device - now the switch, router and WiFi bridge might all be the same device. As far as the server is concerned, it is transmitting the data (not a file although the data is still in FLAC, WAV, etc. format) to the client; what happens between the network card of the server and the network card of the client is unknown by the server.

 

Again, at this point it is no longer a file but data packets. Buffering is only momentary (unlike the next step) and done only to remove crashes when multiple devices are sending and receiving data at once and to allow the switch to read and decide the next step on the packet's journey. "Reclocking" is an irrelevant term here.

 

No, the SotM device receives the data packets, buffers them and reassembles them into a file. "Reclocking" is still an misused term here though should serve to indicate that the packets once received and assembled back into a "file" are independent from those sent by the server. This isn't the complete story though as the FLAC (or whatever) file can be started to be played before the complete file is received.

 

To use an over used (and not complete) analogy - if someone has a piece of paper with a number badly written on it, rings you up and read the number to you for you write it down; the number written on the piece of paper has as much to do with the original piece of paper as the file the SotM processes has to the file stored on the server.

 

That really is an understatement ... there is a lot going on yes ... but none of it is mystical or magical!

 

but its all susceptible to less than ideal hardware performance or software processing defects..

[firedog]

 

 

What could make an audible and measurable difference is noise from the computer output. But again, as I understand it, only if the DAC is badly isolated. Interesting points on that here:

 

Measurements of Sonore microRendu Streamer | Page 3 | Audio Science Review (ASR) Forum

 

 

 

That ASR thread is highly controversial. Many of us think Amir simply doesn't know how to measure correctly.

 

In addition, "as I understand it, only if the DAC is badly isolated." is also not an agreed truth. Most people here have found that most DACs are affected by noise from the USB output on the computer.

[tyvo]

That ASR thread is highly controversial. Many of us think Amir simply doesn't know how to measure correctly.

 

In addition, "as I understand it, only if the DAC is badly isolated." is also not an agreed truth. Most people here have found that most DACs are affected by noise from the USB output on the computer.

 

Well, Amir's ability to measure is not for me to judge. But if you could enlighten me on, why you don't think he's applying proper method, it would be greatly appreciated.

 

Secondly, I did not put anything forward as a truth. Maybe it could well be that many DACs a not that well isolated.

 

"Most people here have found that most DACs are affected by noise from the USB output on the computer."

 

Don't get me wrong. I'm all for empirical data. Even more so when it's supported, just ever so slightly by some scientific method

[YashN]

Well, Amir's ability to measure is not for me to judge.

 

Don't get me wrong. I'm all for empirical data. Even more so when it's supported, just ever so slightly by some scientific method

 

There is a big conceptual gap between 'ever so slightly by some scientific method' and 'I saw these posts on a forum who has "science" in the domain name.

 

I would pay attention solely to John Kenny's post there if I were you and really interested in Science.

[tyvo]

There is a big conceptual gap between 'ever so slightly by some scientific method' and 'I saw these posts on a forum who has "science" in the domain name.

 

I would pay attention solely to John Kenny's post there if I were you and really interested in Science.

 

I think there isn't. If I see documentation for something, well explained and supported by reason, I will take it into account. Good documentation is good documentation no matter where it's put forth.

 

If you cook that thread down to something like, what John Kenny say is the truth, I believe you have have an angle.

 

This discussion might not be super relevant to the OP. Sorry for that.

[Superdad]

 

Sorry for the amateur clip. I use my sMS-200 just as a Roon endpoint. So, no USB drives hooked. In this mode it draws a bit more than 0.03A (when the sMS-200 is booting it draws up to 0.14something A). The power consumption is about 3.6 -3.9W. Hope that helps a bit.

 

Mario

 

Hi Mario:

 

Sorry, but you are measuring AC current draw by the sMS-200's SMPS power supply. That does not tell us much about the product's DC current draw.

 

While an UltraCap LPS-1 is unlikely to power an sMS-200 with USB drives attached, the jury is still out about how much current an basic sMS-200 actually draws. A multimeter and a DC extension cable with a interrupted wire to put the meter in series with it is all that it will take to know for sure.

[Elescher]

Hi Mario:

 

Sorry, but you are measuring AC current draw by the sMS-200's SMPS power supply. That does not tell us much about the product's DC current draw.

 

While an UltraCap LPS-1 is unlikely to power an sMS-200 with USB drives attached, the jury is still out about how much current an basic sMS-200 actually draws. A multimeter and a DC extension cable with a interrupted wire to put the meter in series with it is all that it will take to know for sure.

 

No disrespect intended......but wtf....get a soTm and test it and let us know whether or not it works????

[Superdad]

No disrespect intended......but wtf....get a soTm and test it and let us know whether or not it works????

 

Can I borrow yours? Or you can purchase an UltraCap LPS-1, and if it does not power your sMS-200 I'll refund your money (including shipping).

 

Beyond that I'm not inclined to purchase an sMS-200 all the way from Korea as I am happy with my microRendu, and really it is not practical for us to buy a sample of lots of devices just to see what current they actually draw.

 

[Did just hear from someone that said the LPS-1 is terrific with his PS Audio LANRover. And he uses a 'Y' cable to power both it and a REGEN (since the LANRover needs some help with signal integrity and impedance match).]

 

--Alex C.

[firedog]

No disrespect intended......but wtf....get a soTm and test it and let us know whether or not it works????

 

"No disrespect intended"...followed by an extremely disrespectful sentence. So apparently that was exactly your intent. Nice.

 

I don't see any reason why it is Superdad's (Uptone's) responsibility to buy and test someone else's device to test it's draw. Uptone's responsibility is to inform us about it's devices, which it has done. Maybe you should direct your question to SoTM or their distributor.

[firedog]

Well, Amir's ability to measure is not for me to judge. But if you could enlighten me on, why you don't think he's applying proper method, it would be greatly appreciated.

 

 

Lot's of material already out there about the iFi PS and the mR. Including other threads on this site. Look there instead of continuing the discussion here.

[tyvo]

That wasn't what I asked. I asked about your opinion.

[YashN]

I think there isn't. If I see documentation for something, well explained and supported by reason, I will take it into account. Good documentation is good documentation no matter where it's put forth.

 

If you cook that thread down to something like, what John Kenny say is the truth, I believe you have have an angle.

 

I believe if you have to ask, then you're not fit to judge anything.

 

My angle is Systems Engineering and Science, what's yours?

[Holzohr]

Hi Mario:

 

Sorry, but you are measuring AC current draw by the sMS-200's SMPS power supply. That does not tell us much about the product's DC current draw.

 

While an UltraCap LPS-1 is unlikely to power an sMS-200 with USB drives attached, the jury is still out about how much current an basic sMS-200 actually draws. A multimeter and a DC extension cable with a interrupted wire to put the meter in series with it is all that it will take to know for sure.

 

Hi Alex,

 

ah thanks, the beginner in me totally forgot about the AC/DC thing. Hmm.. a multimeter is here, I used it to adjust the 5V-19.5 output of my HDPlex 100.