Odroid C2 as hqplayer NAA?

Hi,

I have been upsampling and playing DSD files using HQP on a PC and SOTM sms-200 for some time . It works perfectly. But I’ve been inspred by various threads to experience what removing USB from my audio chain does. So…

Can anyone tell me whether @jussi_laako has produced an NAA image that will run on a C2? I tried the 64-bit version which I thought might work but I it wouldn’t boot.

As an alternative I have installed dietpi and can get som great sound out of the system by everything is upsampled to PCM (even when playing DSD files) via HQPlayer. I cannot get HQPlayer to recognise that the NAA and DAC should be able to accept native DSD and/or DoP.

I am assuming that I haven’t configured something in dietpi correctly. Or perhaps there is some text file configuration for NAA that I’ve missed. When I looked at the soundcard settings, there were three options, HDMI, hifi-shield plus and hifi shield 2. When I choose the hifi-shield option I get perfect PCM…but how do I get DSD?

Thanks for any help you can give!
Crom

What kernel version is running? And what version of DietPi?

I thought the kernel was brought up to date for the Odroid C2 this year. I did ask the question here but haven’t got a reply from @Dan_Knight :

I’m away from home at the moment but will check as soon as possible. If it helps, I only downloaded dietpi late last week so I assume the latest.

1 Like

No worries. If it’s linux kernel is up to date, native DSD should be fine. If not, that’s the problem.

I have a C2 somewhere around, in a box, that I can’t find - otherwise I would have checked myself before asking Dan last week.

Hi,

We do not offer a 4.x kernel based image for the C2 yet, however, it is planned for the future.

In the mean time, you could use ARMbian 4.18 image (not desktop, use one on right hand side) and convert to DietPi:
https://www.armbian.com/odroid-c2/

After you login with:

  • root
  • 1234

Follow onscreen instructions to setup a user. Then run DietPi PREP on the system:

apt-get update; apt-get install -y systemd-sysv ca-certificates sudo wget
wget https://raw.githubusercontent.com/Fourdee/DietPi/beta/PREP_SYSTEM_FOR_DIETPI.sh -O PREP_SYSTEM_FOR_DIETPI.sh
chmod +x PREP_SYSTEM_FOR_DIETPI.sh
./PREP_SYSTEM_FOR_DIETPI.sh

Ensure you select BETA branch, contains improved code for PREP.

1 Like

Cheers Dan!

@crom this will likely solve your native DSD playback issue.

Once you get DietPi up and running, just install NAA via dietpi-software.

You’ve already tagged him, so I’m sure the answer in time.

The x64 version definitely won’t work and I’m not sure any of the NAA images here would work but Jussi will confirm:

https://www.signalyst.eu/bins/naa/images/

But the DietPi method should work nicely. I’ll try it out myself if I can find my Odroid C2.

Just out of curiosity.

What did you mean by “I’ve been insipred by various threads to experience what removing USB from my audio chain does.”.

The Odroid C2 NAA solution is an ethernet input & USB audio output solution, just like the SMS-200 I thought?

I’m not the sharpest tool in the shed so apologies if I’m missing something obvious…

Did you enable DoP from HQPlayer side? You can select it under “SDM Pack” drop list…

Hi Jussi, I am away on work at the moment but will check. I haven’t changed anything in HQPlayer since DSD was correctly playing via the SMS-200 but I cannot swear that DoP is selected…I’ll check.

Hi Sean, my aim is to experiment by using I2S directly between streamer and DAC, without the need to convert from i2S to USB and then back from USB to I2S. I’ve read various things about I2S input being preferable to USB and thought I’d test it. To do this I’m using an isolator hat compatible with both Odroid and PI, developed by IanCanada on DIYAUDIO. This hat provides isolation from the noisy PI and presents I2S output as u.fl sockets - ideal for me to mount internally, within the DAC, and connect directly to a re-clocking board. Ian has just launched a group buy for a version 2 of this board which does both isolator and reclocker functions (like the allo kali … but better in my case as it has u.fl sockets pre-mounted on board). Experiments so far have proved interesting, and I’ll possibly start another thread sometime, but even with the odroid powered by crappy wallwart and no optimisation to the OS (other than installing dietpi) the direct I2S connection is definitely ‘on a par’ with my highly optimised/re-clocked/isolated/all-sorts-of-other-tweaks USB chain. Clearly there could be expectation bias at play here but it would appear that removing USB is worthy of further explorartion.

1 Like

Got it! Now it all makes sense for me. Yes I know about this.

Which DAC do you use that takes I2S input?

Let us know what you find when you eventually try it out.

Hi @Dan_Knight, thanks for jumping into help with this. I have run into issues running the PREP script. See image below. It looks like a DNS issue as whtn I try to ping anything except IP addresses I get the error “Temporary failure in name resolution.”

image

On the above screen there was an option to edit the network configuration but this just returned me back to the same screen. When I exited and re-ran the script I received this output:

are supported and installed on your system.

perl: warning: Falling back to the standard locale (“C”).
Git branch: Fourdee/beta
–2018-12-06 12:14:49-- https://raw.githubusercontent.com/Fourdee/DietPi/beta/dietpi/func/dietpi-globals
Resolving raw.githubusercontent.com (raw.githubusercontent.com)… failed: Temporary failure in name resolution.
wget: unable to resolve host address ‘raw.githubusercontent.com
Error: Unable to download dietpi-globals. Aborting…

It looks like the DNS / network settings are changed/reset as part of the script running. Can you point me in the right direction to resolve this please?

many thanks,
Crom

Quick update from me:

Following the above error I decided to reboot. Dietpi booted up. It continued its setup routine (as a normal dietpi image would) and then I exited the setup when given the chance and re-ran the PREP script. Script ran and completed gracefully and asked me to reboot…

Some success but HQP now doesn’t find the NAA at all. I will continue to hunt for a solution but @Dan_Knight I’ve submitted a bug report from dietpi in case you can see anything obvious there, I’d appreciate it:

7d53b0ad-d108-4271-abaf-fd0472606212

Thanks,
Crom

Most common problem is running HQPlayer in multi-homed environment (multiple network interfaces on HQPlayer machine) which in turn may create multicast traffic routing problem…

Hi,

Strange, we usually only see the DNS issue when setting PREP on ARMbian images using WiFi. This is due to network-manager removal.

Currently, you must run PREP using ethernet, else, manual WiFi configuration of /etc/network/interfaces is required prior to running PREP.

Please can you confirm if you used ethernet or WiFi during PREP?


My only concern is PREP did not finish completely. This may in fact be the cause of the HQP issue.

Thanks:

● networkaudiod.service - Network Audio Adapter daemon
   Loaded: loaded (/lib/systemd/system/networkaudiod.service; disabled; vendor preset: enabled)
   Active: active (running) since Thu 2018-12-06 17:54:57 GMT; 2min 39s ago
 Main PID: 1916 (networkaudiod)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/networkaudiod.service
           └─1916 /usr/sbin/networkaudiod

Dec 06 17:56:31 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): initialization failure: clALSAMiniEngine::Initialize(): snd_pcm_open(): No such device
Dec 06 17:56:31 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): begin disconnection
Dec 06 17:56:31 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): ALSA backend uninitialized
Dec 06 17:56:31 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): disconnected [::ffff:192.168.178.37]:45222
Dec 06 17:56:33 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): discovery from [::ffff:192.168.178.37]:50296
Dec 06 17:56:33 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): discovery from [::ffff:192.168.178.37]:50296
Dec 06 17:56:34 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): connection from [::ffff:192.168.178.37]:45224
Dec 06 17:56:34 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): begin disconnection
Dec 06 17:56:34 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): ALSA backend uninitialized
Dec 06 17:56:34 DietPi networkaudiod[1916]: [/usr/sbin/networkaudiod] (1916): disconnected [::ffff:192.168.178.37]:45224

Seems it cannot find the ALSA device, whats the results of aplay -l?

Thanks for your help @Dan_Knight I used ethernet throughout. I’ve never used wifi on the C2/

As you suspected, no soundcards:

root@DietPi:~# aplay -l
aplay: device_list:270: no soundcards found…

If you suspect that it was that the install didn’t finish, I’m happy to wipe and re-do but any idea how to overcome the DNS issue if it happens again?

Interesting, could be a bug our end i’ll take a look.

Ok, so its not even picking up the USB DAC. Might be a bigger issue here:

----------
lsusb:
----------
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Might be a missing module in kernel, what happens if you try to enable the USB module?

modprobe snd-usb-audio
lsmod

i’m not using a USB DAC. The DAC is directly connected to the I2S headers on the ODROID.

My complete chain is as follows:

Odroid > IanCanada’s Pi Isolation hat > I2S output > u.fl I2S input on reclocking board of DAC.

lsmod results in this output:

root@DietPi:~# lsmod
Module Size Used by
snd_soc_hdmi_codec 16384 0
snd_soc_simple_card 16384 0
snd_soc_simple_card_utils 16384 1 snd_soc_simple_card
dw_hdmi_cec 16384 0
dw_hdmi_i2s_audio 16384 0
snd_soc_core 159744 3 snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_simple_card
meson_dw_hdmi 20480 0
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_pcm 110592 3 snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine
meson_drm 49152 1 meson_dw_hdmi
dw_hdmi 32768 2 meson_dw_hdmi,dw_hdmi_i2s_audio
snd_timer 32768 1 snd_pcm
snd 73728 4 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm
drm_kms_helper 172032 3 meson_dw_hdmi,meson_drm,dw_hdmi
soundcore 16384 1 snd
drm 401408 5 meson_dw_hdmi,meson_drm,drm_kms_helper,dw_hdmi
drm_panel_orientation_quirks 16384 1 drm
meson_rng 16384 0
rng_core 16384 1 meson_rng
ao_cec 16384 0
cec 57344 3 dw_hdmi_cec,dw_hdmi,ao_cec
meson_ir 16384 0
rc_core 36864 2 meson_ir
snd_soc_meson_audio_core 16384 0
scpi_hwmon 16384 0
meson_gxbb_wdt 16384 0
nvmem_meson_efuse 16384 0
ip_tables 28672 0
x_tables 36864 1 ip_tables
realtek 16384 1
root@DietPi:~#

modprobe snd-usb-audio results in this:

root@DietPi:~# modprobe snd-usb-audio
root@DietPi:~#

lsmod then results in this:

root@DietPi:~# lsmod
Module Size Used by
snd_usb_audio 200704 0
snd_hwdep 20480 1 snd_usb_audio
snd_usbmidi_lib 32768 1 snd_usb_audio
snd_rawmidi 32768 1 snd_usbmidi_lib
snd_seq_device 16384 1 snd_rawmidi
snd_soc_hdmi_codec 16384 0
snd_soc_simple_card 16384 0
snd_soc_simple_card_utils 16384 1 snd_soc_simple_card
dw_hdmi_cec 16384 0
dw_hdmi_i2s_audio 16384 0
snd_soc_core 159744 3 snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_simple_card
meson_dw_hdmi 20480 0
snd_pcm_dmaengine 16384 1 snd_soc_core
snd_pcm 110592 4 snd_usb_audio,snd_soc_hdmi_codec,snd_soc_core,snd_pcm_dmaengine
meson_drm 49152 1 meson_dw_hdmi
dw_hdmi 32768 2 meson_dw_hdmi,dw_hdmi_i2s_audio
snd_timer 32768 1 snd_pcm
snd 73728 9 snd_seq_device,snd_hwdep,snd_usb_audio,snd_usbmidi_lib,snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm,snd_rawmidi
drm_kms_helper 172032 3 meson_dw_hdmi,meson_drm,dw_hdmi
soundcore 16384 1 snd
drm 401408 5 meson_dw_hdmi,meson_drm,drm_kms_helper,dw_hdmi
drm_panel_orientation_quirks 16384 1 drm
meson_rng 16384 0
rng_core 16384 1 meson_rng
ao_cec 16384 0
cec 57344 3 dw_hdmi_cec,dw_hdmi,ao_cec
meson_ir 16384 0
rc_core 36864 2 meson_ir
snd_soc_meson_audio_core 16384 0
scpi_hwmon 16384 0
meson_gxbb_wdt 16384 0
nvmem_meson_efuse 16384 0
ip_tables 28672 0
x_tables 36864 1 ip_tables
realtek 16384 1
root@DietPi:~#

You’ll need to have kernel built with correct device tree file (dts/dtb) for that to work… IOW, kernel needs to be told what and how is connected to the I2S…