- 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 
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:
- re-install my hardware box with ArchLinux
- 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.