RPi2 - tuning CIFS network mounts

[richardcwhitfield]

Hi All,

I have a Raspberry Pi-2 (RPi2) with a hifiberry Digi+ where the fibre SPDIF goes to a Yamaha amplifier. The RPi2 is running RuneAudio 0.3-Beta and uses a USB wifi dongle to connect to my home network. On the network I have a Synology DS414j NAS with a music directory set up as a CIFS/SMB mount.

When everything is set up using the default configuration settings, I get significant stuttering in the music being played - at random intervals every several seconds it goes silent for a fraction of a second. I tried increasing the MPD audio buffer size in increments up to 10240 kilobytes, and it significantly reduced the problem but did not completely get rid of it.

I suspect that the problem is the wifi network connection and I found in the advanced setting for the network mounts a comment to say change rsize/wsize if you experience problems with music playback, eg clicks and pops. Not stuttering, but something.
So, I looked into rsize and wsize, rsize is the network read size which defaults at 16kB, but in theory can be much bigger. wsize is the write buffer size, but given that the network mount is read-only it should be irrelevant. Also, the standard mount flag is cache=none but I want to minimize network traffic and so I think caching should be a plus.

Any comments/experience in using the following config:
rsize=65536 (64K)
wsize leave at default
cache=strict

I will try it out and report back to this topic.

Thanks,
Richard

[richardcwhitfield]

Hi All,

Increasing rsize to 64K and changing to cache=strict seems to have worked quite well. The system has been running for more than 1 hour without any stuttering, and I have tried jumping round in the play queue and it does not seem to give any problems.

I have checked my Synology DS414j and it is currently using SMB 2 to share files with clients - I have asked their tech support for how big I can make rsize on the client side without breaking anything. It also says that I could use "SMB 2 and large MTU" or SMB 3, so my question is now, is what does ArchLinux/RuneAudio support - can or should I change to SMB 2 and large MTU or SMB 3, if these are supported/better?

Given that all the files being transferred are music, ie big files, I expect that larger read sizes will generally be better.

Any advice would be appreciated.

Richard

[Discovery]

Hi Richard,

I have your configuration (RPI2/Digi+). Try using an RCA cable instead of the optical link and tell me if you notice a difference in the bass frequencies. You may be surprised...

Trevor

[Spiralgalaxy5]

Hi All,

Increasing rsize to 64K and changing to cache=strict seems to have worked quite well. The system has been running for more than 1 hour without any stuttering, and I have tried jumping round in the play queue and it does not seem to give any problems.

I have checked my Synology DS414j and it is currently using SMB 2 to share files with clients - I have asked their tech support for how big I can make rsize on the client side without breaking anything. It also says that I could use "SMB 2 and large MTU" or SMB 3, so my question is now, is what does ArchLinux/RuneAudio support - can or should I change to SMB 2 and large MTU or SMB 3, if these are supported/better?

Given that all the files being transferred are music, ie big files, I expect that larger read sizes will generally be better.

Any advice would be appreciated.

Richard

Not sure if it's worth a new thread so responding here: I have RPi3 B working via its integral WiFi to play music from NAS. When I experimented with 24/96 or 24/192 files the audio would cut out after a few minutes - some kind of synchronisation problem with getting the data from the NAS in a timely manner. The UI would continue to show the track playing and not respond to further input - any user inputs appeared to be queued until the audio situation got resolved. There are so many things in that chain that could be a bottleneck, most of them nothing to do with the Pi itself.... I experimented with audio buffer size but that did not help. The most beneficial change was to the NAS mount: make Rsize = 65536 but with no changes to the cache setting - I heeded the friendly warning

It's maintaining play for much longer periods now (sometimes over 30 minutes with files up to ~4700kbps) but I don't expect perfection using a WiFi connection anyway - flaky stuff, but so convenient. If the UI is left alone the audio eventually returns so the Rune software and all other aspects are pretty darn stable I'd say - graceful recovery! At the moment the Pi is further away from the access point than it is intended to be (while I experiment) and currently I never see better than 50% signal so maybe when it's located in the same room it will be OK.

Tim
RPi 3 B v1.2
IQAudIO Pi-Dac+
Rune release version: 0.4 (build: beta-20160313) - Optimisation: OrionV3-(IQaudioPiDAC)