I choose 250ms for both input and output, otherwise I have some funny issues with jplay iOS to mpd, that I could not pause the music completely even when I pressed pause on jplay iOS.
I think it’s a mpd issue but hqplayer buffer time setting fixed this
Thanks very much for your suggestion
Thanks very much for suggestion.
Then I have to switch from 100ms to 250ms
I believe it is still very much worth the effort to configure HQPlayer to output 96/24 instead of using the built-in SRC in the speakers. Same goes for most AVRs that do the same, either to 96/24 or 192/24.
Lower power NAA’s usually benefit from smaller buffer values. But also depends on your network infrastructure. On wired ethernet and low power ARM CPUs, smaller buffer sizes may be better. While on WiFi the medium ones may be better. Larger ones one better suited for more powerful NAA’s with a good network infrastructure.
Default is usually a good choice unless there is a reason to change.
When you refer to “better”, is that anything to do with sounding better or as long as you can play music with no stuttering, you are good with using any buffer size?
I am not using the speakers for this, I use Roon for up and down sampling and probably HQP is doing this better, for me the inconvenient implementation of switching to different outputs in HQP let me go the route via Roon. But also I listen for app. 90% only to radio via my speakers nowadays, I know what a waste for these speakers……
Thanks so much for your info.
Starting from 10 ms that I used for SOtM 200 I changed to 250 ms for rpi4.
I sometime found small click/bop at 250 ms.
Setting 100 ms click/bop disappeared.
I believe that 100 ms works fine.
I have classical network: Router/switch/cat6 cable/rpi4 with NAA
P. S. Cyan2 is wonderful with your HQPlayer 
Have a nice day
Gerardo
Default and 250 ms should sound the same. But with those low power NAA’s, the default setting may be more reliable (less likely drop-outs/clicks/pops).
Why not JPlay iOS straight to HQPlayer?
Because I am using hqplayer desktop so I need to use a rpi4 as a upnp renderer/usb input NAA to hqplayer desktop.
You bought an Embedded license just for the RPi4 UPnP input feature?
I am using a rpi4 as a upnp/usb input so I don’t need to use hqplayer embedded with jplay iOS
But what is the RPi4 actually running?
Rpi4 running upclimpd and mpd as upnp media renderer, minimserver for connecting to local content, usb input NAA to hqplayer desktop pc and usb output NAA out to dac. All in one
Jplay iOS as upnp controller app for Tidal, qobuz and local content
Hello Dear Friend,
I was reading your February 7th post again and I think those measurements were conducted without correction for Cyan2.
You have done a great job with great commitment and I thank you very much for your contribution.
Since you own Cyan2, do you have the time and desire to do some measurements again with the Cyan2 correction?
Unless someone else has already done them.
cyan2 has brought about a huge improvement in my chain.
Thanks so much in advance for your help
Have a nice day
Gerardo
… and I should add a question to @jussi_laako : what does the dac correction do (how does it work)?
One of the things I’m not ready to discuss in detail. One reason for that also being that rather than being a single static thing, it is an extensible framework. It does set of things now depending on DAC and output format, and it will likely do more things over time.
The DAC corrections seem to be decoupled from the modulator/output format/filter. I would have thought that there would be an ideal combination for each DAC.
Oversampling filter is up to personal preferences/sensitivities, also related to music genre being played, but it is not related to the DAC hardware.
Regarding output format, some format(s) work better on a certain DAC. And some modulators are better suited for some DAC. Although for example ASDM7EC-ul/light/super work the same on the same DAC. So depending on DAC it is more the choice between 5th and 7th order rather than some specific variant of the modulator.
I didn’t want to force a particular format too much regarding corrections, so many times I support more than one output format for a DAC. Corrections deal with the errors caused by the DAC implementation.
Any reason why dsd256 and not dsd512? Purely soundwise choice or upsampling related?