Linux Roon server not playing high res files to Squeezebox [Fixed in 1.3]

Hi. I am new to roon (on a test license currently) and have a pretty similar setup to the ones discussed here - unfortunately with pretty similar problems:

Setup:
Server: Linux Debian Stretch x64, Core i3, 16GB memory, wired per GBit to router, 115,000 songs on a local internal hard drive (ext4)

Audio endpoints:
Logitech Transporter (currently on WIFI)
MS Surface 3 pro (currently on WIFI)

Symptoms:
The MS Surface plays fine with all resolutions (tested up to 24/192).
The Logitech Transporter playes fine with 16/44 content, however, with 24/44 and 24/96 and 24/192 (downsampled to 24/96) it starts playing ok but then switches to white noise, sometimes goes back to music and then back to noise.
I tried switching Audio Analysis Speed (incl. off) with no change. I did powercycling with all equipment involved with no change. Wifi connection is good (it worked for years with LMS) - I may later change to wired connection but given the reports here I am not confident.
I also tried downsampling with no change.

Can I try further options? Are logfiles of any help?

Update: I now also tried a wired ethernet connection to the transporter with no change. In addition I also tried a Mac as an Audio endpoint. The Mac works flawlessly.

So the problem remains the combination of Roon server and Logitech Transporter with anything above 16/44.

Iā€™m not sure how experimental youā€™re willing to be, but iā€™ve got a plugin over here, home backed, that at least makes it work on my SB Touch. Itā€™s an update on the existing EDO plugin + some kernel enhancements. If youā€™re willing to try it out just say the word.

Does the Transporter even run the EDO plugin?

Not as far as I know.

That is the problem, the Transporter is a different thing that does not run anything close to the SB Touch server. But thank you for your support.

Yeahā€¦ totally overlooked that. Sorry!

Since this weekend Iā€™m running Roon on a Raspberry Pi 3 with the Digi+ board. For me this was a rather cheap but worthy replacement for my old Squeezebox Touch. You might have a look at these kind of solutions.

Good luck!

No. but it does handle 24/96 files natively.

Hello again,

Iā€™ve been away from this thread for a while. While Iā€™ve been gone, Harry and I both have been experimenting/working around our problem by using Raspberry Pis as endpoints.
Executive summary is that, yes the Pis with RoonBridge work just fine with hi-res files in both our systems.

Now the possibly interesting bit, as far as this thread is concerned, is that as I type this, Iā€™m listening to a 24/196 file through a Raspberry Pi1 running piCorePlayer as a Squeezebox endpoint. Except for a very occasional faint tick (sounds analog-like, like a faint bit of surface noise) that I havenā€™t quite chased down yet, it seems to be working famously. Iā€™m suspecting the tiny tick is network related, but who knows. It sounds fine, although my brain is in functionality mode still. (I can do sound quality or functionality but not both at the same time.) Wifi performance - with a Canakit Wifi dongle - seems pretty strong, better than the Squeezebox Touch to the best of my reconning.

Now what light this really sheds on things, I canā€™t really say. The hardware is different, obviously, but I have no idea how Squeezelite, which is what piCorePlayer runs, might differ from the software in the SBT. One thing seems fairly likely and thatā€™s that Iā€™m doubting that our Squeezebox issues are a straight-up throughput problem. The stream from RoonServer is uncompressed PCM either way, and this rig is handling it just fine.

Credit where it is due: I have been running RoonBridge in a Pi3. I changed to see a post by RBM in this very forum wherein he suggested piCoreplayer as a workaround for somebody who had only a Pi1. I have a Pi1 that has has piCorePLayer on it forever. It didnā€™t dawn on me that I could use it with Roon. Thank you Rene!

1 Like

On the other handā€¦

Roon v1.3 came out yesterday. At this moment, both of my Squeezebox Touches are set to ā€œuse FLACā€ mode and happily streaming 24/192 content from my Fedora-on-real-hardware server. Woo hooo!

@brian - Way to go. I like some of the other new features as well, like built-in cloud backup and restore. And the better metadata features. Very nice. One note: I did find actually manipulating the ā€œuse FLACā€ switch to be a little difficult on my 8 inch tablets. I had to use a stylus. Maybe the touch zone is a bit small? Or maybe my fingers are a bit big. My subjective impression is that the same switch gizmos on the main settings page worked a bit easier.

By the way, my Raspberry Pi with RoonBridge worked fine with 1.3. I wonder should I update RoonBridge on that machine? Will the install script thatā€™s already on the Pi grab the new version, or do I need to wget a new install script?

Next up will be going back and forth to see of thereā€™s a quality advantage to FLAC or not to FLAC (which is germane only to piCorePlayer, since itā€™s the only endpoint I have that can work both ways.) I remember that the early Squeezeboxes sounded a bit better with FLAC to PCM done on the server and PCM streamed to the endpoint. But when the Touch came out, it didnā€™t seem to matter anymore. Weā€™ll see.

1 Like

It will grab it automatically. Go into settings->about on any roon remote and you should be able to check for updates and see the status.

OK. Shoulda thought of that. It says 1.0 is the latest version :slight_smile:

The build number is the important bit:

Yours should say something like 1.0 (build 61) stable if itā€™s up to date.

Yup. Thatā€™s what it says.

More potentially interesting information:

Today I tried streaming hi-res material to the SBT with FLAC compression turned off, just to see if there was a change with 1.3. Short answer: it kind of worked. Sort of. Better than before. With everythying just right, i could play a whole song. -ish. Otherwise, fail to noise. As expected, basically.

Then I noticed something interesting. I was getting dropouts or pauses on 192K content. It took a while to remember that yesterday I had been experimenting with crossfeed in the DSP settings. (I was rather impressed, by the way) With crossfeed on, dropouts. Crossfeed off, no dropouts. (With FLAC compression off, crossfeed was the kiss of death. Fail to noise in one bar.) Increasing the buffer size on the SBT had an effect here. With the buffer set at ā€œlargeā€, crossfeed didnā€™t seem to cause dropouts, or at least far fewer of them.

This struck me as odd. If processing for crossfreed was happening on the server side, why on earth would the Squeezebox care one way or the other?

Then I noticed something really strange. One of the records I was using to test was Dave Brubeckā€™s ā€œTime Outā€, This particular album is encoded at 16/192, instead of 24/192. (According to Roon) In all my pushing-the-Squeezebox-and-network-to-the-throughput-limit scenarios, these files were more likely to fail, or pause or whatever than the 24/192 files I used. I even went back to this album after half an hour hour or so, just to satisfy myself that I wasnā€™t just seeing fluctuations in network performance. Nope. Consistently, this album overwhelmed the system while 24/192 material didnā€™t. What the HECK could that be all about?

And finally, I saw what might be a bug: Upon starting playback, about one or two bars into the song, I experienced a pause (or dropout). This on both hi-res and red book material. It was only on the first song, after pressing ā€œplayā€. Song-to-song transitions were not affected. Buffer settings on the Squeezebox made no difference here.

ā€¦And the touch zone on the FLAC compression on-ff toggle really does seem tricky, compared to other toggles in the interface.

Just a little update on my Roon 1.3 experience with a Logitech Transporter:

Last year I tested Roon 1.2 with the Transporter and with high-res material in particular the music often failed to noise. This was from a well equipped Linux server (i3, 16GB ram, SSD, Debian Stretch) via LAN and Wifi.

Now Roon was so kind to provide me with another test period with Roon 1.3. My setup basically stayed more or less the same. With the transporter there is no fail to noise anymore. Instead on the Transporter I often have a fail to pause/dropouts of the music. This was after my music collection has been fully analyzed. It seems to be more frequent with high-res material but also happens with red book material.

I really never had any problems of this kind with the Logitechmediaserver on the same setup. This leads me to the conclusion that there is something that Logitech did better in the communication of their server software with the transporter hardware.

One addition that I added in the meantime was a Naim Mu-So Qb. It was added in my kitchen, where I have a bit more difficult Wifi conditions. However, the Naim works absolutely perfect with Roon via AirPlay on Wifi.

This is just a little update on Roon with a Logitech Transporter - neither more nor less. I certainly appreciate any hints on improving my Roon experience. However, I fear that Roon may not make it into my life as long as my Transporter stays - which is a pitty since I really enjoy the Roon software as such.

@Stephan_Aier

Failing to a dropout sounds network-y, which seems to be what youā€™re thinking, too.

Just to confirm - you set Roon to send as FLAC to the Transporter, right?

Did you try running Roon server on a Windows or Mac machine in a similar network environment? If performance is the same, that might push suspicion more towards the network. If the problem disappears, then it sounds more like the ailment that Harry and I had. Now for us, 1.3 and send-as-FLAC fixed the issue with Roonserver on Linux.

Itā€™s also worth noting that in my case, it was only with the Squeezebox Touch as an endpoint that I had any problems. With Squeezelite on a Raspberry Pi, RoonBridge on a Pi and Roon on a laptop (all sending as PCM) high res files worked fine. My issue was specific to Roonserver on Linux and the Squeezebox endpoint. (More specific than that, actually. Roonserver on a virtual machine, running on the same hardware as my ā€œrealā€ server, worked. )

Bummer that 1.3 didnā€™t fix it for you.

Hi Carl,
Thank you for your comment. Actually this is a strange thing. I did some more testing which indeed seems to hint toward networking problems:

  1. I did the ethernet connection - worked without a problem - but is no permanent option in my case.
  2. I took out an old 54MBit wifi router, configured it in Client Bridge mode and connected it via Wifi to my main router and via ethernet to the transporter - surprisingly this also works without any problem so far.
  3. The direct Wifi of Transporter to main router shows the described problems: fail with short dropout, or fail to pause (so that the Transporter shows the clock again in my config), or even fail to temporarily the transporter loosing the network connection. This is all with FLAC to Transporter. Interestingly if I restart the roon server (software) it may play ok for some time and then starts to fail. Once it failed the first time, it will continue to fail more frequently.

What surprises me is that (2) works ok and that (3) works when I run LMS instead of Roon with no issue on the exact same hardware.

Currently (2) is an OKish solution for me. Still I would like to understand this overall behaviour. As mentioned, it may very well be a networking problem. However, I kind of doubt it is entirely a physical layer (as in the ISO/OSI networking model) network problem.