Jriver and Devialet

[AlexS]

I am using mc19 for window 7 USB to devialet. But recently I found that foobar2000 just sound better. I do not know the reason and

I'd been using Foobar2000 for about a year, and have recently given JRiver a try. To my ears, the sound quality is identical (using WASAPI event-style in both). What I like more about Jriver is
1) the rich User Interface
2) Jremote ipad app, which beats Foobar's counterparts: MonkeyMote - functionally adequate, but visually poorly designed, and Apple Remote - visually appealing, but functionally flawed.
Unless I encounter unpleasant surprises during the trial period, I'll be switching to JRiver permanently.

BTW, I think I figured out (with the help of JRiver wiki) the reason for my occasional dropouts: Windows Defender kicking in, when it thought the system was idle, installing the latest definitions, and doing a scan. Jriver also recommends excluding a bunch of JRiver related folders and executables from Window Defender's targets. Thus far, I simply disabled automatic scans (as well as auto Windows updates in general).
However, it's interesting that Foobar never suffered from this issue. Perhaps, it's more robust in that sense. You can also configure Foobar to run its internal processes with high CPU prioriry (under Options --> Advanced), which I'd done. I don't see any such options in JRiver. Perhaps, it's already optimized CPU-wise?
I also noticed a very interesting difference between JRiver and Foobar, which I'd like to understand in more detail. When you use WASAPI in Foobar (and start playback), it spawns a new Windows process called WASAPIHost64 (or something to that effect). This process gets a high CPU priority. JRiver does not create a new process. From what I read, with WASAPI-event enabled, it initiates WASAPI playback from the same thread. I'd like to understand the implications of this difference in terms of performance, and the resistance to interferance from 3rd party processes.

---

Oh, Bryan, I did not notice you were using USB (I'm using AIR, which may be more forgiving to latencies, since it uses buffering on the Devialet side). Perhaps, in your case it's worth increasing the output buffer in JRiver from the 100ms default.