I have same problem with my Allo Sig… 
I’m even thinking of plugging in my old sparky with a usb ethernet adapter which seemed better handled than the ASIX chip on a usb2 bus… which gets stuck.
The adapter had the same chip but on the Sparky’s USB3 port it worked.
On the Allo USBridge Sig, if we limit ourselves to 384 and therefore half as much flow as in 768, it works but remains frustrating !!
Did you find a solution … in the end, should you switch to another streamer (RPI4 or Ultrarendu)?
Hi, yes my solution was my first choice until Allo joined in. I’m now using Sonore UltraRendu which is sublime. Zero issues since March😁
Hi @jussi_laako , WTA1 features at least 135 dB stop-band attenuation (mostly 150dB)
So sinc-L at 120dB attenuation is allowing higher HF leakage than WTA1 ?
Would be nice to have a 150dB attenuation sinc filter (adaptive tap length, non-apodizing) option for better comparison
PGGB offers the unconstrained tap counts and extreme technical specs you are looking for. You can satisfy your curiosity at pggb.io with a few of your own reference tracks.
Thanks @Daniel_Mance but I use HQPlayer not just with Roon but to upsample Apple Music, Spotify, Deezer, Soundcloud, Mixcloud. And the official Tidal and Qobuz apps.
At the same time HQPlayer is handling convolution for DSP crossover and room correction. And parametric EQ with headphones use. With all those streaming services own apps.
All on the fly…
I can’t think of any other DSP engine that can do all this.
@Daniel_Mance if PGGP does ALL this one day (not half of it), please shoot me a message and I’ll try it.
Maybe put in a feature request
PGGB is not built for usage with streaming services. You can use it only for local, physically present files, which need to be converted first to be fed into PGGB.
Of course this is known, hence my comment above:
"if PGGP does ALL this one day (not half of it), please shoot me a message and I’ll try it . Maybe put in a feature request "
I think calculation needs are too demanding to be used on the fly.
PGGB in that sense compares more to HQPlayer Professional.
Hence my ‘feature request’ comment.
Remember HQP Pro came well after the consumer Desktop and Embedded versions…
So you never know 
Anyway as per my linked thread above, I am a very happy HQP user.
Yes, I am also a happy HQP user since many years.
@dabassgoesboomboom , @miklats
there is a PGGB ‘real-time’ plugin for foobar2000. CPU acceleration is such that PGGB is 5x real-time (a 5 min track takes 1 min to process). Yes, its not a streaming plug-in so the local file delay is present per-track but in a playlist, foobar pre-processes the next track so the playlist is seamless, including EQ. IMO, PGGB is compelling enough that it should be auditioned and understood how it can become a useful component in a users toolkit.
I’m sure it is useful and compelling for some peoples needs.
I won’t repeat what I wrote that HQP allows me to do but I’m really not interested in trying anything that doesn’t tick all the things I listed because that would be a step backwards in my current user experience
Going back to foobar2000 (yuck!) is not only a step back in UX but also a step back in time , time travel that I don’t want to do
I’m very happily running HQPlayer on latest macOS and Win10 and Ubuntu
With HQP I can use the official apps for all streaming services. No 3rd party integrations, no plugins. Neat !
I’ve measured and I have seen measurements that it is 120 dB.
Why? Now the filters vary from 192 dB to 300 dB.
And truncated early transients and constant ringing… 
But not unconstrained factors. Since I’m doing minimum 256x with 64-bits. That would produce pretty horribly big files…
It is property of the filter in question. Use some other filter, like sinc-Mx for higher attenuations (~ 240 dB).
No, the delay is excessive. Since by definition with linear phase filter your playback delay is half of the filter length. Just divide the number of taps with two and that with sampling rate and you get the amount of delay.
Extremely long filters also cause extremely long filter ringing in time domain.
But PGGB truncates this initial delay, meaning that the transients within the truncation window will have distortion.
HQPlayer Pro provides exactly same filter set as HQPlayer Desktop and HQPlayer Embedded.
Thanks for clarifying.
I tested PGGB last spring, but it was too cumbersome to use, due to the need of creating my own files. HQPlayer plus Roon Combo is the perfect setup for me, eying sound and ease if use.
Like I said I am a happy user since early days of HQP.
Just for reference, in big picture, sinc-L looks like this:
I didn’t see the ability to convert to DSD.
@jussi_laako are you following this discussion? Chord Electronics Qutest DAC - Official Thread | Page 394 | Headphone Reviews and Discussion - Head-Fi.org
This is his indirect answer to me questioning the fact that in a previous post he had called HQPlayer’s algorithm “wrong”.
I’m curious about your take on this.
Yes, I am following the thread. But I don’t have account on Head-Fi or planning to comment there on his thread.
I think I’ve spent enormous amount of time talking about importance of transients, in both time and frequency domain (since these are mathematically related through 1/x relationship).
OTOH, he seems to be all the time ignoring all the errors in the digital data that are sourced from ADCs and other production stuff along the way to the file you are playing. He seems to be assuming source data to be perfect and correct in first place.
Rob as one extreme approach, MQA people have the opposite extreme. Both are claiming to solve same problem through completely opposing approaches. I offer things for both camps in HQPlayer.
But my personal opinion is that instead going for either extreme it is much harder to achieve something that is optimal from both points of view at the same time. This is where I’ve spent most of my R&D.
And yeah, HQPlayer stuff is also 23 years old now. Started back in 1998.
