About 1.5 seconds is normal. You can try to make it shorter by enabling short buffers.
Hi @jussi_laako - does the new naa-423-x64ramfs try to address these UAC2 input issues discussed or this new update is focused on other fixes?
Maybe, just threw my guess on the thing, but it also has 5.15 kernel which is not the case for earlier ones, so may not be directly comparable.
But overall this syncs with latest HQPlayer OS release, so the two are aligned again in terms of kernel and networkaudiod.
1 Like
No worries. I’ll give it a try and will report back
I understand debugging is very tricky for this thing (and maybe not possible to fix at all) but were you actually able to reproduce the issue yourself that I described with UP NAA input?
For example the playlist I made where each track changes sample rate? Play only a few seconds of each track and press next track.
If it can’t be fixed it’s not a big deal to me because I am using RME ADI-2 input daily. But I would then have to stop recommending UAC2 input at all (even RPi4), in this thread.
I haven’t got time to attempt reproducing this. I wanted to get the release out for other reasons, so I made a small change in suspected area of the code.
No problem. I tested and new release is broken for UAC2 input - not able to use UAC2 input at all.
So would have to stick with v4.20. But even that is broken in a different way (the auto sample rate switching works but with static)
It’s probably ok for fixed rate USB sources.
Something broke with UP UAC2 input at some point but I didn’t note the exact release unfortunately. I wish I had.
RME ADI-2 is definitely the only thing I would currently recommend for auto sample rate switching now.
4.2.0-ramfs I assume? That is 5.4 kernel. Regular 4.2.0 is 5.10 kernel and now 4.2.3 is 5.15 kernel.
I think the driver got broken between 5.4 and 5.10 kernels.
But strange if RPi4 works with 4.2.0 since I think that is 5.10 kernel too, not 5.4 (IIRC).
1 Like
Yep all my testing with UP Gateway has been with ramfs version
4.2.0-ramfs auto sample rate switching works, but comes with the nice feature of the static. It’s different to the Chord white noise blast, because here you actually hear the music. It sounds like bad FM radio reception with the analogue dial, when you didn’t quite get it on the correct frequency with the knob.
Going from timeline when I first reported this issue last year , it broke before 4.2.0 which maybe means it broke before 5.4 kernel ?
But I didn’t save your earliest NAA OS images unfortunately and they’re no longer available.
I mean from this “doesn’t work at all” point of view. That is more black and white.
Ok yeh. Maybe the tweak you did broke it?
If its the same kernel as RPi4 4.2.0 then something else has broken it
RPi4 is also on 5.15 kernel now. But on 4.2.0 generic x64 image is on 5.10 kernel and so is RPi4. Only 4.2.0-ramfs uses 5.4 series.
Ok so
4.2.0-ramfs auto sample rate switching ‘works’ (with static) - 5.4 kernel
4.2.0-RPi4 auto sample rate switching ‘works’ (with static) - 5.10 kernel
4.2.3-ramfs auto sample rate switching is broken - 5.15 kernel
So to complete the picture, I need to actually test 4.2.3-RPi4 image, which I haven’t yet tested.
This might suggest it broke between 5.10 and 5.15 kernel?
I will test and report back.
At least for now, I would not advise anyone to buy an UP Gateway for auto sample rate switching. It still makes for one of the best NAA outputs of course, running NAA OS.
1 Like
Hi @jussi_laako
Tested 4.2.3-RPi4 image and 4.2.2.-x64 just now
- 4.2.3-RPi4 auto sample rate switching ‘works’ ! (with static) - 5.15 kernel
- 4.2.2-x64 auto sample rate is broken, just like ramfs version - 5.15 kernel
- 4.2.3-ramfs auto sample rate switching is broken - 5.15 kernel
- 4.2.0-RPi4 auto sample rate switching ‘works’ (with static) - 5.10 kernel
- 4.2.0-ramfs auto sample rate switching ‘works’ (with static) - 5.4 kernel
Note for the 4.2.3-RPi4 to work, I need to manually change config.txt and add dtoverlay=dwc2 - it doens’t work ‘out of the box’.
I know this result of 4.2.3-RPi4 working may not make sense (same 5.15 kernel as ramfs) so I repeated yesterday’s testing to double check 4.2.3-ramfs and same results again today - very repeatable , very broken.
So if you can fix the static issue, likely RPi4 should be a good option (not only UP Gateway)
1 Like
That is normal, equivalent of making the BIOS setting changes on UP.
Obviously the change I made didn’t fix it… It will be hard to figure out if it doesn’t happen 100% reliably on every rate change.
Since these use same kernel, but the other one is broken, I can try to revert one fix and make a new build in case the regression is now caused by the fix that used to work earlier. Other alternative is that the DWC3 controller driver has got broken somehow (RPi uses DWC2 driver).
1 Like
Yep let me know if you can make 5.15 kernel ramfs build, reverting that fix you added, and I’ll try it.
Hi,
I would like to update that for a few weeks I have been able to use HQP nicely after receiving the Mutec 1.2 converter.
I am using: Apple music on iPhone (lossless) > AirPlay > Zen Stream out at 44.1KHz > S/PDIF > Mutec 1.2 > USB > UP Squared with bootable image of HQP embedded (upsampling to 705.6KHz) > USB direct or SRC-DX > Chord Qutest
I would appreciate answers to the following:
- I did not try all the filters, but I noticed that I can’t play poly-sinc-gauss-xl(a) and poly-sinc-ext3. is it because the UP Squared (intel pentium N4200) cannot run those at 705.6KHz rate? (as I tried 352.8 and it works somehow). I bought the UP Squared for using the OTG input but as it did not work well, I bought the Mutec 1.2 to connect between the Zen Stream and the UP Squared.
- if it is the UP Squared’s limitation, what other silent computer models can be strong enough to run the filters (taking into account future-proof upsampling to 1536KHz and handling PCM to DSD conversion)? And regardless, is it advantageous (on sound quality) to use a more powerful computer even for running filters as sinc-M , sinc-L, poly-sinc-gauss long?
- is there an immediate advantage in using NAA? how can I use it if I still want the Zen Stream to be my first input as described above?
Thanks!
Likely that is CPU power limitation of the UP Squared.
sonicTransporter or similar if you’d like to have off-the-shelf. Or you can build one yourself using for example Streamcom FC10 case.
Immediate advantage given previous question is that the HQPlayer computer doesn’t need to be silent since it can be located in a different room away from the listening position.
Now there are two test builds available.
-1 drops one fix
-2 switches from realtime kernel to a regular lowlatency one
1 Like
Both broken. But this time I have some useful information about ‘broken’.
I hooked up the UP Gateway to HDMI Monitor and both are broken in different ways.
For -2 below I see something about dwc3
Note: both start playing 44.1k track fine but soon as sample rate changes, they both break.
Interesting that it works with the DWC2 driver on RPi. So DWC3 driver has become broken in new ways…
1 Like