Login

jordanhuai · 05-07-2020, 07:54 AM

Moode version:6.5.2
Raspberry pi 4
Synology DS218+

DSD128 playback from nas is stuttering. I have no problem with dsd64. I increased the audio buffer size to maximum. It didn't work, stuttering still exists. If I pause the music for 1-2min, it can play smoothly for a while and stuttering will come back. I tried to play it from a usb drive. It played smoothly. Is there anything I can do to fix it?

**Tim Curtis** · 05-07-2020, 10:18 AM

The symptom suggests a network or NAS throughput issue.

When the glitches occur run the command below to see what the counts are for RX error, dropped, TX error for the interface, eth0 or wlan0, that you are using

Code:
ifconfig

You could also try to ping your NAS for 15 secs while the glitches occur and examine the ping stats for errors, long round trip times, etc.

Code:
ping HOST_OR_IP_ADDR

Ctrl-c to stop

jordanhuai · (This post was last modified: 05-07-2020, 11:04 AM by jordanhuai.)

(05-07-2020, 10:18 AM)Tim Curtis Wrote: The symptom suggests a network or NAS throughput issue.

When the glitches occur run the command below to see what the counts are for RX error, dropped, TX error for the interface, eth0 or wlan0, that you are using

Code:
ifconfig

You could also try to ping your NAS for 15 secs while the glitches occur and examine the ping stats for errors, long round trip times, etc.

Code:
ping HOST_OR_IP_ADDR Ctrl-c to stop

Hi Tim! It looks like nothing is wrong. Thank you for your reply.

Code:
pi@moode:~ $ ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.3.6  netmask 255.255.255.0  broadcast 192.168.3.255

        inet6 fe80::238b:329f:82cd:a047  prefixlen 64  scopeid 0x20<link>

        ether dc:a6:32:80:fa:4c  txqueuelen 1000  (Ethernet)

        RX packets 747597  bytes 1125192698 (1.0 GiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 383508  bytes 27306868 (26.0 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 1000  (Local Loopback)

        RX packets 2075  bytes 231349 (225.9 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 2075  bytes 231349 (225.9 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        ether dc:a6:32:80:fa:4d  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@moode:~ $ ^C

pi@moode:~ $ ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

        inet 192.168.3.6  netmask 255.255.255.0  broadcast 192.168.3.255

        inet6 fe80::238b:329f:82cd:a047  prefixlen 64  scopeid 0x20<link>

        ether dc:a6:32:80:fa:4c  txqueuelen 1000  (Ethernet)

        RX packets 793281  bytes 1194073521 (1.1 GiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 406873  bytes 28926001 (27.5 MiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0

        inet6 ::1  prefixlen 128  scopeid 0x10<host>

        loop  txqueuelen 1000  (Local Loopback)

        RX packets 2126  bytes 235982 (230.4 KiB)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 2126  bytes 235982 (230.4 KiB)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500

        ether dc:a6:32:80:fa:4d  txqueuelen 1000  (Ethernet)

        RX packets 0  bytes 0 (0.0 B)

        RX errors 0  dropped 0  overruns 0  frame 0

        TX packets 0  bytes 0 (0.0 B)

        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code:
pi@moode:~ $ ping 192.168.3.3

PING 192.168.3.3 (192.168.3.3) 56(84) bytes of data.

bytes from 192.168.3.3: icmp_seq=1 ttl=64 time=31.1 ms

bytes from 192.168.3.3: icmp_seq=2 ttl=64 time=0.359 ms

bytes from 192.168.3.3: icmp_seq=3 ttl=64 time=28.1 ms

bytes from 192.168.3.3: icmp_seq=4 ttl=64 time=34.9 ms

bytes from 192.168.3.3: icmp_seq=5 ttl=64 time=25.1 ms

bytes from 192.168.3.3: icmp_seq=6 ttl=64 time=33.3 ms

bytes from 192.168.3.3: icmp_seq=7 ttl=64 time=24.7 ms

bytes from 192.168.3.3: icmp_seq=8 ttl=64 time=27.3 ms

bytes from 192.168.3.3: icmp_seq=9 ttl=64 time=31.7 ms

bytes from 192.168.3.3: icmp_seq=10 ttl=64 time=27.0 ms

bytes from 192.168.3.3: icmp_seq=11 ttl=64 time=31.3 ms

bytes from 192.168.3.3: icmp_seq=12 ttl=64 time=24.4 ms

bytes from 192.168.3.3: icmp_seq=13 ttl=64 time=26.4 ms

bytes from 192.168.3.3: icmp_seq=14 ttl=64 time=32.7 ms

bytes from 192.168.3.3: icmp_seq=15 ttl=64 time=34.0 ms

bytes from 192.168.3.3: icmp_seq=16 ttl=64 time=28.7 ms

bytes from 192.168.3.3: icmp_seq=17 ttl=64 time=31.4 ms

bytes from 192.168.3.3: icmp_seq=18 ttl=64 time=35.2 ms

bytes from 192.168.3.3: icmp_seq=19 ttl=64 time=26.0 ms

bytes from 192.168.3.3: icmp_seq=20 ttl=64 time=30.4 ms

bytes from 192.168.3.3: icmp_seq=21 ttl=64 time=33.4 ms

bytes from 192.168.3.3: icmp_seq=22 ttl=64 time=27.4 ms

bytes from 192.168.3.3: icmp_seq=23 ttl=64 time=32.7 ms

bytes from 192.168.3.3: icmp_seq=24 ttl=64 time=24.1 ms

bytes from 192.168.3.3: icmp_seq=25 ttl=64 time=27.2 ms

bytes from 192.168.3.3: icmp_seq=26 ttl=64 time=33.7 ms

bytes from 192.168.3.3: icmp_seq=27 ttl=64 time=23.9 ms

bytes from 192.168.3.3: icmp_seq=28 ttl=64 time=28.7 ms

bytes from 192.168.3.3: icmp_seq=29 ttl=64 time=32.3 ms

bytes from 192.168.3.3: icmp_seq=30 ttl=64 time=22.9 ms

bytes from 192.168.3.3: icmp_seq=31 ttl=64 time=26.5 ms

^C

--- 192.168.3.3 ping statistics ---

packets transmitted, 31 received, 0% packet loss, time 121ms

rtt min/avg/max/mdev = 0.359/28.288/35.186/6.232 ms

the_bertrum · 05-07-2020, 11:05 AM

I wouldn't say nothing is wrong, those ping response times are huge.

I get these from my device connected via Ethernet:

Code:
bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=0.255 ms

bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=0.214 ms

bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=0.242 ms

bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=0.228 ms

bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=0.248 ms

And from a quite low quality WiFi connection:

Code:
bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=1.26 ms

bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=1.52 ms

bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=1.95 ms

bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=1.22 ms

bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=1.20 ms

bytes from 192.168.0.26: icmp_seq=6 ttl=64 time=1.64 ms

jordanhuai · (This post was last modified: 05-07-2020, 11:39 AM by jordanhuai.)

(05-07-2020, 11:05 AM)the_bertrum Wrote: I wouldn't say nothing is wrong, those ping response times are huge.

I get these from my device connected via Ethernet:

Code:
64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=0.255 ms 64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=0.214 ms 64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=0.242 ms 64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=0.228 ms 64 bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=0.248 ms
And from a quite low quality WiFi connection:

Code:
64 bytes from 192.168.0.26: icmp_seq=1 ttl=64 time=1.26 ms 64 bytes from 192.168.0.26: icmp_seq=2 ttl=64 time=1.52 ms 64 bytes from 192.168.0.26: icmp_seq=3 ttl=64 time=1.95 ms 64 bytes from 192.168.0.26: icmp_seq=4 ttl=64 time=1.22 ms 64 bytes from 192.168.0.26: icmp_seq=5 ttl=64 time=1.20 ms 64 bytes from 192.168.0.26: icmp_seq=6 ttl=64 time=1.64 ms

I connect all of my devices(Nas, pi, pc and chromecast) to a netgear r7000 router. I tried to ping my nas from my pc while not playing dsd128. It gives me <1ms. After i started the music, it gives me much higher pings (around 25ms). Coping a large file from nas to pc will not cause high latency. It looks like the dsd file transfer is causing the huge latency to the whole network. Do you think purchase an unmanaged switch could be a solution for this? Thank you!

**Tim Curtis** · 05-07-2020, 01:37 PM

It's better to isolate the issue first b4 introducing any changes.

File transfer is a bulk copy operation that uses TCP/IP protocol and is not time critical thus the rate at which the data is sent can vary or even stop/restart. Playing a remote music file uses UDP protocol and is time critical thus the rate at which data is sent is constant and cannot vary or stop/restart otherwise there will be buffer under-runs on the receiving client and audio glitches will occur during playback.

The symptom of long RTT ~30ms average from ping during playback suggests a possible issue on the NAS when it tries to stream a music file to client at a constant data rate.

What kind of NAS?
What kind of mount from moOde (SMB or NFS)?

**Tim Curtis** · 05-07-2020, 01:43 PM

Couple other things to try.

1. Swap in a Pi-3B+ and turning on the Ethernet port fix in System Config. This would be to rule out some sort of odd issue with Pi-4B Ethernet.
2. Switch to using a WiFI 5Ghz connection from the 4B instead of Ethernet.

jordanhuai · 05-07-2020, 01:57 PM

(05-07-2020, 01:37 PM)Tim Curtis Wrote: It's better to isolate the issue first b4 introducing any changes.

File transfer is a bulk copy operation that uses TCP/IP protocol and is not time critical thus the rate at which the data is sent can vary or even stop/restart. Playing a remote music file uses UDP protocol and is time critical thus the rate at which data is sent is constant and cannot vary or stop/restart otherwise there will be buffer under-runs on the receiving client and audio glitches will occur during playback.

The symptom of long RTT ~30ms average from ping during playback suggests a possible issue on the NAS when it tries to stream a music file to client at a constant data rate.

What kind of NAS?
What kind of mount from moOde (SMB or NFS)?

It is a Synology ds218+ Mounted to moode under SMB.

**TheOldPresbyope**

Both the file transfer protocols chosen and the software implementations of them matter.

If SMB, are you using SMB version 1.0 (the default setting in moOde unless you change it), 2.0, 3.0, etc.?

In principle, SMBv2 should be faster than SMBv1 for several reasons---it's less "chatty" to use the technical term <grin> and it allows larger block sizes---but this is testable. If you haven't already, try configuring your Synology minimum SMB protocol to "SMB2 with large MTU" (I don't own any Synology gear; I read this on their forum) and in moOde's Music Source panel, change the mounting flags under Advanced Settings to match (e.g., vers=2.0).

Also, the default setting rsize=6144 61440 in moOde is based on a defect in early Windows SMB 1.0 implementations. You can try increasing this to a much bigger number (like double or quadruple) since it is only the maximum allowable value and not the value negotiated between the underlying softwares in your Synology and moOde.

Some might suggest choosing NFS rather than SMB for the protocol. Whether this helps or not may say more about the Synology and Raspbian software than the underlying protocol but you could give it a shot.

----

On a separate note, it sounds like you were pinging only the Synology Ethernet transceiver so while the packet response times are indicative of how busy it is, they may not tell you much about the overall network (particularly the router). If you want to judge the effect on the network (because, say, the router is congested with the UDP traffic), try pinging the Chromecast device from your PC while your moOde player is or is not playing a high-bitrate DSD track from your NAS.

Regards,
Kent

**TheOldPresbyope**

This is not an exhaustive test, but it's suggestive:

I do not own any DSD material but my Khadas Tone Board claims it can handle up to DSD256.

I just downloaded a free collection from Blue Coast Music which contains a single song by Jenna Mammina encoded in different formats including DSD64, DSD128, DSD256 (also, WAV and FLAC at different resolutions). I threw the files into a SMBv1.0 share on my OpenMediaVault NAS.

My setup:

Khadas Tone Board -> (USB) -> moOde6.5.2/RPi4B -> (5GHz WiFi) -> Verizon FiOS G1100 Router/AP -> (Ethernet over Netgear PL1200 powerline adapters!) -> OpenMediaVault/Odroid HC1.

This lashup has worked flawlessly for me with all my FLAC material and default moOde Music Source settings (SMBv1.0, rsize=61440).

With the default moODe Music Source settings, the DSD64 and DSD128 tracks played ok while the DSD256 track stuttered and occasionally had long dropouts.

Keeping SMBv1.0 but bumping rsize=262144 and remounting the shares, I was able to play the DSD256 track.

I didn't try bumping to SMBv2.0 with different rsize settings but I suppose I should for the same sake of completeness.

Like I said, this isn't a definitive test---just one 4min track. Still, it looks encouraging to me.

Regards,
Kent

PS - why don't I own DSD tracks when my KTB can play them? Two reasons, really. First, I'm cheap. I'll spend money on things I want but don't have, but I already have a large collection of FLAC-encoded tracks ripped from treasured CDs and I already subscribe to streaming services which give me access to tracks I don't have. Second, upstream software volume control doesn't work for DSD-encoded material, the KTB doesn't offer hardware volume control for DSD-encoded material, and I hate having to use a downstream manual volume control. I'm exploring ways to fix the latter but there's no "fix" for being a penny pincher. I am my father's son after all.

Login
Username:
Password:	Lost Password?
	Remember me