You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First, thanks for this script! It worked well for me on Ubuntu, but when I moved over to Arch a few months back, things became a bit more difficult, but particularly so with the last few wine updates. I ran into a variety of problems getting dotnet472 installed, and once I finally did get it installed and get Roon running, I could not get audio to my USB DAC which ALSA sees.
I started tracing down these issues one by one until I finally got to a working solution. I'll post it here in the hope it could save a similarly situated user a little time. (I'd submit a PR for this, but it requires a wine downgrade for anyone running the current wine packages on Arch -- a scenario that this script would not contemplate, I imagine.)
My working setup, including exclusive control of the USB DAC:
wine-5.11. Apparently, newer versions are hit and miss with the error seh:NtQueryInformationThread ThreadIsIoPending info class not supported yet. I'm not going to pretend to have a single clue what that means, but it showed up when trying to play to my DAC failed. Version 5.11 was reported not to have this issue in the wine forums, and works for me. (Downgrade in the AUR makes this simple if you're running the current version.)
winetricks: used current version (winetricks 20200412-1)
Follow the steps for "Manual Installation" from WineHQ's .NET Framework page. As they advised, I used a new Wine prefix. Before, winetricks -q dotnet472 always hung without completing. This recommended setup instead from WineHQ worked for me, except that I had to use $HOME's full path:
Use the wine prefix just set up to run the Roon installer and then to run the Roon application.
So far, the application seems stable, and I again have that beautiful high-quality signal path indicator lit! Hope this is of use, and apologies for the verbosity!
The text was updated successfully, but these errors were encountered:
First, thanks for this script! It worked well for me on Ubuntu, but when I moved over to Arch a few months back, things became a bit more difficult, but particularly so with the last few wine updates. I ran into a variety of problems getting dotnet472 installed, and once I finally did get it installed and get Roon running, I could not get audio to my USB DAC which ALSA sees.
I started tracing down these issues one by one until I finally got to a working solution. I'll post it here in the hope it could save a similarly situated user a little time. (I'd submit a PR for this, but it requires a wine downgrade for anyone running the current wine packages on Arch -- a scenario that this script would not contemplate, I imagine.)
My working setup, including exclusive control of the USB DAC:
wine-5.11. Apparently, newer versions are hit and miss with the error
seh:NtQueryInformationThread ThreadIsIoPending info class not supported yet
. I'm not going to pretend to have a single clue what that means, but it showed up when trying to play to my DAC failed. Version 5.11 was reported not to have this issue in the wine forums, and works for me. (Downgrade in the AUR makes this simple if you're running the current version.)winetricks: used current version (winetricks 20200412-1)
Follow the steps for "Manual Installation" from WineHQ's .NET Framework page. As they advised, I used a new Wine prefix. Before, winetricks -q dotnet472 always hung without completing. This recommended setup instead from WineHQ worked for me, except that I had to use $HOME's full path:
$ env WINEPREFIX=$HOME/newprefixname wineboot --init
$ env WINEPREFIX=$HOME/newprefixname winetricks --force dotnet40
$ env WINEPREFIX=$HOME/newprefixname winetricks win7
$ wget get 'https://download.microsoft.com/download/6/E/4/6E48E8AB-DC00-419E-9704-06DD46E5F81D/NDP472-KB4054530-x86-x64-AllOS-ENU.exe'
$ env WINEPREFIX=$HOME/newprefixname wine ~/NDP472-KB4054530-x86-x64-AllOS-ENU.exe /q
So far, the application seems stable, and I again have that beautiful high-quality signal path indicator lit! Hope this is of use, and apologies for the verbosity!
The text was updated successfully, but these errors were encountered: