http://bugs.winehq.org/show_bug.cgi?id=10495
Timo A. Hummel privat@timohummel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |privat@timohummel.com
S.P. crashkopf@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |crashkopf@gmail.com
eris23 jdkatz23@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jdkatz23@gmail.com
nh2@deditus.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nh2@deditus.de
Aigars Mahinovs aigarius@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aigarius@gmail.com
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |scott@open-vote.org
Sardem FF7 sardemff7.pub@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sardemff7.pub@gmail.com
--- Comment #79 from Timo A. Hummel privat@timohummel.com 2009-04-05 07:53:22 --- I have to second Volker's opinion. I'm using an Alesis IO|2 USB sound interface was designed for musicans. As such, it does not provide software mixing - just 2 outputs fixed to 24bits with 48/44.1kHz. Since ALSA does NOT support software mixing on that device for some reason, I decided to go via PulseAudio, and as of today, it is supported by most applications I use.
Since it would not be possible to use VirtualBox and WINE software (and even Firefox with Flash Plugins) at the same time since all three are open virtually all day, it absolutely makes sense to support PulseAudio.
From an end user's point of view, I do not care how it works - it just should
work. This is not the case with ALSA and OSS, maybe it would work somehow if I would switch to another soundcard, but that's not a good solution either.
I don't mind if the PulseAudio-Support has higher latency issues - a bad solution is often better than no solution at all.
--- Comment #80 from Dmitry Timoshkov dmitry@codeweavers.com 2009-04-07 00:41:08 --- You may try to make this work from the other way around: request PulseAudio to support Wine properly.
--- Comment #81 from Ben Klein shacklein@gmail.com 2009-05-11 22:11:46 --- (In reply to comment #78)
Sure any sound server also has disadvantages. But Pulse is there per default in the majority of the current LINIX desktops and this is for good reasons. Gnome, KDE, XFCE all use Pulse. Thus it is not just one more sound server but currently the sound server for LINUX.
Big falsehood here. Gnome and KDE on *some* distributions (Ubuntu, Fedora, Mandriva come to mind) use pulse by default. They are all capable of using ALSA (with dmix if required) directly. XFCE does not use pulse, nor does xubuntu from what I've heard.
(In reply to comment #78)
There really should be no need for Wine to suspend Pulse.
It should only be necessary as an extra option for special requirements but not for the average user.
Pulseaudio itself is a special requirement because its ALSA layer is broken.
(In reply to comment #78)
Thus it is no question for me that Wine needs a Puls audio driver. The question is if there is somebody willing and capable of writing one with sufficient quality and support.
This seems to be the case. Thus supporting the people who write the driver would be much more efficient then arguing against it.
That there would be much less need for a Pulse driver if Pulse should improve the ALSA layer is not an argument against a Pulse driver.
Yes it is. One of the main points about pulseaudio is that it's meant to work with <insert sound system here> without the application needing modifications. This is true for the majority of ALSA/OSS applications. Wine doesn't *need* a pulse driver if: 1) winealsa is improved to work better with current pulseaudio 2) pulseaudio is improved to have a fully working ALSA compatibility layer
Both of these options have the advantage that no new driver needs to be included and maintained.
--- Comment #82 from nh2@deditus.de 2009-05-14 07:43:28 --- I can confirm that these patches work very well for me.
Until now, this seems to be the only way to get a Wine game and a native program (e.g. a VoIP client like Mumble) working with sound simultaneously. Imagine the stupidity of the situation before: I had to chose if I either wanted to hear the people I'm playing with speaking OR ingame sound.
--- Comment #83 from Martin Jürgens martin@gamesplace.info 2009-05-14 09:15:51 --- Fedora has been shipping those patches for a long time now and I did not run into any problem except that sound just works fine - no matter if I listen to music or not. Output is set to ALSA.
--- Comment #84 from Art Taylor theycallhimart@gmail.com 2009-05-14 10:40:08 --- Well, I'm still trying to improve the patches in my spare time as a slight hobby. Time has just been kind of short because of travel and work. If somebody has a good suggestion of a simple Directsound Capture application to test with other than the wine directsound tests I would appreciate it.
--- Comment #85 from nh2@deditus.de 2009-05-15 16:14:39 --- Some were asking for binary packages. Well, here you are. I created .debs with the WinePulse patches (currently based on Wine 1.1.21) for Ubuntu Jaunty in my PPA (https://launchpad.net/~nh2/+archive/ppa). Feel free to test, link or copy them - whatever you want. (You may add them via sources.list or just download the deb package; they might work well on Debian, too.)
--- Comment #86 from Aigars Mahinovs aigarius@gmail.com 2009-05-17 08:26:21 --- As a coment to people suggesting suspending Pulse is the solution - a lot of people play WoW with a Ventrilo client and need to hear the sound from *both*, also it is common to have some relaxing music in the background from a non-Wine source. Pulse and DMix can provide that, but DMix is a pain to configure, while Pulse looks to be nicely preconfigured out-of-the-box in latest distributions, so supporting such mode of operation by default would be very useful.
--- Comment #87 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-02 05:04:27 --- *** Bug 18740 has been marked as a duplicate of this bug. ***