XDMS has two operating modes, Discovery and Concert
- Discovery mode only caches the current track and then only fetches / downloads the next track when the current track is finished. The gap between tracks depends on file size and Internet speed but typically under 3 seconds. In this mode you can skip jump, change queue order and everything else
- Concert Mode caches the current track and the next track in the Queue to deliver a short as possible gap whilst maintaining Sound Quality. In Concert mode, changing queue order, random play and other Functions such as jumping, skipping are not allowed
In pretty careful testing, there is no discernible SQ difference between Discovery and Concert
Discovery looks very close to TAS.Serial in that only one track is downloaded, pre-processed and played.
Concert looks like similar to TAS.Batch with the difference that Batch-size is two (I believe TAS.Batch-size is 20 or so)
I assume that the soniq challenge is to have two parallel processes running:
- Playing a track
- Downloading and pre-processing a track (this process may negatively impact the SQ of Playing a track)
With Concert-mode:
A) Are you fetching Batch #2 WHILE playing Batch #1(-> risk of negative soniq impact, but closer to gapless, i.e. good UX, see above), or
B) Are you fetching Batch #2 AFTER playing Batch #1 (-> no risk of negative soniq impact but you will have double wait time after each batch -> bad UX)
Clearly, Roon is following strategy A) above - this along with other design choices limits the SQ potential of Roon...
I beleive that XDMS is also following A) but based on
@EuroDriver's "there is no discernible SQ difference between Discovery and Concert" we are in good hands and - we can always move to Discovery.
The approach of having dual-modes (Discovery | Concert) leaves the ultimate prioritization (SQ | UX) to the end user - smart move.