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

Audio Gear Talk Squeezebox
21

Ok. Did a test met with NFS instead of SMB. In short: it did not resolve the issue, but I’ve noticed a few things that might help in sorting this out:

While my library was scanning I already started playing 192K content. Couldn’t help my self :slight_smile: Resulted in noise from the start. CPU load of my server at that time around 50% (because of the running scan). When the system was ready with scanning and idle again I retried. This time I could play 192K content for a long time, but failed in the end (after a minute or 10).

Now the weird part: if you think about this than you could easily draw the conclusion that this is server load related. When the noise arrived i switched to DSD64 content, which is being resampled to 176K content. Now, this takes more load on my server than playing 192K content, but it’s now playing fine for about 20 minutes…

22

@spockfish ---- Thank you for your continued feedback and sharing your observations/findings with us. Thank you as well @Carl_Seibert. My apologies for the slow response.

The squeezebox protocol is “pull” based – if it’s not getting audio fast enough, then it really comes down to one of two factors: either the Squeezebox is not asking, or the “pipe” is too small. There should be clear indications in our logs if we were not getting data fast enough from the NAS, so Carl, we are going to circle back and double check those. Harry, are you able to dump me a set of logs from your Roon Server as well?

Our team has taken out a ticket for our developers to test these issues in house and I will be compiling all of your provided info and logs into one place for analysis.

Thanks!
-Eric

23

@Eric sure! I’ll try to do this tonight.

Regards Harry

1 Like
24

@Eric - Let me know of you need more log files. I just grabbed the one that looked like it covered an appropriate time frame. RoonServer appears to make one per run, so I have a zillion to choose from.

As for the two factors you cite, bear in mind that the Squeezebox client works fine with RoonServer running on a Mac. That would appear to exclude client-side failings and, especially given that the Mac’s network situation is a bit more challenged, pretty much verify the network. IO on the machine itself (or on the machine with the data) seem to me still to be in play.

I’ll look and see if I have a snippet of the machine’s log for the time period of the RoonServer log I sent and pass that along if I’ve got it.

-Carl

Oh, and one other thought: Does anybody know what the failure to noise is a symptom of? Network slowdowns appear to cause a pause, but not a failure to noise. Is this a sync issue, maybe?

1 Like
25

@spockfish ---- That would be very appreciated, thanks!

-Eric

26

Hi @Carl_Seibert ---- Another set of logs would be great, thank you!

-Eric

27

Hi @Eric, here’s a link to a log file https://drive.google.com/open?id=0Bw7w2v2GDBzeVC1scG9ta21NSDA

Some details: noise popped in at 20:26 blank.
I let it ran until 20:27 when I skipped to the next track.

Now the rather bizar thing: when it started playing the second track there was immediately noise, but through the noise (that’s the only way I can subscribe it) I heard music. So it sounded extremely distorted, but it was recognisable.

I’ll hope you guys can make something out of this. If you need anything else than just drop a hint.

Thanks,

1 Like
28

Here you go. This is the messages log and the RAAT server log for the time covered by the RoonServer log. (Sorry for the avahi pollution. After I saw that I upgraded avahi to the newest version in my distro’s repository and it reduced the nonsense somewhat. But the actual fix is in the first version that’s too new for Fedora 22, according to the interwebs. Arrgh.)

1 Like
29

@Eric any update on this topic?

Thanks!

30

@Carl_Seibert and @spockfish ---- I wanted to touch base because our developers have had chance to try and test this issue in house.

As before they have reaffirmed that they strongly believe that we should not be seeing any differentiation between platforms and to confirm this, were able to play 192K to a Squeezebox Touch+EDO zone running 7.8.x for 2 hours with no issues or misbehavior.

Carl, in one of your earlier posts you had proposed a test:

“The Mac server is running on a laptop, so there are more WiFi hops when it’s in use. I would expect less throughput in that case. But I can probably lash up a wired connection to the same gigabit switch the Linux server and the data store are on, if need be for testing.”

Did you give this a shot and if so what were your observations? The reason I am asking is because with both cases here, I strongly believe that network troubleshooting should be our area of exploration now.

May I kindly ask you both to please provide a brief description of your network topology and any network hardware you maybe implementing (router(s), switches, repeaters, powerline adaptors, extenders etc).

-Eric

31

Hi @Eric,

I’ll provide that info later as I’m on a conference now.

Out of curiosity: did the devs run their test with a Linux-based server? Because that seemd an important factor.

Regards Harry

32

Yes, this was the test – 24/192 files to a Squeezebox endpoint, from a Linux Core, over a wired connection.

The fact that this worked for us in-house is good news, on one hand, because it means that this configuration can work and a significant issue didn’t make it through our QA process.

On the other hand, it’s frustrating because obviously something different is happening in your setups when Linux is involved that’s not happening with your core on OSX. @Eric is going to continue working with you guys and our team to understand and resolve the issue, but my guess is going to be some kind of networking bottleneck that’s only affecting the OSX device.

That’s just a guess – we’ll be watching this closely until we get this resolved for you guys, so thanks again for your patience.

33

@eric, @mike I upgraded to build 162 today. No joy. It failed within 30 seconds on a 192K file. Ah. well…

@mike I have a simple gigabit switch that has on it the two Linux boxes, one of which hosts the Roon Core in question and the other has the data store and LMS. Also on that switch is a Windows machine that is seldom running when I play music and the SIP server for my home and office phones, neither of which have any traffic during music-playing hours. The switch is linked by wire to an ATT-provided residential router/WiFi access point. On the Wifi side is the Mac laptop that can successfully run Roon server, the Squeezeboxes (three in total), a bunch of phones, tablets, set top boxes and miscellany. All this stuff is in the same subnet.

To recap, from Linux box with data to Linux box with Roon Core (on the switch, on wire) through the ATT box, to the laptop as a Roon endpoint (via WiFi) works.

From Linux box with LMS (running LMS) through the switch to the ATT WiFi router to the Squeezebox Touch works.

From the Linux box with the data through the switch, to the ATT box, to the Mac laptop (running Roon Core) via WiFi, back to the ATT box and then to the Squeezebox Touch via WiFi works, but there are some obvious network slowdowns at 192K. Works perfectly at 96K (And geez. there are like three WiFi hops in there!)

From Linux box with data to Linux box running Roon Core (on the switch, on wire) to the Touch via the ATT box and Wifi doesn’t work.

So, network-wise, the absolute worst route works. The same routing that fails when the Roon Core on the Linux machine feeds the SBT works when there’s a Roon endpoint.

And the SBT that fails in one routing works on a “worse” one. (And also in the similar setup with the LMS on the machine with the data.) So the crappy WiFi implementation on the Touch wouldn’t seem to be the bad actor.

So, unless I’m missing something, I see every possible network point of failure eliminated as the likely culprit. What’s more, it just doesn’t “feel” network-y to me. And I’m a “gut” kind of guy.

If the executable is exactly the same between the Mac and Linux version, that leaves something in Mono or the setup on the Linux box for me, since I don’t like the network as a suspect.

What Linux distro did you guys use to test? I can try to slap up a virtual machine on the same box that the failing Roon Core lives on ands see what happens… I think I have a Windows instance on that box that we could try, too, if that would help.

And does anybody know what the failure to noise is a symptom of? I think that would be a major clue. (My network is held together with enough rubber bands and glue that I’ve heard a lot of network failures. They haven’t sounded sound like that.)

34

Oh. And I might be offline for a while, starting early Thursday morning. We’re having a bit of a hurricane here.

35

for me it’s a Linux with Roon Core (64-bit), all wired to a Asus RT-AC68U. Squeezebox Touch also wired to this Asus router.

Audio is stored on a Synology NAS, that is wired to the Roon Core machine through the same router.

Pretty straightforward, all wired, nothing special (I guess).

I’m still wondering though. I’ve been looking through the logfiles and I would expect messages when there are network troubles (like buffer underruns and stuff like that.)

Thanks,

36

Have you tried eliminating that Asus and just have the Nas, the Roon Core machine and the touch all wired into a unmanaged switch, like a netgear GS105?

37

With the latest LMS I played 192K from a Macbook Pro over wireless flawlessly. I really hope we can put this ‘this is a network issue’ behind us, because I fail to see why playing 192K wirelessly from a Mac works, while playing over wired from a Linux server with Roon does not (at least not for a long time).

38

What Harry said.

I think we have pretty well eliminated network issues.

39

Hi @spockfish and @Carl_Seibert ----- Thank you for the following up with us. Our team has been actively searching for ways to narrow down the cause of this issue in house and have been working closely with our developers during this process.

As Mike had mentioned, we were able to playback 24/192 files to a Squeezebox endpoint from a Linux Core over a wired connection without issues and now are looking for ANY possible deviations between our setup and yours. I would like to purpose a small test to see if we can trigger a change in behavior here. May I kindly ask you to please try the following:

LMS + Roon

  • Please disengage LMS.
  • Then power-cycle the devices.
  • Lastly, try to use them with Roon.

The goal is a clean test where LMS has never laid “hands” on the device. Please let me know your observations. Also, my assumption is that your Lynx machines are not going to sleep during use, but would like to confirm if there are an active power saving setting on those devices.

Thanks!
-Eric

40

I’ve done that as that is my pattern already. No LMS is running in the network.
And no, there is no power setting active on the linux box.

Remember, streaming 96K from the Linux server, or 192K that’s been downsampled from the Linux server all works.

Furthermore, did you discuss my last observation (and noooo, I’m not going crazy :wink: ), that throughout the noise I certainly heard the original music?

Is it not an option that you provide @Carl_Seibert and/or me with a debug server build for Linux? So we can repeat the test and possibly provide you with a more extensive logging?

Furthermore

Thanks!