Alsa source and Wine

[AdamK]

Wine is unable to use PulseAudio Alsa plugin.

This is my /etc/asound.conf:

pcm.pulse {

type pulse

} ctl.pulse {

type pulse

} pcm.!default {

type pulse

} ctl.!default {

type pulse

}

This is registry entries for Alsa configuration in Wine:

REGEDIT4

[HKEY_CURRENT_USER\Software\Wine\Alsa Driver]

"AutoScanCards?"="N"

"AutoScanDevices?"="N"

"DeviceCount?"="1"

"DeviceCTL1"="pulse"

"DevicePCM1"="pulse"

"UseDirectHW"="N"

And I get this error in wine log:

err:alsa:ALSA_CheckSetVolume Could not find 'PCM Playback Volume' element

I tracked it in wine source code to file dlls/winealsa.drv/alsa.c

With following comment:

/* Setup and find an element id that exactly matches the characteristic we want

** FIXME: It is probably short sighted to hard code and fixate on PCM

Playback Volume */

Probably PulseAudio Alsa emulation does not provide enough (or provides wrong) control.

Link to bug entry in Wine Bugzilla: http://bugs.winehq.org/show_bug.cgi?id=10910

[AstralStorm]

If it's still not fixed, you can always work it around using ALSA softvol plugin.

[lennart]

Sorry, this is a bug in wine, not in PCM. It should not assume that there's always a PCM volume control available. At least it should fallback to use the Master volume control.

It makes no sense for our compat layer to provide both Master and PCM because they would be essentially the same and thus very confusing.

Sorry, I cannot fix this in PA, please file a bug for WINE.

[coling]

Just for the benefit of the original poster, I think one of the Mandriva devs (pkarlsen) is working on this to some degree (I've started the ball rolling). We'll hopefully have a wine patch in the not too distant future.

[proyvind]

Isn't the purpose of a compatibility layer to be compatible?

PCM and Master channels are two different channels, both are present on most (every?) systems. IMO It should be perfectly sane to change the volume for PCM only and not all output channels (Master), ie. you might want to turn the volume of PCM down while wanting the volume for playing CD stay the same.

From my understanding what you're saying it's a bug to control more than one channel, which I find it perfectly sane for alsa to do.

I don't see why it would be more confusing for PA to provide both PCM and Master, not providing it seems more confusing while also breaking compatibility. If one really doesn't want to provide both, one should at least provide compatibility so that PCM == Master..

[coling]

Replying to proyvind:

Isn't the purpose of a compatibility layer to be compatible? PCM and Master channels are two different channels, both are present on most (every?) systems.

I'm pretty sure i've had hardware where there is only Master and no PCM. Not my current hardware but perhaps it was my last PC.....

From my understanding what you're saying it's a bug to control more than one channel, which I find it perfectly sane for alsa to do.

Nope, he's saying that their code is a broken implementation in that it make assumptions that are not always true.

I don't see why it would be more confusing for PA to provide both PCM and Master, not providing it seems more confusing while also breaking compatibility. If one really doesn't want to provide both, one should at least provide compatibility so that PCM == Master..

To provide both in Pulseaudio is an ugly work around that hides the real bug (in the client app) and means it's more likely that buggy code stays lying around without ever getting fixed.

[lennart]

Replying to proyvind:

Isn't the purpose of a compatibility layer to be compatible? PCM and Master channels are two different channels, both are present on most (every?) systems. IMO It should be perfectly sane to change the volume for PCM only and not all output channels (Master), ie. you might want to turn the volume of PCM down while wanting the volume for playing CD stay the same.

Lemme check. Ah, right. From the 5 sound cards I have in my machine only 1 has both PCM and Master. Point proved.

All newer (24bit) HDA lack volume control, most USB audio devices only have a single volume control -- if it all.

The specific in code in WINE makes totally invalid assumptions about sound hardware. And judging by the comment the author was actually aware of this! Don't ask me to work around such a blatant violation of the ALSA API.

Also, if you think that someone should add compat kludges for borken apps like WINE, then it is alsa not just PA.

I don't see why it would be more confusing for PA to provide both PCM and Master, not providing it seems more confusing while also breaking compatibility. If one really doesn't want to provide both, one should at least provide compatibility so that PCM == Master..

Because if you open a ALSA mixer app then it will always show two sliders which interact in a very strange way. This will trigger even more bugs in other people's software.

[proyvind]

"PCM Playback Volume" seems actually to be the default set by alsa if not set in the code.

I've attached a patch in the wine bugzilla fixing this as well as wine trying to use incorrect device 'default:X' in stead of 'default'. Sound now works with the exception for directsound which seems to be broken by some other problem. I'm uncertain whether the problem lies in wine or pulseaudio..

[wereHamster]

There is a small 'bug' in the alsa pulse plugin which breaks the wine tests. The problem is that when writing small amounts of data (<4000 bytes), then the latency is not properly updated. The wine test waits until all data is processed using snd_pcm_delay(), which is implemented using pa_stream_get_latency(). But the latency/delay stays always the same so wine loops endlessly. I changed the alsa plugin to not use PA_STREAM_AUTO_TIMING_UPDATE | PA_STREAM_INTERPOLATE_TIMING and voila, wine tests don't loop endlessly anymore.

[wereHamster]

The snd_pcm_delay() emulation inside the alsa pulse plugin is one of the main problems. PA uses used, ALSA uses frames to measure time, buffer positions etc. I suspect that there are rounding problems as I've seen wine wait until some value reaches 4000 while the value returned from ALSA was 3990. Alsa, pa_stream_get_latency() sometimes returns > buffersize, which is really bad for wine, it causes wine to think it has enough time and sleep for too long. I changed the code in alsa-pulse to use write_index-read_index and now wine works fine. Maybe there's a bug in the latency interpolation in PA or something. Or maybe it's just a rounding issue I described earlier (usec->bytes->frames vs. bytes->frames I use now). Anyway, I'd love to hear from the PA devs on this issue.

[wereHamster]

To prevent confusion, small typo in my last comment: PA uses usec, ALSA uses frames..

[susancragin]

The new default pulseaudio in Hardy does not work with many non-Gnome programs. I am worried that everyone (Ubuntu, Alsa, Pulse, Wine) is not on the same page. Will try cross-posting bug information.

Ubuntu: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453 https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/109439

Pulse: http://www.pulseaudio.org/ticket/198

Alsa: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601

Wine: http://bugs.winehq.org/show_bug.cgi?id=10495 http://bugs.winehq.org/show_bug.cgi?id=10910

Tom's Wine Patch: http://www.winehq.org/pipermail/wine-patches/2008-February/050561.html

Skype: http://forum.skype.com/index.php?showtopic=112021

[susancragin]

But wait! There are more! Alsa people tell me they have one for Ekiga and Gnome, too! https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3825 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3825

[mnk]

I don't know if anybody works still on this bug, but yesterday I noticed something got broken with the sound in wine in the last 3 months (I didn't noticed before, cause midi was working). I've found http://bugs.winehq.org/show_bug.cgi?id=13090 It's closed now, but with an invalid fix. After some compiling, I came to conclusion, that for some reason sound in Wine doesn't work when snd_pcm_open is called with pcmname = default, but seems to work correctly when snd_pcm_open is called with pcmname = plughw0,0

Any comments why ?

[mnk]

Mirroring comment from that bug: As default is hw:0, it simply means, that for some reason direct hardware access isn't possible while using alsa pulse plugin, only software. Did I get it right, or did I misunderstood something ?

[pirast]

Hi, guess what, I am also encountering the problem (for a long time now). Sadly, it is still there, and the Wine guys do not seem to fix it, even not for their 1.0 release.

Maybe you could have another look at what is wrong with DirectSound? and PulseAudio or sit together with them? This would be great. Thanks..

[oiaohm]

I am going to be blunt. With wine we have got pulse working but slowly for everyone on alsa. Its the how bit.

pasuspender does not work on all cards either for wine. Reason if card has onboard hardware mixing it works. If card needs software mixer dmix to replace that function it don't work. pasuspender not smart enough to activate dmix in that case so its now a nice intermittent mess. Working for some people and not for others.

I think part of this mess is that you have miss read alsa. Sound card drivers don't need to provide what dmix can do in software. But since its software or hardware applications are build that dmix or hardware exists or if it does not exist user can enable it. Us giving support for people using wine are currently forced to give recommendation to remove pulseaudio from system. Reason we cannot get required performance threw pulse audio due to having to stack dmix and pulse to get things to work. Then it all works with major performance issues. Maybe a few minor registry key edits but works.

Simple fix pulse audio stop blaming wine. You have miss read the documentation. You have not provided part of the needed feature set. So now you have a stack of broken applications. If stacking of dmix over pulse audio worked without speed issue this would not be a problem.

[coling]

Replying to oiaohm:

I am going to be blunt. With wine we have got pulse working but slowly for everyone on alsa. Its the how bit.

Being blunt is fine. Making accusations with no evidence is not.

Please back up your statements with examples. Making such statements on their own will not help people fix things!!

pasuspender does not work on all cards either for wine. Reason if card has onboard hardware mixing it works. If card needs software mixer dmix to replace that function it don't work. pasuspender not smart enough to activate dmix in that case so its now a nice intermittent mess. Working for some people and not for others.

pasuspender is doing it's job fine. You presume that pasuspender should reconfigure alsa. It does not do this. All it does is tell the pulseaudio deamon to release the card. It does not reconfigure alsa. If you alsa configuration is such that the "default" device is routed to the pulse plugin, pasuspender will not touch this (it cannot do this as quite often the default config is specified by root, not the current user).

I think part of this mess is that you have miss read alsa. Sound card drivers don't need to provide what dmix can do in software. But since its software or hardware applications are build that dmix or hardware exists or if it does not exist user can enable it.

Sorry but I don't really follow the above statement, can you clarify? Where has the alsa spec been mis-read? If you can point out where this is happening, perhaps we can fix it but a sweeping statement is pretty much just flame bait that is not particularly constructive :(

Pulseaudio is effectively a replacement of dmix. It makes absolutely no sense to use pulseaudio on top of dmix. People often have some kind of strange attachement to dmix for no sensible reason other than "it's in alsa". So what? A modern linux OS is modular and the sound subsystem is no different. dmix is just a sound server itself, and pulseaudio is a better sound server. End rant :)

Us giving support for people using wine are currently forced to give recommendation to remove pulseaudio from system. Reason we cannot get required performance threw pulse audio due to having to stack dmix and pulse to get things to work. Then it all works with major performance issues. Maybe a few minor registry key edits but works.

Disabling PA seems to be the only way just now until the ALSA bugs are fixed (please follow up the alsa bugs on the alsa devel mailing list as this seems to be the best way to get the alsa people to commit the fixes).

Simple fix pulse audio stop blaming wine. You have miss read the documentation. You have not provided part of the needed feature set. So now you have a stack of broken applications. If stacking of dmix over pulse audio worked without speed issue this would not be a problem.

Please stop making such statements without providing evidence of where the mistakes or bugs are. As I said above, without backing up your words you are just dishing out flame bait which I'm trying hard not to rise to.

There are open bugs in the Alsa BTS that the alsa folks need to address. Werehamster has provided several patches which seem to help.

The primary problem last time I looked was that Wine has misread the alsa specs in there use of the snd_pcm_delay() function. In fairness the docs are a little unclear and expose the implementation in the description. Wine assumes that this should return 0 when all the samples are played but this is not something the docs specify. Wine needs to find an alternative way to do this. I'm not sure how up-to-date my comments are here and Wine may have already fixed this problem in recent months. Certainly, the ALSA "bug" https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3943 should probably be closed as not-a-bug/invalid. See the link to the mailing list discussion on in the bug report for background and the discussions we've had about this.

As far as I'm aware the remaining bugs are:

• https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3942
• https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3944

If the patches provided are not yet committed then someone needs to poke the alsa developers on the alsa devel mailing list.

Please keep any further discussions on this topic on to the mailing list. I wont reply again on this bug in such away as Trac should not really be used like this. Please also do not post non-constructive comments - accusations are fine, provided you back them up!!!

[oiaohm]

Time to go kill Distros that put in pulseaudio and remove dmix off default settings? This kinda of default is leading to pasuspender creating application failing mess. Its a issue if you don't want to endup with pulseaudio and dmix stacked how to do the system defaults. Reason why I say alter it prevents users going why does this not work. If system default is missing dmix or hardware equal warn user at least. Or be nicer and provide a option to enable it for them so there programs work correctly even when pasuspender has been used. Call it a distro mess screwing with you and me. I really just want to be able to give users do this instruction and everything will work perfectly or at least it tells the user they have a problem straight up.

Turns out for some reason dmix is hiding the issue. Yes been taking to one of the wine sound guys found 2 setting lines one in alsa driver one in dsound that appears to make problems go away. Some point that will appear mainline wine.

Please accept my sorry bad day on support channel. I was kinda out to kill someone. Not allowed to kill newbies. The pasuspender one is a pain.

[pirast]

Hello, the patches here: http://bugs.winehq.org/show_bug.cgi?id=10910 fix Wine's alsa backend to work with PulseAudio completly (afaik). Many of them have been commited, the last two ones are minor changes and fix up DirectSound?, so that this ticket can be closed probably (YAY!; but it's better if a dev does it). Thanks to all people for getting things to work together, now PA works fine with everything I use on my desktop :)