I just managed to get Roon and the HQPlayer trial to work with my SotM sMS-200ultra Neo.
The album is playing correctly, but I can’t control the music stream anymore. Roon says “nothing playing” and I can even close Roon and HQPlayer Desktop and the music is still playing.
It seems as if the album just got read really quickly and is now playing from a buffer somewhere.
Any idea what happened and how I can regain control of the music again? Of course I can just restart the network bridge. I just don’t want that to happen again in order to be able to use HQPlayer correctly.
This means I could only play music when I enabled NAA in the SotM. There was no music playing before when only RAAT was enabled in the SotM. Roon output was set to HQPlayer, of course.
This never happened before, except similar stuff when I first checked out HQPlayer a few months ago (I remember latency issues when using the controls which is normal, I think, but also vaguely remember something similar “ouf of control”). I have never had any issues with RAAT.
So I am pretty sure it has to do with HQPlayer, but of course I’l be glad to be proven wrong.
NAA can never possess more than about two seconds of audio. So if you stop playback at HQPlayer or close it, NAA cannot play longer because it doesn’t have data.
HQPlayer doesn’t posses more than ten seconds of audio from Roon, so if you close Roon, HQPlayer cannot play longer because it doesn’t have data…
I had to give up with HQPlayer altogether. Couldn’t get a stable connection running NAA on the SotM. It would run for a while then NAA would drop connection to the DAC and I would have to re-boot the SotM. Tried with several DAC’s and eventually gave up.
I came to the conclusion the reason was my DAC’s needed windows drivers I couldn’t run on the SOtM Linux. I had a self build fanless i3 windows server with a SOtM USB card that ran fine for years with these DACs but eventually the windows server crashed and burned probably because it was overheating. I was tired of the endless PC support so I never replaced it.
I never went down the RP route because I thought it would just be the same problem with Windows based DACs with no custom Linux drivers. Is there a reason a RP will work better than the SOtm in this scenario?
Not sure if this was addressed at me but I don’t chase bitrates. Can’t here the difference. I do have some 24/96 and 24/192 so I did experiment and the dropping of connection didn’t seem to be related to bit rate. I just came to the conclusion I needed to run Windows USB drivers I couldn’t run on the SOtM.
What I meant to ask is does the Linux based RPi4 somehow work with USB DAC’s that require a Windows driver? That is interesting news. I have several older DAC’s that I like the sound of that I just assumed will never work with Linux based servers including RPi4.
My experience with SOtM, is that it is unable to pull of this trick. SOtM package their USB interface in several different ways at multiple price points for either Windows or Linux (but not both, they seem to be keen to segment this market). So for example I could not get a Linux based SOtM SMS-200 Neo to work, I assume because I could not install the Windows drivers. On the other hand I could get a SOtM tX-USBexp USB interface card to work because I could just install it in a spare PCI slot in a Windows based server where I could run the relevant Windows driver.
I bought a SOtM SMS-200 Neo assuming that the sound would be indistinguishable from the SOtM txUSBexp. I wanted a more appliance like experience and I was tired of self supporting a fanless windows server that eventually died prematurely due to over-heating. In fact, the sound was indistinguishable (to my ears) but unfortunately in the absence of the Windows driver the stability made the SMS-200 unusable. SOtM themselves acknowledge there is an issue with older DAC’s requiring Windows drivers and produce a rather expensive Windows server to fill this gap. But it’s quite a low-powered Celeron machine (probably to avoid a complex heatsink design) so I didn’t go down that route and ended up not only abandoning SOtM but also HQPlayer and RAAT. I am a long-time Mark Levinson user so now I use a Mark Levinson 5101 with its inhouse Apodizing filter as a streamer with UPnP as it is 15,000 euros cheaper than the Mark Levinson RAAT roon certified one.
I am a bit reluctant to go down the RPi4 route as I have arrived where I am trying to avoid as much DiY as possible. But I do like those old DACs so I would give it a whirl if I thought there was a chance that Windows DAC’s somehow work with RPi4. Seems a longshot but maybe I am missing something?
One DAC, for example, is an April Music Eximus DP1 that is about 10 year’s old now. The Windows driver is a Thesycon UAC2 rev. 1.61. The DAC does not do more than 24/192. DSD is not supported and TBH I don’t chase bandwith as I cannot hear the difference and stick mostly to redbook. The DAC is long out of production, Linux was never officially supported from what I recall. Maybe it was common in those days to heavily customise drivers. I don’t know.
I don’t have it installed at the moment but from memory, roon would find both an ASIO and an XMOS interface. I am pretty sure HQPlayer used to find the XMOS backend and that is what I would use until HQPlayer would drop the connection, followed by roon. I’m not sure I understand why running NAA on a RPi4 as opposed to on a SOtM will make a difference in this scenario but it would be great if there was a reason why it would?
If it works at all through SOtM, then it works with Linux (and the problem is somewhere else). And based on having Thesycon UAC2 driver it certainly sounds like it should work with Linux just fine. It could be a networking issue as well.
Anway RPi4 with my NAA image is a cheap way to try things.
Even cheaper is to skip NAA and connect the DAC directly to the computer running HQPlayer.
If it works at all through SOtM, then it works with Linux (and the problem is somewhere else).
In my case NAA has never worked on the SOtM SMS-200 Neo. There have always been dropouts requiring a reboot.
Even cheaper is to skip NAA and connect the DAC directly to the computer running HQPlayer.
I know this works. Worked for years This was my original scenario until I tired of PC support and replaced 2) with 1).
Because of the discussion I started experimenting again. I seem to get a stable connection on the SOtM with both roon ready and LMS. It’s just NAA that will not hold a connection. There is quite a detailed config for the XMOS DAC that the LMS server finds so I tried copying that into the HQPlayer/NAA environment. There is no real match though.
I changed everything back to the defaults and tried again with two DAC’s. One an old 24/192 Eximus DP1 and a much newer DSD Gustard x16. I had experimented with every setting I could think of so quite a few of the defaults had changed. But it is the same problem. Connection held for a bit longer but dropped just the same. The only thing I can think of that the two DAC’s have in common is that they do not have native Linux drivers implemented by SOtM. Both the roon ready and LMS severs seem to work fine.
As it happens I do have a PI2AES on order because I have a non-USB network DAC/SACD/Streamer (Mark Levinson 5101). It will be a few weeks so I’ll try again with that. In the meantime Is there any way to get the ML 5101 working with NAA?
I am streaming PCM 768 or DSD 128/256 via ethernet to a RPi4 with NAA image using USB to the X16. No problems at all, stable as can be, not using Roon though. X86 laptop with HQPlayerOS wired to Cisco switch, then on to RPi4 endpoint also connected to the same Cisco switch.
