Problem with 32 bit Wine DirectX audio, ALSA related?

Zare

Zare

I installed wine fresh, using the current port on 14.3 RELEASE-p2. I built it with selected mono, gecko and OSS sound.

Code: 
wine-10.0_2,1                  Microsoft Windows compatibility environment
wine-gecko-2.47.4              Gecko Layout Engine for Wine (HTML support)
wine-mono-9.4.0                Mono .NET implementation for Wine
winetricks-20250212            Easy way to work around problems in Wine

Then as user, I ran /usr/local/share/wine/pkg32.sh install wine mesa-dri

At this point I executed a simple but modern Windows game (Broforce), and it worked normally, sound OK.
Winecfg shows wineoss.drv being used and my interfaces are listed correctly.

Then I tried some other games and they ran without sound. I used winetricks to install dxdiag and saw there are no DirectSound devices. I picked out this part from dxdiags console output

Code: 
00ec:err:alsa:get_device_name_from_guid No devices found in registry?
00ec:err:alsa:get_device_name_from_guid No devices found in registry?
00ec:err:alsa:get_device_name_from_guid No devices found in registry?
00ec:err:alsa:get_device_name_from_guid No devices found in registry?
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for Loopback
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for Loopback
ALSA lib seq_hw.c:531:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
00ec:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound
output probably won't work.

If I don't build stuff from ports but use packages :

Code: 
wine-10.0_1,1                  Microsoft Windows compatibility environment
wine-gecko-2.47.4              Gecko Layout Engine for Wine (HTML support)
wine-mono-9.4.0                Mono .NET implementation for Wine
winetricks-20250212            Easy way to work around problems in Wine

Wine then uses winealsa.drv and there are no devices shown in winecfg, and of course nothing in DirectSound too.
However this time the dxdiag stderr looks a bit different

Code: 
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for Loopback
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for Loopback
ALSA lib seq_hw.c:531:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory
00ec:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound
output probably won't work.

I think in this case there is ALSA device list present, but empty one.

So...what to do here? Why is our wine built against ALSA by default anyway? Is there some bridge like pulseaudio exposing ALSA that I'm unaware of (I have pulseaudio_enable="NO" in rc but it's still running by virtue of Plasma).
 
This is unclear to me, too.

It might be time to email the maintainer and ask them to add a quick description of how sound is supposed to work for FreeBSD Wine to files/pkg-message.
 
I got this exact same wine error as well recently... and I never did find a correction for it.

My work around was to uninstall wine-10.0_1,1 and then install wine-proton-9.0.3 instead of the generic wine package. I understand that might not be an ideal fix, but the Windows program I was trying to get running worked after that. I also changed my $PATH to find 'wine' after that with:

Code: 
export PATH=$PATH:/usr/local/wine-proton/bin

I currently have the following installed:

Code: 
wine-gecko-2.47.4              Gecko Layout Engine for Wine (HTML support)
wine-mono-9.4.0                Mono .NET implementation for Wine
wine-proton-9.0.3              Wine with a bit of extra spice

I (would like) to get Steam working too -- and Steam itself works fine -- but the games I want to play aren't quite there yet. Still trying and I "think it's me" and not something else at the moment.
 
The usage of ALSA does seem to be a package build conf issue, and can't be avoided by ports on user side, due to pkg32.sh bringing in ALSA built wine again.

(pure ALSA bridge would need to have a kernel counterpart providing devfs nodes. I never saw that on FreeBSD)

I will try wine-proton and to contact the maintainer meanwhile.
 
I used wine-devel but don't recall any problem with audio and default OSS on FreeBSD (mostly DirectSound; OpenAL on UT99, possibly either SDL or XAudio on Dota 2)
 
Zare said:
CShell wine-proton sound works for game I wish to play. Many thanks :)
Click to expand...

Ah excellent - I am glad that worked. There are still some odd things around Windows .msi files that I am still working out and a few other things. But running games on FreeBSD is (a lot) closer than it once was ! It's getting there.
 
The performance of wine-10 the current package is really great at games. With DirectX to Vulkan implementation provided by winetricks stuff looks great.

I will contact the person supporting the packaging because it seems both wine and wine-devel target ALSA per default.

With wine-proton there are limited options in winetricks about DirectX and performance is lower at least for couple of games I tried, but it still works.
 
There have been issues regarding OSS and Wine mainly with modern DirectX games using XAudio. ALSA have been then enabled by default.

Your issue is simply that ALSA doesn't have support for midi device in our case.

Because its not an daily encounter for everyone, just compile Wine with the OSS option instead and thats it.

There have been some progress to solve these issues but didn't have time for proper re-testing it yet.

PR 268164
 
Alexander88207 said:
Because its not an daily encounter for everyone, just compile Wine with the OSS option instead and thats it.
Click to expand...

Initially I have done exactly that and expected everything to work (the very beginning of the post). But it doesn't.

Reading the PR link you provided I guess per default wine package should produce sound via alsa-lib. I should see in winecfg winealsa.drv being used, and sound test button should work. Then I should run some application and hopefully hear its sounds.

This is not what I experience. I'm going to clean up everything now, install regular wine package, new 64-bit prefix and try a 64-bit application like music player that has many supported Windows-based audio APIs.
 
How is ALSA supposed to work, anyway? Is audio/alsa-lib a shared library that oresents an alsa API to the application and internally translates to OSS? The one-line description is a little terse.

What about jackd support? That should work on FreeBSD.
 
I think it should work that way and I think the problem could be there, and not in wine port.
I have tried just plain wine package install and AIMP - its ALSA bound, there are no sound devices present, no sound devs in AIMP and ofc no sound...

The problem could be in alsa-lib not presenting them. I'll try to find a music player that can use alsa to see whether it works on my system.
 
cracauer@ said:
What about jackd support? That should work on FreeBSD.
Click to expand...

Jack option is something I'd love to see on the port. Alexander are there any reasons to not have it?

1758805839810.png


This is synth primarily developed on Linux thus it supports ALSA and jack out of the box - no configurations for this package/port.

When running against alsa-lib it presents native OSS as a ALSA device.

On our side it ends ofc just as a OSS vchan

Code: 
        dsp0.play.0[dsp0.virtual_play.1]: spd 48000, fmt 0x08801000/0x00200010, flags 0x1
000110c, 0x00000063, pid 4549 (BespokeSynth)

I think the issue might be in 32-bit alsa-lib accessing OSS.
 
Ok alsa-lib without alsa kernel module won't present any "soundcards" but it can implement virtual devices eg "PCM" in their nomenclature. alsa-lib on FreeBSD is built with oss PCM module. It is what that synth UI shows too.

To play music on FreeBSD via aplay you would need to tell it to use the oss module, because default behaviour is to use the default soundcard.

Run

aplay file.wav

And it triggers these alsa-lib errors

Code: 
ALSA lib confmisc.c:165:(snd_config_get_card) Cannot get card index for Loopback
aplay: main:850: audio open error: Operation not supported by device

Exactly the same symptom as wine. Executing

aplay -D oss test.wav

Should play the file through the default OSS soundcard (in very low default settings)

I wonder how it is supposed to work in Wine's case Alexander88207 , judging by what I see winealsa wants physical devices and not virtual PCMs?
 
That isn't the case for me :

Code: 
wine-devel-10.10,1             Microsoft Windows compatibility environment
wine-gecko-devel-2.47.4        Gecko Layout Engine for Wine development branch (HTML support)
wine-mono-devel-10.1.0         Mono .NET implementation for Wine development branch
winetricks-20250212            Easy way to work around problems in Wine

1758838274331.png


Ofc I always do everything on a clean prefix.
 
The gist of my problem is that wine does not present an MME audio mapper, but wine-proton does.

I will disregard wine-devel for now because I can't get it to run all the test applications, and unfortunately the same for my EL9 work laptop - seems wine there has heavy problems running anything 32 bit.

MME (windows audio mapper) is the oldest still around Windows audio API, it was always supplanted by DirectX audio (DirectSound), but it had also been superseeded by WASAPI. The way backward compatibility is handled in Windows comes down to audio mapper to WASAPI internal bridging, as soundcards do not provide these drivers anymore. This makes old programs just work on Windows.

Therefore the linking of old(er) sound application on OSS host but ALSA Wine should be :

app->MME->WASAPI->winealsa.drv->alsa-lib->OSS

And it works correctly in wine-proton. I can test with two tools - AIMP, that doesn't know about the audio mapper, only modern APIs, and Sound Forge 6.0 which is opposite. In wine-proton AIMP has my OSS devices presented as WASAPI/DirectSound, Sound Forge has them as Windows sound mapper entries.

Now with wine, two chains are available depending on ALSA/OSS selection

app->MME->wineoss.drv->OSS
app->WASAPI->winealsa.drv->alsa-lib->OSS

Additional problem is that google is so littered with these terms, MME, WASAPI, because there are millions of "aspiring musicians" around the world that still don't know the basic terminology in their software and they ask "I have half a second latency on my instrument" type of questions.

I'm also fairly confident this is not a port/package issue but upstream. It just seems like there is issue with internal sound mapper affairs.

Does anyone have run a Linux system where this can be tested?
 
Sound wasn't working on Call of Duty World at War on linux-steam-utils. But I then installed Mizuma and I guess it installed something else that made the sound work?! I'm confused now. I also ran
Code: 
/usr/local/steam-utils/bin/lsu-wine-env winecfg

and set the audio to my hdmi audio out 0 that I am using. So, not sure what happened. But it's now working.
 
Zare said:
That isn't the case for me :

Code: 
wine-devel-10.10,1             Microsoft Windows compatibility environment
wine-gecko-devel-2.47.4        Gecko Layout Engine for Wine development branch (HTML support)
wine-mono-devel-10.1.0         Mono .NET implementation for Wine development branch
winetricks-20250212            Easy way to work around problems in Wine

View attachment 23722

Ofc I always do everything on a clean prefix.
Click to expand...
This is on latest branch, not quarterly
 
You must log in or register to reply here.
Back
Top