Problem with 32 bit Wine DirectX audio, ALSA related?

Zare said:
The latest packages behave the same as quarterly.
Click to expand...
You mean you don't have the driver name or the audio not working as you want ?
Because I have this:
 

Attachments

  • wine-devel.png
    wine-devel.png
    25.1 KB · Views: 29
Some good news today! There were 2x posts in the Reddit FreeBSD forum: 1x on using LSU steam and another post on using the "steam bottler".

"steam-bottler" pkg installer adds (a fix) to the installed wine bottle to use the OSS libraries (instead of ALSA) with wine 10.0_1,1. And.. the fix works! I installed the PC/Linux version of Dwarf Fortress and for the first time on *BSD... I hear music in the game! Another game that was not working under LSU steam (aka the game literally crashed while booting/starting) runs flawlessly under "steam bottler".

Dwarf Fortress actually "ran" under Steam/LSU, but had no sound. Not a complete deal breaker, but music and sound while playing Dwarf Fortress is kind of cool. (YA - I know I could also play the Unix version of Dwarf Fortress :cool: )

NOTE: That I am not playing very extreme Windows games -- these are pretty small Windows based strategy games. Your mileage may vary (YMMV).

Here are the 2x posts on Reddit
  1. FreeBSD Steam with LSU
  2. FreeBSD with steam_bottler
I will say that "steam_bottler" is noticeably (A LOT) faster than Steam/LSU on boot up, running a game, etc. I was pretty amazed at the speed. So the FreeBSD forum comments about wine-proton being (slower) seem to be correct at the moment.

Shout out to Reddit user: u/Chester_Linux for the write ups!
 
Coincidentally, I'd been struggling in with this recently, nearly to the point of dual-booting a SystemD-less Linux distro just for Wine. However, this port of Proton Experimental 10.0 yielded a couple of staggering successes in running things (both 32 and 64-bit) that nothing else would – with working sound! I don't use Steam, but it's apparently (co-)maintained by at least one author of steam-bottler.

In terms of the audio driver, it's been a toss-up in my cases between sound=oss and sound=pulse. You may need to tinker with it a bit, for instance by installing 32-bit packages for Gstreamer plugins, PulseAudio etc. with the usual /usr/local/bin/pkg32 script.
 
CShell said:
I will say that "steam_bottler" is noticeably (A LOT) faster than Steam/LSU on boot up, running a game, etc. I was pretty amazed at the speed. So the FreeBSD forum comments about wine-proton being (slower) seem to be correct at the moment.
Click to expand...
Proton takes a few moments to set/check/update a separate Wine prefix for a game each time you launch it. The implication that wine-proton is somehow worse at game performance is complete bullshit, though.
 
shkhln said:
Proton takes a few moments to set/check/update a separate Wine prefix for a game each time you launch it. The implication that wine-proton is somehow worse at game performance is complete bullshit, though.
Click to expand...

Here is what I currently see with steam/LSU/wine-proton
  1. The steam product itself under LSU/wine-proton works very well. Running "steam" is far superior to the running steam application used by the "steam-bottle" product at the moment
  2. The download of games (aka the usual steam game download screen showing over-the-net game download, proton patch installs, etc) - also very good
  3. Running games under wine-proton (is broken) for Nvidia cards because there is an NVidia performance overlay that is taking over "most" of the game screen when (any) steam game is launched. I have tried to research various ways to turn off the NVIDIA performance overlay but nothing has worked so far.
  4. Sound on some games (notably Dwarf Fortress for PC) is not working
  5. Some games simply 'core' dump the wine-proton binary - and do not run at all
  6. Your feedback on wine-proton performing (updates) at boot/run time is valid. But the user perception when comparing wine 10x and win-proton-9.0.3 load/run/speed performance is still valid.
  7. One thought is to (at least optionally? or run side by side? either or?) replace wine-proton with the wine 10x with the OSS library fixes (shown above) in the LSU set up.
That's where it is (today). Tomorrow it will likely be better. These reviews/comments are obviously a "point in time" and everything changes (hopefully for the better) going forward.
 
CShell said:
Running games under wine-proton (is broken) for Nvidia cards because there is an NVidia performance overlay that is taking over "most" of the game screen when (any) steam game is launched. I have tried to research various ways to turn off the NVIDIA performance overlay but nothing has worked so far.
Click to expand...
Here's how Nvidia overlay actually looks like:
nvidia-overlay.png


CShell said:
Sound on some games (notably Dwarf Fortress for PC) is not working
Click to expand...
Was this ever reported?

CShell said:
Some games simply 'core' dump the wine-proton binary - and do not run at all
Click to expand...
Or this?

CShell said:
Your feedback on wine-proton performing (updates) at boot/run time is valid. But the user perception when comparing wine 10x and win-proton-9.0.3 load/run/speed performance is still valid.
Click to expand...
In both cases you are using wine-proton: https://github.com/es-j3/steam-bott...c21896861751889448746e/src/steam-bottler#L152.

CShell said:
One thought is to (at least optionally? or run side by side? either or?) replace wine-proton with the wine 10x with the OSS library fixes (shown above) in the LSU set up.
Click to expand...
That's not technically feasible. wine-proton is specifically the version of Wine that was patched (by Valve) to work together with steamclient.so from Linux Steam; if regular Wine worked, we wouldn't bother with any additional ports.

The latest update to wine-proton is stuck at the PulseAudio dependency debate: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288475.
 
shkhln said:
Here's how Nvidia overlay actually looks like:
Click to expand...

On my machine/card -- the NVIDIA overlay does not look like that. There is a large real time performance graph at the (bottom left) of the screen constantly providing GPU statistics as a long "sign wave"-- plus FPS output (multiple lines output plus graphical output). And (A LOT) more information than the 2x lines shown at the top of the screen (left). Why is there an NVIDIA performance overlay displayed at all? This should be disabled so we can actually play the game we are running. The performance overlay is literally stepping on game output.

Thank you for taking a look at these issues.
 
shkhln said:
The latest update to wine-proton is stuck at the PulseAudio dependency debate: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288475.
Click to expand...
Assuming you are Alex S. from the Bugzilla string: thanks for your work on maintaining and updating this port. It is impressive and complex, especially the WoW64 stuff.

Do you see a path to getting it unstuck? Proton 10 unbreaks some big-ticket applications, and it would be nice to have it in tree (and it might help some folks).

Trying to wrap my head around the issue being debated:

Code: 
# /usr/local/wine-proton/bin/wine --version 
wine-10.0
# ldd /usr/local/wine-proton/lib/wine/x86_64-unix/winepulse.so | awk '/pulse/'
/usr/local/wine-proton/lib/wine/x86_64-unix/winepulse.so:
    libpulse.so.0 => /usr/local/lib/libpulse.so.0 (0x3aa9827ed000)
    libpulsecommon-17.0.so => /usr/local/lib/pulseaudio/libpulsecommon-17.0.so (0x3aa9820f3000)

As I understand it, if the port doesn't include Pulse as a runtime dependency, one could, by selecting winepulse.drv, end up dlopen()'ing a library (winepulse.so) that is in turn linked to a missing dependency (libpulse.so.0). What happens if that call to dlopen() fails? This seems to be the point on which everything hinges. If Wine handles the error gracefully, then presumably the linter warning flagged up by vvd@ can be safely ignored, because it is inconceivable that any other port could depend on winepulse.so.

Much apart from this, if you ask me, the benefits of Proton are obviated without Pulse to such an extent that it might just as well be made a hard dependency, but there are presumably those out there who may still want OSS only.
 
shkhln said:
It's not mentioned in this thread and I'm not sure why would you bring that into the LSU + wine-proton vs wine-proton standalone comparison.
Click to expand...

I'm not exactly sure who are you referring to.
I am the author of this topic, and LSU/steam is not my debate. I have issues with sound API. Speaking of which;

shkhln said:
The latest update to wine-proton is stuck at the PulseAudio dependency debate: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288475.
Click to expand...

Do you maybe have more information on this part

Making pulseaudio a lib dependency as suggested, would be a POLA violation for user of wine-proton that have pulseaudio not installed on their systems, since this would automatically make pulseaudio a dependency at the install.
And for users relying on pulseaudio due to some games needing it, having the pulseaudio off would be a POLA violation since they would suddenly not have any sound (or maybe very distorted ones) on their games.
Click to expand...

This is exactly what I see when building wine, not wine-proton. Backend choice impacts client APIs which for me is totally braindead if it is so in the upstream. E.g. using OSS does not give you Wasapi and DirectX drivers.

Meanwhile I switched to wine-proton-e.10.0.20250919,1 and it seems to work cool altogether :) Performance in game is on wine10 level and sound is correct via OSS backend (all APIs).
 
CShell said:
There is a large real time performance graph at the (bottom left) of the screen constantly providing GPU statistics as a long "sign wave"-- plus FPS output (multiple lines output plus graphical output). And (A LOT) more information than the 2x lines shown at the top of the screen (left).
Click to expand...
You mean this https://github.com/shkhln/linuxulat...58d84173ea/tools/LSU_FreeBSD_Wine/run.rb#L257? I like it way too much to disable, mostly because I can see what hardware people are using when they post screenshots elsewhere. If there are enough complaints, then perhaps.

vidmak said:
As I understand it, if the port doesn't include Pulse as a runtime dependency, one could, by selecting winepulse.drv, end up dlopen()'ing a library (winepulse.so) that is in turn linked to a missing dependency (libpulse.so.0). What happens if that call to dlopen() fails?
Click to expand...
You'll get a warning and no sound.

vidmak said:
This seems to be the point on which everything hinges. If Wine handles the error gracefully, then presumably the linter warning flagged up by vvd@ can be safely ignored, because it is inconceivable that any other port could depend on winepulse.so.
Click to expand...
It's not. The point of contention is specifically this linter warning. I obviously consider this ridiculous, thus I won't do anything about it.

Zare said:
This is exactly what I see when building wine, not wine-proton. Backend choice impacts client APIs which for me is totally braindead if it is so in the upstream. E.g. using OSS does not give you Wasapi and DirectX drivers.
Click to expand...
I haven't noticed this. What exactly do you observe?
 
shkhln said:
What exactly do you observe?
Click to expand...

I'm unable to get overall sound working with wine packages regardless of the audio backend, but switching the backend impacts the underlying Windows audio subsystems. When using OSS, I have the primitive mapper device, but no Wasapi or DirectSound. When using ALSA, I don't have the mapper, but have the newer APIs - the entire 'Audio' of winecfg is blank and test sound button does not work. However some DirectX games play sounds normally.

Wine-proton uses wineoss.drv, winecfg looks correct with all my devices, test button works and it correctly maps the devices to Wasapi and DirectSound too. I'm not sure why regular wine package doesn't perform the same thing in my case.

What is more odd, is that modern Windows do not use mapper drivers any more, the mapper is just bridged to Wasapi. E.g. my real soundcard on my real Win2022 doesn't have MME driver but Windows 95 apps will still work on it and see my card.

Also the writing on the link you provided, "games relying on pulseaudio", why should a Windows game rely on a particular Wine audio backend?

Testing is rather easy. I mean I'm 99% confident that winecfg Audio shows the MME mapper section but to be sure one can use an old Winamp, and new AIMP. Former does MME only, latter does Wasapi/DirectX only. Expectancty as user is to have proper driver outlined in winecfg, have system devices listed there, and be able to play a file through both programs. I am simply unable to achieve this with wine packages, whereas wine-proton just does everything as expected.
 
You must log in or register to reply here.
Back
Top