Jump to content
IGNORED

SOtM smS-200 unveiled at Munich Hi-End


Recommended Posts

I have configured eunhasu with static IP for 14 months and have had a few versions of the OS that have reverted to dynamic when upgrading.  I am using 0.4.56 now and the last few upgrades have stayed on static.

 

I also suggest using a network scanner to show device IP addresses to locate devices that use DHCP to set their IP address.

Link to comment

For quite a while I have been using a SOtM SMS-200 as an NAA with Roon and HQPlayer into an Audiolab MDAC+ and have been able to upsample PCM to DSD 128 or directly output DSD 64, 128 and 256 files using DirectSDM.

 

I have recently updated the SMS-200 firmware and am now using V0.456. I'm not sure what has changed but I notice everything is being output as PCM. Even DSD files are being converted to PCM when Direct SDM is selected in HQPlayer which should just pass the DSD files straight through unaffected. I am also unable to select the SDM output from the drop menu in the main GUI window of HQPlayer. 

 

When I make the SMS-200 a Roon endpoint DSD 64 and 128 files play OK but when I try to play a DSD256 file Roon downsamples it to DSD128 (11.29MHz to 5.645MHz). Previously I was able to play DSD256 files and my DAC confirmed they were at the original sample rate of 11.29MHz. Sample rate conversion is disabled in Roon and the SMS-200 Roon settings are Native DSD512.

 

When I look at the Device Setup for the SMS-200 in Roon's settings the SMS-200 is shown as the Bridge Device and under Audio Device it lists my DAC as Unidentified device AUDIOLAB USB Audio 2.0.

 

Miska from Signalyst the supplier of HQPlayer thinks that  kernel update to sMS-200 has removed native DSD support for my DAC.

 

Has anyone else experienced similar problems? I haven't had any response from SOtM yet. 

Link to comment

Thank you all for your suggestions on how I might access the Eunhasu OS website. I finally was able to do so, but probably not how you might have guessed.

 

First, I tried the suggestion made by @tedwoods:

 

"If you're accessing it via DHCP and not via a bridged  or static IP configuration, it could mean it has been assigned a new IP address, so your link to Eunhasu does not work anymore.
Google ""sotm my" and it'll direct you to "my eunhasu" page (http://sotm-audio.com/my/), where you can find the new IP address and connect to Eunhasu again."
 
When I did this, an IP address appeared and I clicked on the link that said “Connect to Eunhasu.” That link inserted the IP address into the browser. This, however, resulted in a message that the server where this page is located is not responding. 
 
Next I clicked on System Preferences > Network on my audio server. This showed that the ethernet bridge I had created for my sMS-200 Ultra 200 was functioning. It also showed a different local IP address than the "my Eunhasu" page described above. So I inserted that address in my browser. The result, however, was the same:  the server at that IP address did not respond.
 
This was becoming frustrating because I had been unable to play digital music using Roon. Roon could not "see" my sMS-200 on the network. I had thought a reboot of the Eunhasu OS might solve the problem (it seems to have done that in the past). It turned out, however, that the problem was apparently related to the cabling of my SOtM-modified D-Link switch (the first leg of my SOtM Ultra trifecta). When I removed the switch from my system, Roon immediately saw the sMS-200 and I could play music. 
 
Roon also gave me a different IP address for the sMS-200 in the Device Setup window. I tried this one and, voila, I was finally able to access Eunhasu. 
 
A long and winding road for sure. Not sure why the first two methods described above didn't work.
Link to comment
8 hours ago, Always.Learning said:

It turned out, however, that the problem was apparently related to the cabling of my SOtM-modified D-Link switch (the first leg of my SOtM Ultra trifecta). When I removed the switch from my system, Roon immediately saw the sMS-200 and I could play music. 

 

So, you have a bad switch?

Link to comment

I have never had any of these issues since I upgraded directly from 4.22 to 4.56.  I use DHCP on my router to assign a fixed IP to the sMS, and the IP has never changed from what I told my router to give it.  Eunhasu access takes more or less the same amount of time as it always did.  The internal green flashing light is normal behavior. 

 

 

 

Link to comment
4 hours ago, Solstice380 said:

 

So, you have a bad switch?

Too early to say. I haven't really attempted to get at the root of the problem yet. It may be fine and the problem may simply have been a loose connection that could be easily dealt with.

 

This is a switch that was clocked (from my sMS-200 Ultra) by a short, 12 inch cable from DigiKey that cost $20. I never really liked the connectors on these cables and it always felt a bit precarious. Also, the fact that I was running two stiff, unwieldy SOtM dBL-Cat7 ethernet cables in and out of the lightweight switch made for a more precarious situation. I'm curious if anyone else has had problems with their SOtM-modified switch? 

Link to comment

Just to add to the recent posts regarding "My Eunhasu", I too have had problems.  I first noticed this when I was changing some cables recently.  When doing this, I would shut down the sMS-200ultra, then power up again when done.  I would then find that Eunhasu would not connect.  At one time I actually thought I had bricked the sMS.  I tried all sorts of things to get it to work, but without success.  Eventually, I tried logging into my router, found the IP address for the sMS, used this to log in directly and all was good.  Not exactly what you would expect from a "plug and play" consumer device.  Thanks to all those that have recommended "Fing", by the way.  Fing is much quicker and easier than logging into a router.

 

I have not used my system for a few days, and this morning I again could not connect to Eunhasu.  This was strange, the PC has been off, but the sMS-200ultra has been permanently connected and powered up during this time.  Trying "My Eunhasu", and nothing happens, nothing at all.  Very strange, and I certainly have not had these issues in the past.  OK, a couple of minutes with "Fing" finding the IP address, and I am up and running again.  For those that are computer literate, this is little more than a minor niggle.  Being frank, anyone not computer literate would be completely stuffed by this, which is not really acceptable.  Hopefully, this is a minor glitch and SOtM will get it sorted out.

Windows 11 PC, Roon, HQPlayer, Focus Fidelity convolutions, iFi Zen Stream, Paul Hynes SR4, Mutec REF10, Mutec MC3+USB, Devialet 1000Pro, KEF Blade.  Plus Pro-Ject Signature 12 TT for playing my 'legacy' vinyl collection. Desktop system; RME ADI-2 DAC fs, Meze Empyrean headphones.

Link to comment

Hi all and @may.park

Want to check if anyone here get to play native dsd successfully on MPD/DLNA mode?

I've Minimserver (no transcoding) running on a Synology NAS - have SOTM set to "Native DSD Type 2" and also on the latest 4.56 firmware.

It seems that whenever I try playing any dsf file - sotm sends it as PCM to my dac. 

Can't seems to play native dsd. Anyone with experience on this mode willing to share or help?

Link to comment

@may.park

Hi May, I believe that Spotify made some changes to its spotify connect protocol.

Right not - in librespot mode, I cannot send audio to Sotm when I change playlist on my ios and windows device

I'll need to play a playlist or album on my ios/windows device first - then connect via spotifyconnect to SOTM. 

I am limited to only playing the songs on the playlist/album. If I want to change to another playlist/album - spotify connect will not play the newly selected playlist/album. 

Link to comment
15 hours ago, SYM said:

Hi all and @may.park

Want to check if anyone here get to play native dsd successfully on MPD/DLNA mode?

I've Minimserver (no transcoding) running on a Synology NAS - have SOTM set to "Native DSD Type 2" and also on the latest 4.56 firmware.

It seems that whenever I try playing any dsf file - sotm sends it as PCM to my dac. 

Can't seems to play native dsd. Anyone with experience on this mode willing to share or help?

 

Did you update the kernel?

Link to comment
13 minutes ago, aslg said:

Did you update the kernel?

 

I downloaded and flash the image to 4.56. Its not a problem with the kernel. I think I know why I cannot stream native dsd to my dac now.

 

Sotm maintains a list of compatible dsd dacs for native dsd playback. As long as your dac is not in that list - I suspect eunhasu will transcode the dsd stream into pcm even though the dac is capable of decoding dsd. 

 

I emailed May to clarify on this point- hope she gets back soon

Link to comment

Thanks 5-pot-fan. That sounds promising. I did try 4.56 after you posted in the "Praise For SOtM" thread about your success. I notice with your current settings you posted above, you have doubled the Internal Buffer from 16348 ( I assumed this was a typo and should have been 16384) to 32768. Was this because you had more issues after your posts in the other thread?

 

Your setup sounds quite similar to mine. I also have LMS on a separate computer so it's not running on sms 200. My dac also has no DSD.

 

Hopefully there will be a 4.57 released soon.

Link to comment
14 minutes ago, SYM said:

Thanks @5-pot-fan for sharing your experience 

As seen in your settings - you’ve disabled DSD. Can I ask if this is by choice or just simply a limitation of SOtM?

It's mainly because my DAC does not handle DSD. I bought it primarily for digitising my vinyl, and am happy with both the recording and the playback SQ. When that job is done I may get another DAC, one that handles DSD, but one step at a time!

I do intend to test changes to the Squeezelite config settings, and will report back when done.

 

Link to comment
24 minutes ago, lasker98 said:

Thanks 5-pot-fan. That sounds promising. I did try 4.56 after you posted in the "Praise For SOtM" thread about your success. I notice with your current settings you posted above, you have doubled the Internal Buffer from 16348 ( I assumed this was a typo and should have been 16384) to 32768. Was this because you had more issues after your posts in the other thread?

 

Your setup sounds quite similar to mine. I also have LMS on a separate computer so it's not running on sms 200. My dac also has no DSD.

 

Hopefully there will be a 4.57 released soon.

Now you mention it, SoTM made a change at the end of their 2nd login (during which they tested their DAC ID-related edits). I don't know why they did it, and frankly never checked back against the previous settings, because it all still worked! Perhaps the settings are not that crucial in my system, but I will make some other edits, and record what I do.

Link to comment

Ok, I have done a few more tests on my sms-200,changing the Squeezelite config settings.

All the changes were made by first saving the changes then doing a reboot.

Changing the sample format setting from 24_3 to 16 made no difference, possibly because these 2 values appear in my DAC information within the config page. Setting it to 24 or to 32 gave bad stuttering.

Leaving the sample format at 24_3, the max sample rate at 192000 (also a setting shown in the DAC information page), and DSD at None, I then changed the buffer time, internal buffer and period count as follows:

Starting at 320, 32768 and 32 respectively, i halved these values at each further step.

Step 1 (original values as above): all OK

Step 2 : all OK

Step 3 : occasional dropouts

Step 4 : bad stuttering and variations in apparent speed of replay

Step 5 : bad stuttering and the music was slowed down.

I suppose I could try testing changes to these 3 values individually but that might be another 12 tests, and another 2 -3 hours. Next time I have paint drying maybe...

Once back to the original values I then tried switching DSP mode between None and DOP. I have only 2 or 3 files in .dff or SACD format but these played fine (I have appropriate plugins installed in LMS). I assume these files were played through the DAC in PCM format, but they played as expected.

I then tried some .wav files with DOP and None selected and could not detect any differences between them and they all played OK.

The only minor issue, as reported by others, is that I cannot reboot directly from the System Settings page, but can do so from the System Settings/System Config page - not a major issue for me during these tests.

I don't know if this info will be of use to anyone, but it's free!

 

 

Link to comment

Thanks again 5-pot-fan. I very much appreciate you taking the time to experiment with these different settings.

It does seem that much higher values are required for the config settings then anywhere else I've seen any kind of suggested settings. This link seems to be the most useful I've found as far as understanding the different settings:

 

https://translate.google.com/translate?hl=en&sl=it&u=http://marcoc1712.it/%3Fp%3D458&prev=search

 

In one section he gives the default Squeezelite values as:

 

"If nothing is specified, squeezelite uses the following default values:

Buffer Size: 40 ms
Period Count: 4
that are extremely conservative."

 

That 40ms/4 setting seems pretty consistent with anything else I've read as well as my own experiences. Even with 4.22 the Eunhasu default for my dac is 40ms/4 with "Internal Buffer" blank. I'm currently using 30 ms/3 with 4.22 and have zero issues. Based on your testing it looks like you start getting stuttering with 80 ms/8 which is still much higher than anywhere else I've seen or used myself. Based on this I have to say I believe there's still issues with Eunhasu and Squeezelite although it does appear progress is being made.

Thanks again for your help. 🙂

Link to comment

Lasker98, 

I agree with your comments about settings, as far as v4.22 is concerned. My system works fine with the default settings in 4.22. This has not been the case with 4.51 onwards.

It was at around v4.5xx that (if memory serves) changes were made to the Squeezelite kernel in some way, or perhaps in the way it interacts with the rest of the SOtM sms-200 software, and it is from then that these problems arose - as I'm sure you know.

One of the reasons for getting the sms-200 rather than my previous preference was due to issues that product was facing with Linux-related updates, so it has not surprised me that some problems have occurred for SOtM in similar circumstances. How these have been tackled, and the improved quality of the sound, leaves me glad about my choice.

Looking forward to 4.57 now!

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...