For random reasons, I had a Pi 5 in a Flirc case with Ropieee installed. I coupled it with a Topping HS02 USB isolator to drive a Holo May KTE in DSD256. Without having a fancy streamer to compare with at hand, this modest NAA endpoint sounds really good (meaning, it sounds as if is not there 
)
2 Likes
It har certainly been up before, but, is there a kind soul who can tell me if there is a real audible difference between NAA image and NAA image ramfs. Any drawbacks or limitations?
No audible difference. Main difference is that with the ramfs one you can always completely safely just pull the power plug and it is fine. In addition you can remove the boot media after booting up and it continues to work. Downside of ramfs image is much larger memory footprint because there’s a lot of redundant and never used data being held in RAM, and that you cannot store any setting changes that would survive reboots. Also the regular images contain more utilities for advanced use because many of those would be useless on ramfs. It is very unlikely though that the regular one would get broken if you just pull the plug with those, thanks to modern journaling filesystem.
1 Like
Hello,
Here is an error report.
I let RopieeeXL do its upgrade today and HQPlayer Embedded on Ubuntu will no longer play PCM 384kHz to it. After reading some similar issues from back in November, I then upgraded to the latest version of HQPlayer embedded for Ubuntu, but still receive the same error.
The version of NAA on RopieeeXL is 5.1.3.
The error in the log is:
NAA output requested format not available!
NAA output clNetEngine::PushPCM(): engine not ready
clHQPlayerEngine::Execute(): push to FIFO failed
This is when sending PCM at 384kHz. Sending DSD 256 on the same streamer to my other DAC works fine.
I have another streamer running NAA 5.0.2, and it still works fine sending both 384kHz PCM and DSD256 using the latest version of HQPlayer Embedded.
Maybe you have already fixed this issue with a later version of NAA. If so I will send a note to the Ropieee developer to hopefully have the version updated in the next release.
I’ve saved off the entire log if you need it.
Thanks
Sorry, but I think you’d need to ask RopieeeXL people. It is not not among my supported OS and thus the support is up to the entity providing the OS.
I’d like to make a USB stick with NAA 5.13. I can’t get the .img file to work with Balena Etcher. I’ve tried the 2 images (normal and RAMFS), reloaded the files several times but still the same thing.I’ve also tried several USB sticks.
I tried it with Rufus and it works!
1 Like
Yes, on Windows Rufus is a good option. Sometimes balenaEtcher fails in mysterious ways. Rufus is more reliable, but it is Windows-only.
On Linux and macOS of course “dd” always works, but it is a dangerous and command line only.
RoPieee NAA Input:
Any chance to get dtoverlay=dwc2,dr_mode=peripheral in the config.txt to get the RPi 4 in peripheral mode (USB Gadget)? I added it manually by inserting the card in a PC, but seems like it’s overwritten.
@Stefano_Antonelli @stockfisch @jussi_laako
One of my UP Gateway NAA endpoints seems to have died. I’ve made sure I updated its NAA image, the Ethernet port lights flash, but it does not respond to ping. I had a Pi 5 assembly in a FLIRC case waiting for installation on a different system, I swapped it in to drive my Holo May via an Intona isolator. It seems to be working fine.
Is there any reason to try to find a mini-PC replacement for the Up Gateway, or should I just stick with the Pi 5?
Rpi5 as a naa has hardware issue with the usb, you can’t go beyond dsd256 or pcm 768.
Rpi4 has no such limitation
Thanks for the warning, I’m currently using DSD256, will keep that in mind.
In my bedroom, I am using a rpi5 to run hqplayer desktop dsd512x48 to a rpi4 as NAA, that works fine. But you can’t use the rpi5 as NAA to go beyond dsd256
Update: I plugged monitor and keyboard into the Up Gateway, it goes through the boot sequence until it complains it failed to decompress the kernel and then drops into a weird password dialog (something in the Up Gateway BIOS, presumably). I’ve tried with two different flash drives. Any other suggestions?
UP Gateway BIOS has feature that if it notices USB boot media changing or not attached, it switches trying to boot from eMMC instead. So you may need to connect keyboard and monitor and check the active boot device…
I recommend trying to boot memtest86 and letting it run at least one complete cycle. If RAM has gone bad it will cause weird issues.
1 Like
705.6k PCM… Meaning that 44.1k x512 DSD still works, but 48k x512 doesn’t.
1 Like
Thanks. Memory test for 1.5 cycles was perfect. Very strange, the problem continues, even though boot device #1 is USB as it should be. It’s quite puzzling that it can run memory tests for hours without any issue but then fails on decompressing the kernel. Nothing changed as far as I can tell, it had just been running for years, with just a couple of NAA image updates along the way.
Which tool do you use to write the images? And are you using the regular one or the ramfs one? I’m running ramfs image on mine. But regular one will use quite a bit less RAM.
Using Balena Etcher to write the ramfs .img. Note that the UP Gateway had been working flawlessly for a long time, booted from an earlier ramfs NAA image. I’ll try the regular one just in case.
Update: The regular image worked! Could it be that the RAM test does not really reach the whole memory, and the ramfs image was hitting some flaky bits that the regular one does not?