camott

Yes I already do that. Just like my UI as clean as possible. All good.

A couple of minor non-functional tweaks if I may: 1. whatever the number is, can you only show that actual number of configured pipeline records in the Matrix configuration tab of HQ OS - it really clogs up the UI (I see that you are already doing so in the logs - yay) 2. with that in mind, could you also provide for a choice of only 2 pipelines for us standard 2 channel users??

V_120 installed successfully using my DIY cable. Love the giant volume readout when using the remote! @OE333 Thanks for being so responsive to community requests.

@OE333 is this the same build/revision as you have posted under “extended firmware” on your GitHub site? The version number is v_120 and timestamp of 5 days ago. But notes are 2 months old. Thanks!

Interesting. I am surprised that installing a dedicated ethernet card instead of using built-in ethernet actually made a significant difference. Do you have a measure of how much cpu load was lowered ? a few percent? or more?

But this is the buffer time on the NAA device USB output to DAC ... what does that have to do with network flow before the NAA device? (edit: regardless, switch between HQPlayer OS Server and NAA HoloRed is an unmanaged TP-Link SL108 with 802.3x built in) If output is via NAA downstream, then does the short buffer setting affect the NAA application level FIFO?

Thanks! Got most of that. Struggling to figure this one out, but pushing DSD1024 to NAA on HoloRed (pi4) with Default or 90ms buffer time, I get the occasional light dust tick/pop, say 1 per minute or two , which I assume is a block/packet being dropped by buffer overflow. Yet, if I change it to something much shorter like 10ms it's clean. Makes no sense ... This is the only point I didn't fully get. Are you saying that the short buffer setting has no impact when source is streaming/file and output is NAA? Does it not apply to the NAA application level FIFO buffer?

Hi @Miska Still a little fuzzy on the various buffers in HQPlayer and NAA. 1. I am now seeing the lower/ouput buffer info in HQPClient with NAA 5. Is this the output on the NAA device downstream or the HQPlayer device? I assume the former otherwise it would have worked without yesterdays NAA5 release? a. If so, what size/time does it represent? b. if not, is there an application level output buffer in NAA on top of the hardware driver buffer (see #4 below)? 2. When you say that with an "endless" source it's roughly 10 second intermediate buffer, is this referring to the input or output? I am mainly using Roon as input and the input buffer never shows any info. 3. Are either of these related to the "short buffer" (normal/short/minimal) setting? 4. I assume that none of this is related to the audio backend "buffer time" (0 being driver default) for, in my case, NAA device. Correct? thanks for the constant improvements!

Ok thanks for confirming. Yes I can also do ASDM7EC-light @ DSD1024. I thought that offloading was only about filters/convolution - what does GPU offloading do vs e-core offloading that frees up the p-cores to modulate ASDM7EC-super @ DSD1024?

From what I am gathering from this and other reports, is that it's not yet possible to do ASDM7EC-super at DSD1024 without a GPU or overclocking ... is that correct?

Can you clarify what kind of use-cases that would apply to? Like HQPEmbedded inside a DAC/all-in-one?

Pretty sure he means DAC/device directly connected to HQPlayer Embedded, not via NAA. NAA doesn't have support for anything other than the audio stream afaik.

They would be really great. I sometimes use the DAC200 directly from Roon in a grouped zone and being able to control master volume from the Roon App would be very helpful. Wouldn’t work via HQP of course … nudge nudge @Miska

ok so after further testing I am going to retract most of what I said yesterday. I think my my bios settings were possibly causing some issues with tests. with testing today, 192 -> DSD1024, ASDM7EC-light, multicore="1", all of the standard filters with ecores=default/pool/filter. but ecores="filters" gives the lowest overall cpu temp/power consumption (standard filters == ext3/gauss-long/gauss-xla/gauss-hires. filters like sinc-MGa do not work)

After further testing, I get best performance with ecores="default", then "pool", then "filter". Somewhat the opposite of your testing. Multicore="1" helps each a bit (at the cost of higher overall cpu load/thermals of course). With ecores="default" and multicore="1", I am just able to eek out gauss-long/ext3/gauss-hires + ASDM7EC-light @ DSD1024 on my non-overclocked 14900-k.