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

  • Yeah EDO installed, otherwise it would not be possible to play high res.
  • audio output indeed is digital only.

Those Roon settings are the same on my side, I’m fresh out of ideas.

You’re streaming server > sbt > coax out > DAC, nothing else in the mix, right?

Just for giggles try turn on digital vol control then set it to 100% and see if that changes anything,

nope.

right now testing from an VM with ArchLinux installed. Because it needs to be either my linux setup, or even hardware as a test with Roon from a MBP works.

[quote=“spockfish, post:83, topic:14000”]or even hardware as a test with Roon from a MBP works.
[/quote] not sure what you’re saying here.

@evand I have FW 7.8.0 and EDO 0.9. So good there.

All my hi-res files are FLACs. I get the issue on 96K files as well as 192K. It’s not linked to particular files. And the time of play before the problem is variable. As short as a few seconds and as long as half an hour or more. Once I get a failure to noise, it will only play for a few seconds and then fail again. So in that way, my symptoms are pretty similar to Egbert_Braams’.

I see that Harry has the SBT’s volume disabled in Roon; my is enabled. So no joy there.

Pretty darn sure this is not network.

I have the issue on 96K files both with and without Digital-Only selected. So with and without the EDO kernel loaded.

[Shuffles off to compare the ffmpeg and avconv versions on the Kubuntu and Fedora systems. Life would be sweet if it’s something so simple. Any other candidates you can think of I would be thrilled to check.]

avconv isn’t installed on either machine.

Here’s the return for ffmpeg on each machine. There is indeed a difference in the versions. Note the copyright date. Neither version is exactly ancient. Harry, what do you see?

[carl@Tux ~]$ ffmpeg
ffmpeg version 2.6.8 Copyright © 2000-2016 the FFmpeg developers
built with gcc 5.3.1 (GCC) 20151207 (Red Hat 5.3.1-2)
configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags=’-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic’ --enable-bzlib --disable-crystalhd --enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libcdio --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopencv --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
libavutil 54. 20.100 / 54. 20.100
libavcodec 56. 26.100 / 56. 26.100
libavformat 56. 25.101 / 56. 25.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 11.102 / 5. 11.102
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 3.100 / 53. 3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]… {[outfile options] outfile}…

Use -h to get full help or, even better, run ‘man ffmpeg’

carl@Kubuntu16virtual:~$ ffmpeg
ffmpeg version 2.8.6-1ubuntu2 Copyright © 2000-2016 the FFmpeg developers
built with gcc 5.3.1 (Ubuntu 5.3.1-11ubuntu1) 20160311
configuration: --prefix=/usr --extra-version=1ubuntu2 --build-suffix=-ffmpeg --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-libx264 --enable-libopencv
libavutil 54. 31.100 / 54. 31.100
libavcodec 56. 60.100 / 56. 60.100
libavformat 56. 40.101 / 56. 40.101
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 40.101 / 5. 40.101
libavresample 2. 1. 0 / 2. 1. 0
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.101 / 1. 2.101
libpostproc 53. 3.100 / 53. 3.100
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]… {[outfile options] outfile}…

Use -h to get full help or, even better, run 'man ffmpeg

Then again, does RoonServer care about ffmpeg if it’s only streaming FLAC, rather than decoding it to transcode bit rates?

Not sure whether it sends FLAC or LPCM to the SBT, if it’s treated the same way as other endpoints it gets LPCM and ffmpeg is thus part of the equation.

One last thing you can try is to restore your SBT’s to factory settings and then to reapply the firmware and EDO updates. I’m suggesting this because I recall that a handful of users over the years experienced a white noise issue using SBT and SB3 and in all cases a factory reset solved the issue.

Oh sorry, it was late already :wink:

I meant that on my side it could be a hardware issue, because my test with RoonServer running on a Macbook Pro and playing 192K content just works.

Ok… Interesting.

Running RoonServer on my virtual ArchLinux I can play 192K content flawlessly.

On one hand good, on the other hand annoying because now it’s either the hardware box or the linux distro (openSUSE) in this case that I’m running.

OpenSUSE never failed on me, and as I’m running their rolling release (Tumbleweed) software versions are somewhat comparable to ArchLinux or even more recent.

I see 2 options for continuing this:

  1. re-install my hardware box with ArchLinux
  2. create a new VM with openSUSE and re-test again

Try option 2 first.

In his master’s voice:

1 Like

Roon transmits LPCM to Squeezeboxes.

ffmpeg is not used to decode FLAC (only for mp3/aac, because those require codec licenses).

The next major release of Roon wll support on-the-fly FLAC encoding for Squeezeboxes to reduce networking demand (at the expense of CPU usage on both sides doing the extra encode/decode) as a setting.

2 Likes

@brian We may be on the verge of an “ah ha!” moment here. How does Roon do the FLAC to LPCM transcode? That may be a place to look. Is it an OS-provided component?

LMS has a user option to send native FLAC or transcoded PCM (WAV) from the server to the client. I seem to remember that there were issues with Enhanced Digital Output with PCM streams. In any case, I think prevailing practice was/is to send FLAC to the Touch natively. That’s the way my LMS was set to do it. Harry? Mind, this may be moot, because Roon is doing just fine running on Mac, Arch, and Ubuntu/Kubuntu, and it’s sending an LPCM stream in all those cases.

On a more general note, it appears that we are one or two experiments away from confirming that Harry and I can solve our own particular problems by rebuilding our servers on new OSes, or we can press on until we really figure this out. I see two things that argue against the first approach. For one: It would be, in my case anyway, an awful lot of just plain work. Two: It would leave the users and Roon with an unsolved issue that could easily bite again. I vote we keep going until we know what’s going on.

For my part, I’ll look to see if I have a Fedora 22 image, and if I do, I’ll whip up a VM and we’ll see if it behaves any different from Fedora 22 on hardware.

@evand Yes, did that. So did Harry, I think. And I did quite a lot to pretty throughly eliminate client malfunction from suspicion. If this is something the client is doing, it’s something the client is supposed to be doing that just isn’t playing nicely, like maybe an inappropriately sized buffer or something.

[quote=“Carl_Seibert, post:95, topic:14000”]
like maybe an inappropriately sized buffer or something.
[/quote]you didn’t ever experiment with all the sbt tweak toolkits that some did, did you?

We ship our own copy of libFLAC (libFLAC 1.3.1–the current version). I’m having a hard time seeing a relationship between the FLAC decoder and this issue, though.

My guess is, the “falling to static” behavior happens when audio data doesn’t make to some part of the driver/hardware in time. It’s in a class of symptoms that I generally associate with poorly written drivers (in this case, the audio drivers on the squeezebox). Symptoms like this point to a performance issue somewhere, but don’t indicate where, since the problem is happening at the far end of the chain.

Squeezebox streaming is TCP based, and flow control/buffering as well as hardware buffer size selection is all done within the SB Touch, so there’s no buffer sizes to tweak in Roon’s world.

I think transmitting as FLAC might resolve this since it does shift performance costs around the system, and it’s also what LMS does (so that approach has a lot more hours of reliable use behind it). I can’t be sure because we haven’t pinpointed the cause of this issue yet, which is the case because we haven’t been able to produce those symptoms here.

The moment when we see the problem here, progress will become much easier and much more certain. What you’re doing–eliminating variables one by one–is the best way to get to that point.

We’re going to deploy the FLAC change regardless of what happens in this thread, so worst case, you’ll have something to try when that release comes out. I’d be more comfortable if we could figure out how to reproduce this and be able to fully validate this as a fix sooner rather than later.

Cue the spooky Halloween music…

I built a Fedora 22 VM, no updates, just Fedora 22 straight from the ISO and I installed ffmep when the Roon install script complained about it. And it worked. No fail-to-noise, no missing queue entries. It just worked. (With some network issues) I don’t know what’s more frustrating: when something doesn’t work that’s supposed to or when something does that isn’t.

Then, just to make sure the planets hadn’t realigned, I went back to Fedora 22 directly on the hardware. And it failed. Instantly now.

What. The. Heck.

Harry mentioned hardware and I sort of dismissed the idea at the time because all the host’s hardware is used by the VM. But and that was then and now is now. I think Harry is also making a VM with the same OS as his hardware. I guess we’ll see if the same strangeness happens there.

Short of something where the virtual hardware works and the real hardware doesn’t, the only (sort of) plausible explanation I can posit would be that something installed on the real machine, that isn’t on the clean VM, might be causing the issue. But I have no clue at all where to start looking.

Played around again with my hardware box, trying to understand what the difference is with the VM.
I’ve become a little bit suspicious about my CPU freq scaling that I see on the hardware box, which is not present (for obvious reasons) on the VM.

On the hardware box the governor was set to ‘powersave’ in stead of ‘ondemand’ or ‘performance’. The latter is what I did. Now, it seems that it takes longer before the noise kicks in. The ‘seems’ is because I don’t have hard evidence, and in the end the noise is still there.

I’m going to investigate this more. Strange thing is that I’ve monitored load extensively, and at no point in time my system is running out of breath, at least from where I’m sitting.

Ah well, the story continues, but possibly only in the weekend.

Perhaps run memtest on your boxes and confirm your RAM is good.