I have version “5.0.3-3” from Debian Sid, with a recent-ish reinstall with the roon-on-wine script, both of my computers (laptop and desktop also running Roon Server) are affected, same exact versions of everything.
I’d happily debug this if given some pointers or settings to change, if you have ideas 
Ah and I’ll start with hardware specs in case we discover it matters:
Software wise, both are up-to-date Debian Sid, both recently reinstalled so it’s not an old feature carried from a 2019 package that suddenly broke.
A freshly reinstalled Roon client with roon-on-wine script reproduces the same behavior of using 1 CPU between roon and wineserver.
hmmm… ok. Maybe it is something in the settings.
When I looked yesterday everything was fine, but later on I also had a huge CPU load.
Unfortunately I forgot what I did, so I couldn’t reproduce the scenario 
We should probably try to decide whether to continue in this thread or my dedicated one. I’ll post specs when we know
I’ve moved the related posts over to here.
Thanks, it’s a mess now but better to have it all here
We don‘t have that in Windows?
I looked around in the 903 feedback thread and searched a bit but didn’t find any reports about Windows on the forum, at least when I looked 2 days ago
I just tried to go through and change all settings in my new vanilla install from the spockfish script and none of them made any difference.
Edit: No difference between Xorg and Wayland
Edit: God, there is a thing called “wine profiling” that has to do with the actual grape juice, this does not make googling easier
Same here:
The behavior started after updating to build 903. The increased fan activity due to the load is annoying…
Looking at the machine specs people have posted, it’s not caused by weak machines
I’m not experiencing any issues. Here’s what I’m running:
Ubuntu 20.04.3
Wine 7.0
Kernel 5.13.0
I’m running a Xeon with Intel graphics and no third-party drivers. It appears that those who have problems have two GPUs.
(I have the issue) No 3rd-party drivers either. Thanks for your observation, but I just blacklisted the amdgpu module, but no change.
Nope, my laptop with its integrated Intel GPU has the same issue as my desktop with dedicated GPU.
I’ll have a go at fiddling with wine settings this weekend, and I’ll try to provide some info and logs so that we can compare them with those from people not having this issue.
I upgraded to Wine 7.0 from WineHQ, no change 
I used the WineHQ official:
wget -O - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add -
sudo add-apt-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ focal main'
sudo apt update
sudo apt install --install-recommends winehq-stable
Yes, I had found out about the 7.0 release and had edited my above post in the meantime. Unfortunately, no change after upgrading
While stracing, I noticed that Roon was creating a few threads over 10 seconds, is that expected?
Stracing for 10 seconds yields ~40 MB of text… It’s mostly variations of this for roon process
1523316 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(21, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 sched_yield() = 0
1523316 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
1523316 write(3, "\214\0\0\0\0\0\0\0\0\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0"..., 64) = 64
1523316 read(4, "\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
1523316 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(21, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
With some instances of this in between:
1523316 futex(0x7d2dfc78, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
1523383 <... futex resumed>) = 0
1523316 <... futex resumed>) = 1
1523383 futex(0x7d2dfc28, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
1523316 futex(0x7d2dfc28, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
1523383 <... futex resumed>) = -1 EAGAIN (Resource temporarily unavailable)
1523316 <... futex resumed>) = 0
1523383 futex(0x7d2dfc28, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
1523316 getpid( <unfinished ...>
1523383 <... futex resumed>) = 0
1523316 <... getpid resumed>) = 1523316
1523316 futex(0x7d2e9b9c, FUTEX_WAIT_BITSET, 2, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
1523383 futex(0x7d0e5e68, FUTEX_WAKE_PRIVATE, 1) = 1
1523363 <... futex resumed>) = 0
1523383 futex(0x7d2e9b9c, FUTEX_WAKE, 2147483647 <unfinished ...>
1523363 futex(0x7d0e5e18, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
1523383 <... futex resumed>) = 1
1523363 <... futex resumed>) = 0
1523316 <... futex resumed>) = 0
1523383 futex(0x7d2dfc7c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
1523363 ioctl(113, DRM_IOCTL_AMDGPU_CS <unfinished ...>
1523316 futex(0x7d2aefcc, FUTEX_WAIT_BITSET, 2, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
1523363 <... ioctl resumed>, 0x7f9c5902cac0) = 0
1523363 futex(0x7d2aefcc, FUTEX_WAKE, 2147483647) = 1
1523316 <... futex resumed>) = 0
1523363 futex(0x7d0e5e6c, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
1523316 recvmsg(21, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(21, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 poll([{fd=21, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=21, revents=POLLOUT}])
1523316 writev(21, [{iov_base="\224\1\22\0\v\2@\2 \2@\2\31\275\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., iov_len=72}], 1) = 72
1523316 getpid() = 1523316
1523316 poll([{fd=21, events=POLLIN}], 1, -1) = 1 ([{fd=21, revents=POLLIN}])
1523316 recvmsg(21, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="#\224\246\245\0\0\0\0\2\0\0\0\37\2@\2\v\2@\2\31\275\6\0 \2@\2!\2@\2"..., iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 72
1523316 recvmsg(21, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
1523316 write(3, "\214\0\0\0\0\0\0\0\0\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0"..., 64) = 64
1523316 read(4, "\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
1523316 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 recvmsg(109, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 poll([{fd=21, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=21, revents=POLLOUT}])
1523316 writev(21, [{iov_base=">\3\7\0\v\2@\2\3\0\340\2^\7@\2\0\0\0\0\0\0\0\0\376\0162\10", iov_len=28}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 28
1523316 recvmsg(21, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
1523316 sched_yield() = 0
1523316 rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
And the following for wine process:
947418 read(26, "\214\0\0\0\0\0\0\0\0\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0"..., 64) = 64
947418 write(27, "\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
947418 epoll_wait(10, [{EPOLLIN, {u32=412, u64=412}}], 128, 55) = 1
947418 read(26, "\214\0\0\0\0\0\0\0\0\1\0\0\1\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0"..., 64) = 64
947418 write(27, "\3\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
947418 epoll_wait(10, [{EPOLLIN, {u32=412, u64=412}}], 128, 55) = 1
I’d be curious to find what a non-affected roon-on-wine process looks like. You can try with strace -fp $ROON_PID -o roon.log and Control-C after about 5 to 10 seconds.
I have MESA 21.3.5 (Debian Sid), you can look at the detailed versions there: PrivateBin (it’s a bit verbose).
My laptop has the same versions of everything, but a single non-4K screen at 1920x1200 and integrated Intel GPU.
Mine looks exactly the same. I hope someone who doesn’t experience the issue can compare