@jussi_laako, I used both a dietpi as NAA and one of your NAA images so it’s most likely not a dietpi issue. It also didn’t occur upsampling to 192, just 384.
.sjb
Hi Luix @Lcocozza did you check this?
@jussi_laako will need as much information as he can get to try and resolve it so any inofrmation you can add would be beneficial.
.sjb
Hi I use a Microrendu as NAA, I will do as many tests as possible and report here.
1 Like
Runing my WIN 10 pc direct to my dac apparently does not invert the channels, again further testing needed.
Okay I have a better idea of what’s happening here and it’s not HQPLAYER as the same inversion happens with Roon upsampling to 384 via Raspberry Pi running dietpi into a Chord Hugo TT DAC.
The reason why only some HQP filters seemed to be affected was some only upsampled to 352 on which the left/right inversion doesn’t happen.
so is the issue dietpi or Linux related or Hugo TT related.
I’d be much obliged if anyone with this combination could check upsampled 384 via DietPi into Hugo TT.
@Dan_Knight any ideas?
I cannot believe I’m the only one experiencing this?
.sjb
Hi John,
If this only occurs on the Hugo DAC, its most likley limited to that device. Ideally, if someone can run a different USB DAC with 384KHz (i lack a device to test myself) and verify channels, it should answer this for us.
Another option you could try is updating the RPi kernel to 4.9. There may be fixes/improvements to USB audio since 4.4. You can achieve this by doing the following:
apt-get install rpi-update
rpi-update
rebootJust bear in mind, 4.4 is considered official stable, 4.9 is still under development and could be unstable.
Thanks Dan, I’ve posted over on CA
but hopefully someone here could also try this to try and isolate my issue.
@moderators -any of you have the ability to test this?
Thanks,
.sjb
@support like the subject already explains I am having issues when upsampling to 384 kHz with DSP in Roon. The channels only get swapped when upsampling to 384 kHz. Upsampling to 352.8 kHz works fine, same goes for 192 kHz and DSD for example.
I assume you guys understand what I mean by this but very bluntly put; when I upsampling to 384 kHz it’s like somebody swaps my left and right loudspeaker cables.
I am using the following hardware
Synology DS716+II running Roon server
Auralic Aries
Chord 2Qute
Integrated amp
Thanks in advance!
Interesting I’m having a similar issue fir quite some time. The fact you have a Chord DAC would seem to implicate it.
I had first put this down to HQP, then Raspberry Pi (or Linux which still may be the issue considering the Auralic probably runs Linux) but the problem seems not to be common from the amount of replies I have got but we both have chrod DACs.
Anyone else any idea about this?
.sjb
I have read your thread and indeed it’s interesting. Have you already contacted Chord about this problem? Surely if it’s Hugo related (my 2Qute is practically a Hugo in a desktop form factor) they surely will be able to reproduce.
The confounding factor is that the inversion didn’t happen when a windows PC supplied the signal only when the Pi is in the loop.
So it could be either (or most likely both) contribute to the problem.
It certainly might be worth contacting Chord seeing as we have evidence of 2 of their products being affected.
If you contact them let me know how you get on.
.sjb
I was able to reproduce this today using DietPi + a Hugo + Roon Bridge. I did some more testing too, on different platforms and with other DACs.
This is a strange problem.
I can reproduce on Hugo, but not Mojo (or any other DAC I tried. We don’t have a 2qute, so I couldn’t give that one a shot, but I tried a handful of others and none of them are flipping channels around at 384kHz).
I can reproduce on DietPi regardless of the playback software–Roon Bridge, NAA, etc. I can even reproduce using the ALSA speaker-test utility, which plays a couple of seconds of pink noise to each channel in sequence:
speaker-test -D hw:1,0 -r 352800 -F S32_LE -c 2 # plays first in left, then in right
speaker-test -D hw:1,0 -r 384000 -F S32_LE -c 2 # plays first in right, then in left (wrong!!)
But–on a NUC5i5 running Ubuntu 16.04, the channels are correct always–even running the same speaker-test commands.
This suggests that at least something about the Linux environment is a variable here, in addition to the DAC itself, since I have two Linux machines here and only one is affected.
Ubuntu 16.04:
brian@nucbuntu ~ $ aplay --version
aplay: version 1.1.0 by Jaroslav Kysela <perex@perex.cz>
brian@nucbuntu ~ $ uname -a
Linux nucbuntu 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
DietPi:
root@dietpi-1:~# aplay --version
aplay: version 1.0.28 by Jaroslav Kysela <perex@perex.cz>
root@dietpi-1:~# uname -a
Linux dietpi-1 4.4.44-v7+ #2 SMP Sat Feb 11 16:07:35 UTC 2017 armv7l GNU/Linux
Interestingly, DietPi has a very new kernel, but an older ALSA compared to Ubuntu. I wonder if this is something that got fixed somewhere along the line in ALSA.
@Dan_Knight --is there a simple way to try bringing a DietPi device up to ALSA 1.1.0 without mucking with other stuff? That would be an interesting next step here.
2 Likes
Hi Brian,
Could be, worth a shot 
Yep, we offer a RPi Debian Stretch image, which will bump ALSA base and utils to a newer version:
https://packages.debian.org/stretch/alsa-utils
Our Stretch image is under beta, but should be stable enough for further testing with Hugo:
Failing that, as the x86_64 Ubuntu kernel seems fine, it may be a “bug” (or a possible RPi employed patch that breaks this) in the official RPi kernel that is the issue?
In regards to kernel, we use the official RPi kernel (some tweaks to HDMI audio etc) and try to keep it in line with official versions (4.4.50 currently).
1 Like
Ok, ALSA 1.1.0 isn’t it. The newer DietPi is showing the same behavior.
1 Like
Thanks Brian,
Possibily the last item to test would be upgrading the RPi kernel to 4.9, it may contain fixes/enchanments to audio/USB:
Failing that, it must be limited to ARM/RPi and/or its custom kernel fork. We could confirm this with testing USB DAC on a non-RPi ARM device (eg: NanoPi / Odroid ) and seeing if the same occurs.
1 Like
Failing that, it must be limited to ARM/RPi and/or its custom kernel fork. We could confirm this with testing USB DAC on a non-RPi ARM device (eg: NanoPi / Odroid ) and seeing if the same occurs.
Ok, that’s an easy test for me. DietPi + NanoPi NEO does not have the issue.
The main difference between the NanoPi image and the Raspberry Pi image is the kernel + boot stuff, right–anything else you can think of?
This is the DietPi kernel on the NanoPi…closer to what I have on Ubuntu than what’s on the Pi for what it’s worth. Maybe this is a regression in recent kernels.
Linux DietPi 4.9.4-sun8i #14 SMP Thu Feb 2 02:03:26 CET 2017 armv7l GNU/Linux```
2 Likes
Just for information, I’ve update to dietpi ver 149 and this has had no effect on the channel inversion.
.sjb
Hi John,
Thanks for letting us know. Sorry to hear this is still an unresolved issue.
I’am not really sure where we can go from here, as this issue appears to be limited to the RPi kernel itself (confirmed by Brian with NanoPi Neo working), and USB snd driver.
Unfortunately i’am short on time at the moment, and in all honesty, I dont believe I can find a fix for this in the kernel.
Not ideal, but a quick fix (minus delivery time) would be to purchase a NanoPi NEO for this DAC.
1 Like
Hi Support, @support
May I have someone to have a look at this issue again? I am encountering the same problem while doing DXD (352 & 384) upsampling (via Roon only). All other sample rates and DSD are working properly without this inverted issue.
My playback chain is as follows:
Antipodes DX Gen3 (Roon Core)
exD Roon Bridge (Roon Ready)
dCS Scarlatti dac
Please let me know if you need any info further, thanks!
Brgds / Gary!
I’ve tested latest Roon build 323 in this configuration:
Roon Core on PC Ubuntu -> Lumin U1 (function as a Roon bridge) -> USB DAC input of Esoteric N-05
I’ve not experienced channel reversal with Roon upsampling. So I think the problem is not likely to be in Roon Core.
I suggest you direct connect your dCS DAC to the Roon Core machine and see if the problem is still there or not. It may then be possible to draw a preliminary conclusion where the fault lies in.
Flag @AMP for dCS.