Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Freddiekaberman]

Hi to all,

I have followed MWillems excellent guide to set up MC 22 on a Pi3. Sq is excellent, for me it is some way ahead of volumio and moode. The downside is that I am getting frequent dropouts. I have tried wired Ethernet vs wifi, mc running as renderer only, and as server renderer combined, I have fiddled with buffer settings all to no avail. All in context of streaming from a qnap Nas via a netgear switch (which works great for my other systems).

If anyone has any pointers as to how I should diagnose the issue, it would be much appreciated.

[mwillems]

Let's focus on the best case: wired ethernet with the Pi serving solely as a renderer.  How often do you get dropouts?  What is your output device with the pi?  Which buffer settings have you tried?  I know this sounds odd, but have you tried setting the thumbnailing priority lower?

[Freddiekaberman]

Thanks for reply, sorry for delay, family life and such...

When hard wired, dropouts are coming initially in the first few seconds of a track, in cases where I start a new playlist or album. After that it seems almost random i.e. it might go 5 mins or 10 mins and then dropout at any point during a track. The dropouts can last few quite a few seconds in some instances, it is not a what I would call a stutter. This is happening regardless of files size and I have tried with CD rips, 24/96 and 24/192 in both WAV and Flac format.

Output device in this case is USB out to an IFi iLink spdif converter (I have the powered from a separate USB hub). This then goes coax to a chord mojo.

Buffer settings, I have tried most of the options in MC - under "Audio / Settings" I tried prebuffering 6,10 seconds, memory play. Under "Audio device" I have also tried doubling up the default buffer value. Hope that is clear.

In the meantime I will try it USB direct to the Mojo and make sure it replicates.

[mwillems]

Buffer settings, I have tried most of the options in MC - under "Audio / Settings" I tried prebuffering 6,10 seconds, memory play. Under "Audio device" I have also tried doubling up the default buffer value. Hope that is clear.

Pre-buffering shouldn't have any effect on what you're describing, and in fact might make it worse right at the start.  Try smaller buffer values and see if that helps. 

I think your suggested approach of testing a direct USB connection is also a good one; a direct USB connection may well provide different results than an SPDIF signal as SPDIF is a "one way" method of communication and doesn't allow for negotiation between the device driver and the software. 

[Freddiekaberman]

OK many thanks, I will play around with these variables and report back.

[Freddiekaberman]

Hi,

I have now tried unfortunately to no avail;
USB from Pi3 straight to Chord Mojo, hard Ethernet, Pi as renderer only with another instance of MC server running on a Win 10 PC.
Reduced buffer settings
Thumbnail priority set to low.

The only success I have had was with an SSD drive connected directly to the Pi, in this case everything seems to work well. I guess I can conclude from this, it is a network issue of some kind.
I read that there is an issue where Pi can struggle with date I/O when Ethernet and USB are simultaneously busy - is that the likely cause or could I be missing something else?

[JimH]

Did you try turning off auto-import?

[Freddiekaberman]

Yes I disabled that after setting up MC on Pi as renderer only. I have also now managed to replicate dropouts when playing from a local library via SSD, so I guess that might rule out network issues. It would be great to get to the bottom of this, because the SQ is very good!

[blgentry]

There have been reports of the Spectrum Analyzer on MC22 for Linux causing poor performance.  You might fire up the MC GUI, then disable the spectrum analyzer (right click in the header to see the menu).  This may or may not have anything to do with your issues, but it's worth a try.

Brian.

[Freddiekaberman]

Thanks, I have done that but to no avail. I have switched to using Rune as renderer with JRiver on PC as server - so far no dropouts but no particular magic on the SQ front either.

[bob]

Hi,

I have now tried unfortunately to no avail;
USB from Pi3 straight to Chord Mojo, hard Ethernet, Pi as renderer only with another instance of MC server running on a Win 10 PC.
Reduced buffer settings
Thumbnail priority set to low.

The only success I have had was with an SSD drive connected directly to the Pi, in this case everything seems to work well. I guess I can conclude from this, it is a network issue of some kind.
I read that there is an issue where Pi can struggle with date I/O when Ethernet and USB are simultaneously busy - is that the likely cause or could I be missing something else?

It does seem to be the case that the Ethernet and USB are using the same I/O bandwidth however I am playing hires files without incidence to my Id Pi.
Can you elaborate on the following:
What file types you are sending to the Id Pi (also bitdepth, sample rate, channels).
How are you getting files from the QNAP to the Id Pi?
What are you using as a controller to send the files to the Id Pi?

[Freddiekaberman]

Hi Bob,

I am using standard uncompressed two channel flacs and wavs from 16/44 up to 24/192. The controller (if I understand it correctly) is another instance of MC21 running from a Win10 PC, with JRemote as control point. I have also tried the Pi as both server/controller and renderer by streaming the files directly from my QNAP nas over hardwired Ethernet. I seem to get the same dropouts whatever I do. This is all in context of output via USB. I have checked and all files are sent "as is" without any upsampling or other manipulation. The only option I have ticked on the Pi is crossfeed, since this is a headphone only setup. Since I replicated the same dropout with a local SSD, I'm thinking there must be some other process going on - that said, I can watch the CPU % via remote desktop and it doesn't look anything abnormal - in the range 5-30% or so during playback.

[bob]

Hi Bob,

I am using standard uncompressed two channel flacs and wavs from 16/44 up to 24/192. The controller (if I understand it correctly) is another instance of MC21 running from a Win10 PC, with JRemote as control point. I have also tried the Pi as both server/controller and renderer by streaming the files directly from my QNAP nas over hardwired Ethernet. I seem to get the same dropouts whatever I do. This is all in context of output via USB. I have checked and all files are sent "as is" without any upsampling or other manipulation. The only option I have ticked on the Pi is crossfeed, since this is a headphone only setup. Since I replicated the same dropout with a local SSD, I'm thinking there must be some other process going on - that said, I can watch the CPU % via remote desktop and it doesn't look anything abnormal - in the range 5-30% or so during playback.

On the MC on the Pi3 under Options->Media Network->Advanced try checking the "disable audio buffer to disk"

[Freddiekaberman]

Hi Bob,

Thanks very much for your suggestion, this one worked. I can now stream up to 24/192 almost flawlessly with Pi as renderer only. I have just hooked it up to a REGEN and then into the MOJO - the SQ is far higher than I had hoped for from a bedside headphone setup; very pleased with this and well worth a few days of tinkering to get it right.

[blgentry]

On the MC on the Pi3 under Options->Media Network->Advanced try checking the "disable audio buffer to disk"

Just so I can understand:

So, by default, the *client* (or renderer) writes the audio stream to disk first, then reads it from there?  In this case, that means that the Pi3 was trying to write to it's flash memory (probably), which is really slow, so this caused the dropouts?

Turning this off makes it a "straight network stream".

Brian.

[mwillems]

Just so I can understand:

So, by default, the *client* (or renderer) writes the audio stream to disk first, then reads it from there?  In this case, that means that the Pi3 was trying to write to it's flash memory (probably), which is really slow, so this caused the dropouts?

Turning this off makes it a "straight network stream".

Brian.

It's trying to write to and read from the sd card for buffering purposes. Normally disk buffering is helpful in a network play context, but this is a rare case where the disk i/o is actually potentially slower/less continuous than the network connection so its bottlenecking.  The pi's sd slot only has a throughput of 20Mb/s in the best case, and split between reads and writes the real throughput in a buffering context is probably much lower. 

Using an external USB drive would be potentially even worse as the network connection shares a bus with the usb controller, meaning that the disk i/o would literally be stealing throughput from the network connection.  So reading from the network into memory and leaving it there is a better option, even in the comparatively memory starved environment of a Pi.

[bob]

It's trying to write to and read from the sd card for buffering purposes. Normally disk buffering is helpful in a network play context, but this is a rare case where the disk i/o is actually potentially slower/less continuous than the network connection so its bottlenecking.  The pi's sd slot only has a throughput of 20Mb/s in the best case, and split between reads and writes the real throughput in a buffering context is probably much lower. 

Using an external USB drive would be potentially even worse as the network connection shares a bus with the usb controller, meaning that the disk i/o would literally be stealing throughput from the network connection.  So reading from the network into memory and leaving it there is a better option, even in the comparatively memory starved environment of a Pi.

Yes.
The other issue with NOT buffering to disk is that some files are not seekable as a stream
Buffering them into a file allows for seeking on a normally non-seekable format.

[blgentry]

Thanks for the confirmation and extra info guys.  Always trying to learn more about this super complex piece of software. 

Brian.