Issues with DietPi and HighRez upsampling into Mojo

This really is not an issue, but i was curious whether anyone else has experienced this.

I am running DietPi (147) on a Raspberry Pi 2B and on a NanoPi Neo 512Mb. When upsampling to either 706/768Khz or DSD128/256 i get short dropouts, say every 45seconds, mostly towards the end of the song playing.
They are connected over ethernet and both of them are connected via USB to my Chord Mojo.
At DSD256 and PCM over 700khz i also have experienced one or both channels losing sync and instead playing just pink noise into my head phones or speakers.
I cannot recreate this when feeding my Mojo from a headless MacMini (2011). I dont have any other DAC that accepts these resolutions to compare the Mojo with though.

And while im at it, i cant seem to update my dietpi install over SSH, it stops at screen saying “please backup your system” and when trying to do so it gets stuck when backing up some irrelevant turkish root certificate…

Likely @Dan_Knight can help you with your upgrade woes – though I wouldn’t be tempted to mess with Turkish root certificates… :wink: Perhaps the fastest / easiest way is to reflash your card with a fresh DietPi. Make sure you change your root password, just in case…

As far as the Mojo goes: I usually feed mine from a Cubox, but I’ve tried a Pi3 for a few days without any problems at PCM768 and DSD256. I guess the combination of network traffic and USB traffic at these bitrates is a bit taxing for the little bugger, but I did not have any hiccups. Are your network and core (upsampling?) are up to it?

Thank you for input Rene!

Yes, i agree its a small task to reflash the microSD and i think i’ll do that. Do you backup your DietPi system?
Edit: Sorry about this! There was no problem other than a somewhat corrupt user interface through the Reflection for Unix-app on iPad. I just managed to perform the updates on both of my active Pi’s!

Concerning the high rez glitches, i would say the system can manage. I ususally get processing speeds at around 4x when upsampling to DSD256 and around 10-12x when doing 706/768Khz PCM.
And the MacMini do not show any signs of issues at the same speeds…

I was eyeballing a Cubox Pro for trials as you responded. Do you run Jessie Lite on that one?

No, never. It’s a <10 min. job to flash and configure a new card if needed (when it’s only used as RoonBridge zone).

Your upsampling numbers look fine – I agree that these should not cause any problems.

As for the Cuboxes: I have three of them around the house (i1, i2 & 4Pro). Even the i1 does not break a sweat when running RoonBridge.

I run Armbian on them. If you decide to dive in, make sure you use the Legacy release (Vanille was pretty half-baked for audio last time I tried). They changed their site a bit, offering only Ubuntu Vanilla on the first page – but I guess you need Debian_jessie_default these days, available from here: https://dl.armbian.com/cubox-i/

I touched on the Cubox installation in the old guide (instructions come after the Raspberry Pi part). You can ignore the bit about .raw files – Armbian uses .img files now that you can write to your card in the same way you’d do with DietPi.

Hi,

Thats a new one we havn’t seen :slight_smile:

Any chance you could take a screenshot/paste of this, so we can investigate?

Thx for your attention @Dan_Knight!
I discovered it’s most probably an issue caused by the Reflection app. But i will take a screenshot as soon as i can, while using Terminal on my Mac instead!
The update went fine when i (blindly) tried pressing Tab followed by Enter! So all is well, but i didnt have time to try the “dietpi-backup” command again.
And now i’m away… :confused:

1 Like

Hmmm, i must admit i had no issues with dietpi-backup when using my iMacs Terminal application…
The issues before were clearly due to the Reflection app for iPad.

Well then another mystery solved. One still remains however!
I have two Pi’s, both 2B. One is version 149 and the other 150. Both are up to date says the diet-update!

───────────────────────────────────────
DietPi | 16:19 | Mon 01/05/17
───────────────────────────────────────
V149 | RPi 2 Model B (armv7l)
───────────────────────────────────────
IP Address | 192.168.15.136
───────────────────────────────────────

and the other one:

───────────────────────────────────────
DietPi | 16:18 | Mon 01/05/17
───────────────────────────────────────
V150 | RPi 2 Model B (armv7l)
───────────────────────────────────────
IP Address | 192.168.15.222
───────────────────────────────────────

And, has the 384Khz-kernel-setting moved into the Just-Boom configuration?

Hi,

v149 is current version DietPi, v150 is dev/testing.

I think you may be running the testing branch of DietPi, instead of “master”. Can we check the following please:

cat /DietPi/dietpi.txt | grep 'gitbranch'

And, has the 384Khz-kernel-setting moved into the Just-Boom configuration?

dietpi-justboom audio control panel? Yep, its in there, can enable 384KHz for MPD.

You are very much correct sir!:
gitbranch=testing

I do not know why though? :slight_smile:

Not entirely sure. Our images contain “master” setting by default.

Can you remember where you downloaded the image from, which one, and, which version is on the image file?

I believe it is a quite recent image, downloaded from your main site on the 17/3 2017 at 16:23 CET.
Any suggestion how to acquire the version of the image? The file is just named “DietPi_RPi-armv6-(Jessie).7z”
I s’pose there should be some version file somewhere on the filesystem also?

Hi Mike,

Yep, if you open the 7z file, image version is in the filename. It can also be obtained with:

cat /etc/.dietpi_image_version

I’ve checked the image download, dietpi.txt is setup for master. Did you make any changes to dietpi.txt, prior to first run?

Hi Dan, my DietPi with “gitbranch=testing” is actually from version 142

root@DietPi:~# cat /etc/.dietpi_image_version
142

This means it is NOT downloaded recently as i first thought… It may be from 2016-12-02 or 2016-06-12 though.

This is not an issue to spend any more time on though, and i will simply refresh the micro SD with the latest image instead.

After updating my NanoPi Neo to DietPi 149 i haven’t experienced this lost sync into the Mojo again. :smiley:

But the issue with short dropouts with DSD remains, and is heard mostly with DSD256, less so with DSD128 and DSD64 i have yet to try. (Similar on both Raspberry Pi 2B and NanoPi Neo)
It would be nice to read of other peoples experience with similar setup?

And a question for @Dan_Knight, is it possible to kill the blue led programatically with DietPi on the NanoPi Neo? It is so bright as to be totally useless in a dark room! :slight_smile: Like looking into a strobe!
(blinks twice i rapid succesion every second or so, after boot up)

1 Like

Hi,

Yep, you can turn the LED off by running the following command:

echo -e "none" > /sys/class/leds/*blue*/trigger

To do this automatically during boot, add the above command to the end of /etc/rc.local, and, above exit 0

Like a charm! Million thanks @Dan_Knight!