After some googling I found a Roon thread from 2019, confirming @Marin_Weigel comments.
John @ Roon Tech confirms the software does not execute transition commands at zero crosspoint, which in turn causes random pops on execution of transition commands.
John apparently filled a feature request back in 2019 to address this, is this in pipeline?
Hi @grizaudio ,
Apologies for the delay in getting back to you here.
I checked with the QA team and weāve submitted a ticket regarding this behavior, it is being tracked. Though, I am unable to comment on a timeline of when it will be addressed.
Thanks for the update Noris.
Fingers crossed. With the original feature request submitted in 2019, I wonāt get my hopes up.
Am I correct to assume this logic change needs to occur @ endpoint, which is why its a complex fix?
Okay, so, itās roughly one year later. I also have this rather annoying behavior and can confirm, after testing with different roon endpoints, itās obviously by nature when cutting a stream instantly, without some special treatment.
Itās somehow hard to believe that roon really pursues a vision of constantly improving listening experience. The very core thing here is the playback itself. Please do not put all your remaining efforts into something like ARC or future cloud based AI add-ons. My minimum expectation would be a flawless playback, beyond any doubt.
Great improvements sometimes come from the little things 
. Donāt hesitate to leave big visions for a while to fix the basics .
@noris Are you able to give us some feedback here?
To fix this issue, āI believeā the programming team will need to make changes to RAAT and endpoint programming/behaviourā¦
I canāt see it happening, as it impacts every non/certified endpoint.
Its a significant version change.
Curious do you use DSP? just wondering.
Yes, no idea, if theyād need to change something regarding the RAAT protocol itself or something on an upper level at the sender software. I think it looks pretty much like the cross-fade function. Donāt know if this is actually part of the protocol or just a function of the sender.
No DSP. Happens with PCM and DSD output through different endpoints.
Hi @grizaudio,
Better transient handling with manual track transitions has been a backlog ticket for some time. The ticket remains active.
Please allow me a chance to escalate internally to get a more precise sense of when it will gain traction. From my understanding, we intend to address this as soon as we have the engineering bandwidth.
Thanks @connor, as you are aware John @ Roon logged this ticket back in 2019.
Roon obviously knew this issue existed, well before I and others posted on it, which is frustrating considering the lengths I went to trying to debug/solve/prove it. Some basic communication early in the thread would have been appreciated.
Without trying to sound rude, there seems to be a significant flaw in the way Roon [RAAT] handles transition execution, this handling of transitions becomes especially audible for those using MUSE to execute DSP crossovers [as gain structure is very different to the average HiFi setup].
Personally, I would much rather engineering resources are allocated to fixing the āfundamentalā tough stuff, rather than investing āDEVā resources into ARC, which in my experience never works great and continues to be problematic especially in low coverage areas, when the native streaming app is not.
With Roon making a big song and dance about MUSE, its important to understand issues like this zero crosspoint execution ticket, hamstring the product for advanced DSP speaker users.
Another fundamental ticket, involves procedural DSP [MUSE] logged back in June 22: