Release 2024.03

Hi @Burkhardt_Petermann and @nquery

I’ve pushed out another update for the CM4 board. Interested if this makes a difference for you guys.

Thanks

ok thanks. unfortunately, i won’t be able to test until back on Sunday but will do so promptly.

Hi @spockfish

the first impression is good → crackling is gone.
What do you’ve change in the beta 2024.03.91?

My change should only affect the crackling.

1 Like

Sorry, edited my posting. The headphone amp was not full warmed up…

1 Like

Ok… this is good… let me know how it goes over time and if this is solid.

Yes it looks good (no crackling in using Ropiee as Roon endpoint and NAA client), but one thing (don’t know if it’s related to Ropieee):

My test configuration is

  • Holo Audio Red with the current beta from Ropieee
  • Red connected with USB and I2S to the Holo Audio May
  • Roon endpoint uses I2S out and the NAA client USB out
  • Roon upsampling to DSD512, HQPlayer to DSD256 or DSD512.

In this configuration DSD512 through HQPlayer has sometimes dropouts.
Using an extra RPi4 with Jussi’s NAA image has no dropouts here and so it seems not HQPlayer PC (with an Intel i9) related.
Can’t test it at the moment with the Red OS, because here currently only one service at once is possible.

@spockfish Back home and have been testing. 22 minutes now, and I think the latest update has indeed fixed the issue with CM4/Red … haven’t noticed a single dustpop/packet drop yet. (vs ~~ once/minute previously). Would be very curious to know what change you made wrt CM4 … thanks!

On the Pi 4 the USB bus needs to be (explictely) enabled. And with that selection you also choose whichh driver to be used: the ‘old’ one, or the new (upstream) one.

I choose the new one, which worked fine with the previous kernels (remember: my day to day listening routine is based on a CM4). However, with the latest change to RoPieee’s kernel stuff got more critical wrt performance of (sub) components. And it happens that the old driver is better performant then the new one. Which I knew, but I dismissed that because of ‘old’ vs ‘new’.

I’ve now switched back to the old driver.

Thanks

1 Like

Thanks. This is all but confirms what I thought was happening - USB packets were being dropped/delayed on the outbound/driver side resulting in the ‘dustpops’.

One more related question then - does the HQ Player NAA output driver buffer time setting have any actual impact in your implementation? Admittedly, I am still a little fuzzy on how this hint actually gets passed from HQPlayer config → NAA → driver. (@jussi_laako ?) I think it had some small impact but hard to empirically validate - making it smaller actually seemed to help a bit in my experiments. Regardless, leaving it at default/0ms works fine with your latest beta.

1 Like

It has to do with latencies induced by local bus traffic in the hardware and interrupt handling latencies, and the length of time different drivers disable interrupts for. If the latency gets too high, there’s a missed deadline, or at some other place a buffer overflow.

When the buffer is smaller, transfers are shorter but more frequent. But risk for buffer underrun and transfer overhead increases.

2 Likes

Not sure if it’s just me but I feel like ever since this update my Raspberry Pi 4 Model B Rev 1.2 has been running a little warmer than usual. Is that typical? My board temp has pretty much been in the mid 60s (C) for the past few days. It used to be pretty rare if I ever got above 60 degrees. Any cause for concern here?

RoPieeeXL 2024.03 (1451)
6.1.77-SPCKFSH-v8+

This is mine into a Flirc passive case

If you’re concerned about the temps you might consider a different case. I’ve had good luck with an Akasa Gem Pro (if it’s a PI4) or a Geekworm Passive Cooling Case (if it’s a Pi3). These are both heat sink cases and work pretty well. My office rig that I use alot rarely gets over 39C. That’s several hours a day. 60C seems pretty warm to me for a Pi running Ropieee.

This is mine in the Akasa Gem Pro, it really is a quality piece of engineering.

using the 1450/1451 release on a PI3 Display and a Pi4 Display, both run well but freeze after running some 12 hours or so and then the displayed clock is frozen too. Only manually booting them again gets them back working and then the same happens agains after some time …any idea?? With the older SW installed they worked for weeks…
FEEDBACK IS e1c1f596fddbac0c and 61ff4f614c6294d0 after reboot

1 Like

It is. The new kernel runs a little bit hotter.

Thanks for the recommendation. I grabbed this and my temp has dropped 20-25ish degrees. I’m now in the 38-41 degrees (C) range.

2 Likes

I’m really pleased it’s worked out for you, I have four of these in different locations and they are all working really well (and I think that they look good as well).

So again, they freeze every day now after several hours of use…