[PROBLEM] Initial stuttering when playing back high resolution files

[DutchBassAddict]

I seem to be experiencing issues (a stutter) at the beginning of a track that is a high resolution format (24bit and dsd) with moode running on my RPI3b+, with an Audiophonics Sabre Dac HAT (i2s 9038 unbalanced), source files coming from a NAS (but also happened when I tried some music locally) using a linear power supply. I tried the same hardware with Volumio and it worked flawlessly. So I feel it's safe to presume the hardware isn't at fault here. Would love some suggestions. I'm not resampling anything nor am I using an EQ. 


Appreciate any help you can give me. Would love to give more information but I'm not sure where to start.

[Tim Curtis]

Your best bet is to zip up one of the tracks and PM a download link to myself, @TheOldPresbyope and @Nutul.

I have a Audiophonics 9038 unbalanced and can try to repro.

[DutchBassAddict]

Your best bet is to zip up one of the tracks and PM a download link to myself, @TheOldPresbyope and @Nutul.

I have a Audiophonics 9038 unbalanced and can try to repro.

Appreciate it, I will send the link now. Added a few as examples. (They playback fine or my PC)

[TheOldPresbyope]

@DutchBassAddict 

I tried all three files using a 64bit moOde 8.3.2 installation on a Pi3A+ driving my Khadas Tone1 USB DAC in ALSA Output mode "Direct (hw)" and with mpd Format set to "Native DSD (default)". The only conversion happening is a  24bit  --> 32bit mapping at the output to match the DAC requirements. The files are served over WiFi via the SMB service on my NAS.

In a nutshell, I didn't notice a stutter at the beginning playing either DSD or FLAC tracks nor do I see any suspicious log messages even with log levels cranked up.

Could you describe more concretely what you're hearing?


Regards,
Kent

[Tim Curtis]

The files play perfectly on my Audiophonics 9038, no audio glitches whatsoever.

Here's a screen shot of Audio info

   

[Nutul]

Same here,

all the files play without any glitch. Also I have DSD set to native, as my dac supports it .
I use a USB dac, though, so this is not a sign that things actually work; as there still might be a problem with MPD (or ALSA, FWIW) and IIS devices...

I would be very happy, however, if the issue was related to your, and only your device (and even happier, if the manufacturer provided a software fix for it, if case be)

[yage2046]

I've been doing extensive troubleshooting random dropouts during playback of DSD64 files on my setup consisting of an RPi 3 B+ with a USB DAC (Benchmark DAC3 HGC). This DAC requires DoP mode to be enabled in the MPD config.

The two things I've found to have the most impact on performance were switching to the 32 bit 'legacy' version of mOode and setting the CPU governor to 'performance' instead of 'ondemand'.

Lastly, I also had some strange messages in my logs related to CIFS (my music folder is being shared from a Mac mini). It was writing 'CIFS: __readahead_batch() returned' repeatedly to /var/log/messages as I was streaming a file. That also seemed to be causing dropouts. I disabled and re-enabled sharing on the Mac and the error went away.

Hope this helps!

[TheOldPresbyope]

@yage2046 

Firstly,

The two things I've found to have the most impact on performance were switching to the 32 bit 'legacy' version of mOode and setting the CPU governor to 'performance' instead of 'ondemand'.

Does "impact on performance" mean that the rate at which the random dropouts occur lessens when you make these changes? Is there a noticeable ordering to the effect? E.g., is making one of the changes better than making the other, or v.v; is making both changes better than making only one or the other?


Secondly

Lastly, I also had some strange messages in my logs related to CIFS (my music folder is being shared from a Mac mini). It was writing 'CIFS: __readahead_batch() returned' repeatedly to /var/log/messages as I was streaming a file

Hmmm. Can't say I've noticed this message before but now that I look I see them flooding /var/log/kern.log as I play FLAC files in moOde 8.3.2 on a Pi4B from my OpenMediaVault NAS running in Linux on a Odroid HC1. Searching the message content on the Interweb™ turns up a number of hits from various people. From what I've read so far, I'm not sure what the best practice would be here.

Regards,
Kent

[yage2046]

Does "impact on performance" mean that the rate at which the random dropouts occur lessens when you make these changes? Is there a noticeable ordering to the effect? E.g., is making one of the changes better than making the other, or v.v; is making both changes better than making only one or the other?

If the default USB driver (dwc_otg) is being used, then the 32 bit version is a much better choice. On the 64 bit version, I experience dropouts every 30 secs or so if on the 'ondemand' governor and I can force a dropout by logging in with ssh. If I switch to 'performance' the dropouts occur about every 50 - 60 secs. 

On the 32 bit version, a dropout might happen after 7-8 minutes with dwc_otg + ondemand. I can't trigger a dropout with ssh. With dwc_otg + performance, I get a dropout about every 10 minutes. Here's a post from a kernel dev on a possible reason why 32 bit is better - link.

Using the 'dwc2' USB driver instead of 'dwc_otg' and enabling 'performance' on either the 32 bit or 64 bit version results in the most stable system. Dropouts are very rare - I may get one after 30-40 minutes of playback.

I tested a few previous releases and the most stable version out of the box was 7.6.1. It played for about 30 minutes until I got a dropout.

Re: CIFS errors, I think I may have been getting the errors because of a series of blackouts due to weather. I reset folder sharing on the Mac and now I don't get the error messages anymore.

[DutchBassAddict]

Does "impact on performance" mean that the rate at which the random dropouts occur lessens when you make these changes? Is there a noticeable ordering to the effect? E.g., is making one of the changes better than making the other, or v.v; is making both changes better than making only one or the other?

If the default USB driver (dwc_otg) is being used, then the 32 bit version is a much better choice. On the 64 bit version, I experience dropouts every 30 secs or so if on the 'ondemand' governor and I can force a dropout by logging in with ssh. If I switch to 'performance' the dropouts occur about every 50 - 60 secs. 

On the 32 bit version, a dropout might happen after 7-8 minutes with dwc_otg + ondemand. I can't trigger a dropout with ssh. With dwc_otg + performance, I get a dropout about every 10 minutes. Here's a post from a kernel dev on a possible reason why 32 bit is better - link.

Using the 'dwc2' USB driver instead of 'dwc_otg' and enabling 'performance' on either the 32 bit or 64 bit version results in the most stable system. Dropouts are very rare - I may get one after 30-40 minutes of playback.

I tested a few previous releases and the most stable version out of the box was 7.6.1. It played for about 30 minutes until I got a dropout.

Re: CIFS errors, I think I may have been getting the errors because of a series of blackouts due to weather. I reset folder sharing on the Mac and now I don't get the error messages anymore.

Appreciate the clarification, and even more excitingly, switching to 32 bit solved the audio issue completely from my initial testing (half an hour or so, default settings except for setting up the i2s DAC and fileshare, trying to keep it simple). I would have never thought to try that! Verified on both of the Pi's that this fixes the audio. Unfortunately the UI also seems a bit slower and my initial boot failed to resize the disk. But definitely a worthy tradeoff. Forgot to mention this, but I tried moode a while ago (can't remember version, +- half a year ago) and I had the same stuttering happen then, too. Now to get spotify connect working and I will be all set! The spotify connect not working may be user error, but I had it working sporadically (intermittently though) and now it's just never showing up at all when I try to connect to it (32 and 64bit).

Thanks once again for all the help everyone!!

Any way to mark this problem "solved"?

Spoke to soon: When I'm using DoP the problem occurs, and when I use "native DSD" it seems to downsample to 352k pcm, is this correct? If my Dac somehow can't do DOP even though it should, this may be the same in the 64 bit version as I always defaulted to that as the dac was advertised as being able to handle it.