Thanks for your input @jussi_laako. I have perfect music playing up to 192k 24bit PCM using latest build of dietpi using the audio chain detailed above but I run into trouble when trying for higher rates.
Do you mean that for DSD playback, or greater than 192k, I would need a custom kernel?
Am I trying to fit a round peg into a square hole here and should I try something else? I did try to use your NAA images but I think I may need to swap the Odroid for a rasberry pi to get it to run. My linux knowledge ends way before we start talking about customising a kernel
That is a good suggestion @dabassgoesboomboom - thank you. However, the point of this exercise was to remove USB from my audio chain. I’ve already demonstrated that this is worth exploring further and I’d like to get DSD 256 / 512 playing on the DAC as I have done previously, but this time without USB involved.
The Odroid board looks like a far better option than the pi - higher processing speed, no wifi/bluetooth to create unnecessary EMI etc etc
From your comment, it looks like the way forward would be to ask @jussi_laako to consider creating a version of his custom kernel for the Odroid C2 board…jussi, what do you think?
Most ARM-based SoC’s have totally horrible kernel support. If manufacturer talks about Android, the only kernel available is likely ancient one made for Android (3.14 or similar). So picking a board/SoC that has decent up to date kernel is actually very hard.
Since ARM platforms don’t have things like ACPI BIOS x86 platforms have, they need a lot of SoC and board specific configuration data to tell what kind of peripherals are connected, how and where. Because the board itself is unable to tell anything about it’s internal configuration. This means support for every single ARM-based board is usually huge amount of pain and suffering.
Thanks very much @dabassgoesboomboom for not giving up on this - much appreciated. I didn’t realise that the GPIO on some of the UP boards is pin-compatible with the rasberry pi GPIO. This is really good news for me as I can use this board with the I2S isolation hat and u.fl output connectors!
I need to make sure that my facts are straight regarding the compatibility of that connector …is that correct… but a board like this looks like it will fit the bill perfectly:
Don’t come to me for facts on this because I haven’t tried any of this stuff but yes, that’s the same board discussed in the thread I linked and the same board that comes in the fanless assembled unit I linked.
I would jump on that thread I linked and ask all the questions there. They seem to be tinkering with the same goal you have - I2S audio.
@jussi_laako are you able to confirm that I would be able to configure one of your HQPlayer images to output to the I2S headers of the UP boards? Or are the ‘hardwired’ to USB output? Having installed one, I realise that there is no login so I am assuming that end-user configuration is non-existent?
In order to provide I2S output, it looks like the boards need a BIOS update followed by some patching to the kernel, from here:
If you need a patched kernel you are probably better off with Debian or similar and install NAA package there.
But you can see how far you get with my images. My images or HQPlayer in general are not hard-wired, so all audio interfaces that appear as ALSA devices should work.
I’m personally not huge fan of these I2S interfaces, although with SOF and UpSquared you can do some improvements because it has an FPGA between SoC and I2S interface. But depends on what you are planning to connect…
Thanks Jussi, I will give your images a try first.
Regarding the I2S interfaces on these little boards, I agree that the output isn’t going to be top notch (particularly out of the rasberry pi, for example) but the odroid I’ve tried sounded pretty good and worthy of further exploration. My plan is to upgrade the power to (and on) all the individual boards and then isolate and re-clock the I2S output (using IanCanada’s FIFOpi) which should alleviate a lot of the problems. Then, once the signal reaches my DAC (over 2 inch long u.fl cables as opposed to 1m usb cable + associated interfaces) it will get re-clocked again by higher quality clocks before it hits the dual mono Bufallo dacs. After all that I’ll be able to tell if it’s worth it
That is precisely what I meant and what is is needed, because most boards generate the I2S clock from the CPU or HDMI pixel clock and it is all but great. Reclocking through FIFO certainly fixes it.
What I meant in the earlier post is that this reclocking FIFO could be implemented in the on-board FPGA (Altera MAX 10) of UpSquared (Up2). IIRC the smaller UpBoard doesn’t have this FPGA part. If there is already a suitable existing device to do the reclocking, then it is probably not worth playing with FPGA programming unless you are used to that.
That sounds like a good plan! That way there shouldn’t be problems using the onboard I2S.
but yes, that’s the same board discussed in the thread I linked and the same board that comes in the fanless assembled unit I linked.