This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too.
http://www.pulseaudio.org/wiki/PerfectSetup
It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control.
Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use.
Sorry for expanding the topic so much.
On 4/2/08, Susan Cragin susancragin@earthlink.net wrote:
This site purports to give instructions on how to run certain applications, including Skype (which is 32-bit). I think wine should have instructions here too.
http://www.pulseaudio.org/wiki/PerfectSetup
It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins ryuzaki90@gmail.com wrote:
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control.
Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use.
Sorry for expanding the topic so much.
On 4/2/08, Susan Cragin susancragin@earthlink.net wrote:
This site purports to give instructions on how to run certain
applications, including Skype (which is 32-bit). I think wine should have instructions here too.
http://www.pulseaudio.org/wiki/PerfectSetup
It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0.
On Wed, Apr 2, 2008 at 1:05 PM, Austin English austinenglish@gmail.com wrote:
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins ryuzaki90@gmail.com wrote:
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control.
Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use.
Sorry for expanding the topic so much.
On 4/2/08, Susan Cragin susancragin@earthlink.net wrote:
This site purports to give instructions on how to run certain
applications, including Skype (which is 32-bit). I think wine should have instructions here too.
http://www.pulseaudio.org/wiki/PerfectSetup
It doesn't look like pulseaudio is going away from Ubuntu anytime soon. https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0.
And I believe Julliard rejected the idea of adding a pulseaudio driver.
James Hawkins wrote:
On Wed, Apr 2, 2008 at 1:05 PM, Austin English austinenglish@gmail.com wrote:
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins ryuzaki90@gmail.com wrote:
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control.
Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use.
Sorry for expanding the topic so much.
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0.
And I believe Julliard rejected the idea of adding a pulseaudio driver.
Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment.
I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant.
bye michael
On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc mstefani@redhat.com wrote:
James Hawkins wrote:
On Wed, Apr 2, 2008 at 1:05 PM, Austin English austinenglish@gmail.com wrote:
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins ryuzaki90@gmail.com wrote:
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing. In effect, wine handles it's own audio (by talking with ALSA or OSS) then passes that through to the outside sound server... which in most cases would simply be ALSA or OSS itself, but in this case it gets passed to ALSA/OSS and through this talks to pulse. I call that pretty messy when we could just directly talk to pulse audio (easily, too) and have by applications control. Pulse is going to be in pretty much every distro soon. For a 1.0 release, no one wants to go out of their way to accomodate the shortcomings of our audio control.
Even directly sending the blobof output to pulse directly at first would simplify things. I know this means yet asnother audio output method to maintain, and for various reasons many are against it. But this is similar to us needing to improve ALSA support rather recently. Pulseaudio does directly support ALSA, but it's a bit demanding on how it need to work to be perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need support for. Pulse is a drop in replacement for things like Network Sound, and way easier to configure and use.
Sorry for expanding the topic so much.
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0.
And I believe Julliard rejected the idea of adding a pulseaudio driver.
Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment.
I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant.
"No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers." -Julliard
http://winehq.org/pipermail/wine-devel/2008-March/063755.html
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would require quite a bit of time/work and is likely outside of the scope of 1.0.
And I believe Julliard rejected the idea of adding a pulseaudio driver.
Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment.
I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant.
"No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers." -Julliard
http://winehq.org/pipermail/wine-devel/2008-March/063755.html
... I also guess no one is stopping people from writing a pulseaudio driver.
Its just that it needs to make certain criteria before inclusion, after we got burned with esound, arts, nas, etc etc etc etc.
Ciao, Marcus
Marcus Meissner wrote:
... I also guess no one is stopping people from writing a pulseaudio driver.
Its just that it needs to make certain criteria before inclusion, after we got burned with esound, arts, nas, etc etc etc etc.
Ciao, Marcus
Correct. There is a pulse driver for Wine being worked on, but outside the Wine project (ie "not us").
James Hawkins wrote:
On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc mstefani@redhat.com wrote:
James Hawkins wrote:
And I believe Julliard rejected the idea of adding a pulseaudio driver.
Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment.
I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant.
"No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers." -Julliard
http://winehq.org/pipermail/wine-devel/2008-March/063755.html
Right, forgot about that one. But I am still sure he would accept a "perfect" full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this "yet another audio system 2.0" is and why Wine _needs_ to implement that one.
So if one of the proponents of pulseaudio for Wine would just go ahead and start writing one, for example on git.or.cz Alexandre wouldn't mind at all. Convincing the distributions to include the pulseaudio driver should be an easy selling especially for Fedora and Ubuntu who seem to move to "pulseaudio will fix everything".
bye michael "who fixed the sound on his desktop by removing pulseaudio"
Michael Stefaniuc mstefani@redhat.com writes:
Right, forgot about that one. But I am still sure he would accept a "perfect" full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this "yet another audio system 2.0" is and why Wine _needs_ to implement that one.
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Once this is done and we have demonstrated that we can actually make one driver work 100% correctly, then we can consider adding another one.
Hi Alexandre,
2008/4/2, Alexandre Julliard julliard@winehq.org:
Michael Stefaniuc mstefani@redhat.com writes:
Right, forgot about that one. But I am still sure he would accept a "perfect" full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this "yet another audio system 2.0" is and why Wine _needs_ to implement that one.
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Once this is done and we have demonstrated that we can actually make one driver work 100% correctly, then we can consider adding another one.
Apart from the horrible waveout playback code that was directly copied from wineoss, and to a lighter degree the wavein code is there anything seriously broken in winealsa? Nothing comes to mind at the moment.
Cheers, Maarten.
"Maarten Lankhorst" m.b.lankhorst@gmail.com writes:
Apart from the horrible waveout playback code that was directly copied from wineoss, and to a lighter degree the wavein code is there anything seriously broken in winealsa? Nothing comes to mind at the moment.
Well, people are saying we need a pulseaudio driver because alsa doesn't work right on top of pulseaudio; now it may well be that the fault is entirely on the pulseaudio side, but either way it needs to be investigated and fixed.
One other (minor) problem I know about is that building the alsa driver spews out several warnings about using deprecated functions.
Alexandre Julliard wrote:
Michael Stefaniuc mstefani@redhat.com writes:
Right, forgot about that one. But I am still sure he would accept a "perfect" full featured and beautiful written pulseaudio driver. What he doesn't wants at all is wasting precious Wine developer time on creating one in his Wine git repository. And having it rot there because in 1-2 years all of todays pulseaudio proponents will complain how broken pulseaudio is and how much better this "yet another audio system 2.0" is and why Wine _needs_ to implement that one.
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do.
Once this is done and we have demonstrated that we can actually make one driver work 100% correctly, then we can consider adding another one.
It is your tree and given the history the only sane approach for your ("The Wine") git tree. But that's the centralized approach and I would love if people would start moving away from that.
Compare "Hey guys, pulseaudio is the uber cool must have audio system of the future. I went ahead and added a pulseaudio driver to Wine. Here is the link to my git tree." to "Bitch bitch moan everything else sucks but pulseaudio bitch bitch so you guys go ahead and implement it in Wine."
I prefer the first version but i probably listened to often to Linus about the advantages of git and the distributed development model.
bye michael
On Wednesday 02 April 2008 03:26:40 pm Michael Stefaniuc wrote:
Alexandre Julliard wrote:
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do.
But that still doesn't make it The Right Thing to do. Who's to say PulseAudio will really stick around and continue to be useful? Phonon has a good chance of that, too (as it's backed by Trolltech/Qt, and is useable on several OSs). And I'm sure people said some of the same thing about aRts. But we know how that ended up.
And it's not even like PA's main feature (software mixing) isn't available through ALSA (dmix). Sure it has some other features, but they're hardly something that Wine needs to make such a shift for (most apps have their own volume control, and people that need device hot-plugging can still get it through the ALSA-PulseAudio plugin; or even the OSS-PulseAudio plugin).
I'm sure I'm not alone in feeling like we're getting jerked around with audio APIs in Linux (use OSS! no, use ESD! no, use ALSA! no, use PulseAudio!). IMO, we have to set down and just pick something.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A lot of the posts I see about PulseAudio seem to complain about the Linux audio situation in general. PulseAudio just gets dragged along in all the negativity.
Chris Robinson wrote:
On Wednesday 02 April 2008 03:26:40 pm Michael Stefaniuc wrote:
Alexandre Julliard wrote:
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do.
But that still doesn't make it The Right Thing to do. Who's to say PulseAudio will really stick around and continue to be useful? Phonon has a good chance of that, too (as it's backed by Trolltech/Qt, and is useable on several OSs). And I'm sure people said some of the same thing about aRts. But we know how that ended up.
Phonon is high level multimedia framework. PulseAudio is a sound server. Those are two very different areas.
aRts and ESounD were both abandoned because of inactivity, I believe. Your doubts about the same happening to PulseAudio in light of that are understandable.
But PulseAudio is the most actively maintained and most desktop integrated audio solution we have now, and pretty much has been since it's inception. This looks like one of the widest and most enthusiastic adoptions of an audio standard I've ever seen on Linux, so I think the risk is small.
And it's not even like PA's main feature (software mixing) isn't available through ALSA (dmix). Sure it has some other features, but they're hardly something that Wine needs to make such a shift for (most apps have their own volume control, and people that need device hot-plugging can still get it through the ALSA-PulseAudio plugin; or even the OSS-PulseAudio plugin).
DMix is also a sound server. PulseAudio is a replacement in that sense. Some will argue it is even a better replacement. ;)
Wine already goes to great lengths to integrate with the existing desktop environments and distributions. (All the tiny things work: I can double click on .exes, applications appear in desktop menu, I can copy and paste naturally, even drag and drop.) Why not go the extra length and have full integration when it comes to audio as well? Many large distributions have already accepted PulseAudio as the standard.
Device hot-plugging should be nothing special, especially with Bluetooth headsets and similar. I admit that I too do not know the exact advantages in this area when talking directly to PulseAudio instead of through the ALSA plug-in, but right now Wine does not even work with the ALSA plug-in for me.
I'm sure I'm not alone in feeling like we're getting jerked around with audio APIs in Linux (use OSS! no, use ESD! no, use ALSA! no, use PulseAudio!). IMO, we have to set down and just pick something.
You're damn right! So let's pick PulseAudio! :)
Regards, - -- Stéphan
Chris Robinson wrote:
On Wednesday 02 April 2008 03:26:40 pm Michael Stefaniuc wrote:
Alexandre Julliard wrote:
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do.
But that still doesn't make it The Right Thing to do. Who's to say PulseAudio will really stick around and continue to be useful? Phonon has a good chance of that, too (as it's backed by Trolltech/Qt, and is useable on several OSs). And I'm sure people said some of the same thing about aRts. But we know how that ended up.
And it's not even like PA's main feature (software mixing) isn't available through ALSA (dmix). Sure it has some other features, but they're hardly something that Wine needs to make such a shift for (most apps have their own volume control, and people that need device hot-plugging can still get it through the ALSA-PulseAudio plugin; or even the OSS-PulseAudio plugin).
PulseAudio will take off exactly because Ubuntu is using it.
I'm sure I'm not alone in feeling like we're getting jerked around with audio APIs in Linux (use OSS! no, use ESD! no, use ALSA! no, use PulseAudio!). IMO, we have to set down and just pick something.
Right, and very understandably it looks like we've picked ALSA, while the distributions seemed to have picked PulseAudio.
Thanks, Scott Ritchie
On Thu, 03 Apr 2008 01:58:04 -0700 Scott Ritchie scott@open-vote.org wrote:
PulseAudio will take off exactly because Ubuntu is using it.
Just to remind you that Fedora has been using it before :P
Anyway, I had to deal with a lot of people when F8 hit because wine was not working with the default fedora install. Not everything was perfect in the fedora setup of pa then and it probably is not now, but for the near future that is where sound in fedora is going.
I would really prefer a native pa backend in wine, but something I do not understand is why people complain about pa <-> alsa <-> wine when pa <-> pa-esd-compat <-> wine works perfectly...
Regards, Andreas Bierfert
Andreas Bierfert wrote:
On Thu, 03 Apr 2008 01:58:04 -0700 Scott Ritchie scott@open-vote.org wrote:
PulseAudio will take off exactly because Ubuntu is using it.
Just to remind you that Fedora has been using it before :P
Anyway, I had to deal with a lot of people when F8 hit because wine was not working with the default fedora install. Not everything was perfect in the fedora setup of pa then and it probably is not now, but for the near future that is where sound in fedora is going.
Until the easy stuff that everybody implements (mixer, interface to the ton of other sound systems) is finished. Fixing the bugs and the odd cases will not be sexy. Interest in PA will fade away, the fan boys will move to the next cool thing for which they can go out preaching and trying to convince the people of The Right Way. PA will start to rot and count as broken by design. Then the next sound system will emerge "to fix" all the PA breakages. Fedora and Ubuntu will move to this next uber cool sound system. Rinse repeat.
I would love to have a sound system that sticks around for a while. But I really doubt that that will be named PulseAudio.
bye michael
On Thursday 03 April 2008 01:58:04 am Scott Ritchie wrote:
PulseAudio will take off exactly because Ubuntu is using it.
I don't see ALSA going anywhere anytime soon, seeing as it's in the Linux kernel itself.
There's also the issue of PulseAudio being designed to further abstract away the audio hardware, which is, IMO, the wrong way Wine needs to be going for its DirectSound implementation. The closer we can get to hardware capbilities and features, the better.. and AFAIK, ALSA can provide that (assuming its drivers know about it).
I'm sure I'm not alone in feeling like we're getting jerked around with audio APIs in Linux (use OSS! no, use ESD! no, use ALSA! no, use PulseAudio!). IMO, we have to set down and just pick something.
Right, and very understandably it looks like we've picked ALSA, while the distributions seemed to have picked PulseAudio.
Just as distributions picked ESD (via Gnome) and aRts (via KDE) before.
AFAICS, the big issue with the sound landscape in Linux is the lack of ability to play multiple sounds at one time, brought on by the lack of proper hardware (that doesn't provide multiple output voices) combined with an API that can't smartly do software mixing given the lack of hardware voices. ALSA can do software mixing, but it needs to be told explicitly by using dmix.
Adding Yet Another Sound API will not fix this. In fact it'll make it worse, as each API will want to take exclusive control and we're left with a handful of APIs that need to be supported, because a user will be using one and can't (easilly) use another. As well, the more you layer one new API on another, you'll add more latency and room for bugs, and just enhance the impression that Linux audio sucks. Plus, it'll punish those that *do* have good hardware by abstracting it away to the lowest common denominator.
IMO, this is why Wine needs to use something lower-level like OSS and ALSA, so it can get the capabilities of hardware and offer them through its DirectSound implementation, and expose features of the same hardware, not a generalized sound server. With Direct3D, we go through OpenGL to expose the hardware capabilities. With DirectSound, ALSA seems to be the closest we have that provides hardware capabilities.
Michael Stefaniuc mstefani@redhat.com writes:
Alexandre Julliard wrote:
What I really want is for all the people who are clamoring for yet another driver to pitch in and start fixing the alsa driver instead.
Right but you _cannot_ force people to do that. If they just go ahead and setup a separate Wine repo they can work on pulseaudio all the day and nobody can stop them. That's the OSS reality and git makes that very easy to do.
Obviously I'm not trying to prevent anybody from working on it, just trying to encourage at least a few people to follow the correct approach.
But yes, with git it's very easy to maintain a separate tree, and that was a large part of the reason for making the switch from cvs. This way I can keep being an asshole about the main tree, and people can route around me and still get work done. Everybody wins...
I would totally agree with that, James. If ALSA worked perfectly, it's really no problem getting it working "OOB" with Pulse, no specific sound system needed.
On Wed, Apr 2, 2008 at 2:59 PM, James Hawkins truiken@gmail.com wrote:
On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc mstefani@redhat.com wrote:
James Hawkins wrote:
On Wed, Apr 2, 2008 at 1:05 PM, Austin English <
austinenglish@gmail.com> wrote:
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins ryuzaki90@gmail.com
wrote:
I'm more interested in a direct pulseaudio gateway for Wine...
since by
application sound control is the biggest thing here for most
people.... wine
is treated as one big audio blob. Pulse sees it as one thing. In
effect,
wine handles it's own audio (by talking with ALSA or OSS) then
passes that
through to the outside sound server... which in most cases would
simply be
ALSA or OSS itself, but in this case it gets passed to ALSA/OSS
and through
this talks to pulse. I call that pretty messy when we could just
directly
talk to pulse audio (easily, too) and have by applications
control. Pulse is
going to be in pretty much every distro soon. For a 1.0 release,
no one
wants to go out of their way to accomodate the shortcomings of
our audio
control.
Even directly sending the blobof output to pulse directly at
first would
simplify things. I know this means yet asnother audio output
method to
maintain, and for various reasons many are against it. But this
is similar
to us needing to improve ALSA support rather recently. Pulseaudio
does
directly support ALSA, but it's a bit demanding on how it need to
work to be
perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need
support for.
Pulse is a drop in replacement for things like Network Sound, and
way easier
to configure and use.
Sorry for expanding the topic so much.
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day, you'd need to implement a full structure/drivers/etc., which would
require
quite a bit of time/work and is likely outside of the scope of 1.0.
And I believe Julliard rejected the idea of adding a pulseaudio
driver.
Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment.
I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which cleans up the wineaudio driver mess en passant.
"No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers." -Julliard
http://winehq.org/pipermail/wine-devel/2008-March/063755.html
-- James Hawkins
Sorry for the double post. But further on that point, at the sound system neutral level, naming eahc app individually as a sound item would rock. In such a way that each app perhaps talks to ALSA directly, which results in self identification, and further Pulse via ALSA recognizing things individually.
For me, the only way to get it working properly with pulse is padsp, meaning using oss and prefixing all wine commands with padsp.
On Wed, Apr 2, 2008 at 5:20 PM, Bryan Haskins ryuzaki90@gmail.com wrote:
I would totally agree with that, James. If ALSA worked perfectly, it's really no problem getting it working "OOB" with Pulse, no specific sound system needed.
On Wed, Apr 2, 2008 at 2:59 PM, James Hawkins truiken@gmail.com wrote:
On Wed, Apr 2, 2008 at 1:52 PM, Michael Stefaniuc mstefani@redhat.com wrote:
James Hawkins wrote:
On Wed, Apr 2, 2008 at 1:05 PM, Austin English <
austinenglish@gmail.com> wrote:
On Wed, Apr 2, 2008 at 10:08 AM, Bryan Haskins <
ryuzaki90@gmail.com> wrote:
I'm more interested in a direct pulseaudio gateway for Wine...
since by
application sound control is the biggest thing here for most
people.... wine
is treated as one big audio blob. Pulse sees it as one thing.
In effect,
wine handles it's own audio (by talking with ALSA or OSS) then
passes that
through to the outside sound server... which in most cases
would simply be
ALSA or OSS itself, but in this case it gets passed to ALSA/OSS
and through
this talks to pulse. I call that pretty messy when we could
just directly
talk to pulse audio (easily, too) and have by applications
control. Pulse is
going to be in pretty much every distro soon. For a 1.0
release, no one
wants to go out of their way to accomodate the shortcomings of
our audio
control.
Even directly sending the blobof output to pulse directly at
first would
simplify things. I know this means yet asnother audio output
method to
maintain, and for various reasons many are against it. But this
is similar
to us needing to improve ALSA support rather recently.
Pulseaudio does
directly support ALSA, but it's a bit demanding on how it need
to work to be
perfect.
ALSA, Pulseaudio, and OSS are probably the big three we need
support for.
Pulse is a drop in replacement for things like Network Sound,
and way easier
to configure and use.
Sorry for expanding the topic so much.
This has been brought up before, and it's quite a bit of work. You can't just simply forward everything to pulse call it a day,
you'd
need to implement a full structure/drivers/etc., which would
require
quite a bit of time/work and is likely outside of the scope of
1.0.
And I believe Julliard rejected the idea of adding a pulseaudio
driver.
Nope! He isn't against a pulseaudio driver. He is against yet another broken and half implemented driver for the desktop sound system that happens to be en vogue at the moment.
I think he would love to see a clean, full implemented pulseaudio driver; presented in a nice easy review-able patch series which
cleans
up the wineaudio driver mess en passant.
"No, the right answer is to make the Alsa driver work right. We need to stop rushing out to write a new driver every time there's a problem with an existing one, all it leads to is more broken drivers." -Julliard
http://winehq.org/pipermail/wine-devel/2008-March/063755.html
-- James Hawkins
On Wed, Apr 02, 2008 at 05:23:50PM -0400, Bryan Haskins wrote:
Sorry for the double post. But further on that point, at the sound system neutral level, naming eahc app individually as a sound item would rock. In such a way that each app perhaps talks to ALSA directly, which results in self identification, and further Pulse via ALSA recognizing things individually.
That this doesn't work with the alsa->pulse plugin is a missing feature of that plugin which could be fixed.
Jan
Am Mittwoch, 2. April 2008 17:08:06 schrieb Bryan Haskins:
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing.
Isn't that a PulseAudio limitation? I am sure that Wine opens a new Alsa connection for each Windows application that uses sound. I don't know how PA groups the input, but it can surely find different Wine inputs from Alsa.
On Thu, Apr 03, 2008 at 01:46:18AM +0200, Stefan Dösinger wrote:
Am Mittwoch, 2. April 2008 17:08:06 schrieb Bryan Haskins:
I'm more interested in a direct pulseaudio gateway for Wine... since by application sound control is the biggest thing here for most people.... wine is treated as one big audio blob. Pulse sees it as one thing.
Isn't that a PulseAudio limitation? I am sure that Wine opens a new Alsa connection for each Windows application that uses sound. I don't know how PA groups the input, but it can surely find different Wine inputs from Alsa.
Yes, more precicely it's about how the alsa->pulse plugin tries to identify different applications. It gets the real process name (the loader), not the one wine changed to. The plugin could use that, but it would also be nice if the plugin would take an optional argument to set the name explicitly like on can with the pulse api.
Jan
Am Sonntag, 6. April 2008 12:27:51 schrieb Jan Zerebecki:
Yes, more precicely it's about how the alsa->pulse plugin tries to identify different applications. It gets the real process name (the loader), not the one wine changed to. The plugin could use that, but it would also be nice if the plugin would take an optional argument to set the name explicitly like on can with the pulse api.
I don't see how the process name or a process identification is a proper primary key for sound clients. They should rather use the alsa primary buffers requested by the apps rather than the process identification. They could still use the process name as a description for the user interface, using anything not directly sound API related like PID, process name, ..., as the identifier for a sound client is broken IMHO.
On Sun, Apr 06, 2008 at 05:41:05PM +0200, Stefan Dösinger wrote:
Am Sonntag, 6. April 2008 12:27:51 schrieb Jan Zerebecki:
Yes, more precicely it's about how the alsa->pulse plugin tries to identify different applications. It gets the real process name (the loader), not the one wine changed to. The plugin could use that, but it would also be nice if the plugin would take an optional argument to set the name explicitly like on can with the pulse api.
I don't see how the process name or a process identification is a proper primary key for sound clients. They should rather use the alsa primary buffers requested by the apps rather than the process identification. They could still use the process name as a description for the user interface, using anything not directly sound API related like PID, process name, ..., as the identifier for a sound client is broken IMHO.
It results in the behaviour that the user would expect. E.g. that one game you start retains the same settings everytime it creates a primary buffer (thus that it retains the settings on the next start) and the voice chat client also always retains it's separate setting.
I'd expect most pulse using applications use one identifier for their whole application (and the same one on each start).
There is nothing like that identifier in alsa and AFAIK neither in dsound/winmm.
Jan
On Sun, Apr 6, 2008 at 12:04 PM, Jan Zerebecki jan.wine@zerebecki.de wrote:
It results in the behaviour that the user would expect. E.g. that one game you start retains the same settings everytime it creates a primary buffer (thus that it retains the settings on the next start) and the voice chat client also always retains it's separate setting.
I'd expect most pulse using applications use one identifier for their whole application (and the same one on each start).
I guess this whole system provided per app sound preference thing seems weird to me. From a design stand point, does it not make sense for apps that use sound to expect they should maintain their own sound settings and reuse them on startup.
To design this into the system seems like a workaround for apps that fail to properly maintain their own sound preferences. Wouldn't it be better to patch those apps?
Just my .005 cent, John
On Sun, Apr 06, 2008 at 12:49:53PM -0500, John Klehm wrote:
On Sun, Apr 6, 2008 at 12:04 PM, Jan Zerebecki jan.wine@zerebecki.de wrote:
It results in the behaviour that the user would expect. E.g. that one game you start retains the same settings everytime it creates a primary buffer (thus that it retains the settings on the next start) and the voice chat client also always retains it's separate setting.
I'd expect most pulse using applications use one identifier for their whole application (and the same one on each start).
I guess this whole system provided per app sound preference thing seems weird to me. From a design stand point, does it not make sense for apps that use sound to expect they should maintain their own sound settings and reuse them on startup.
That would mean duplicate code for every application... With that logic defined in a central place you can change it, like group configurations together, e.g. all your games use the same volume setting but your voice chat uses another.
To design this into the system seems like a workaround for apps that fail to properly maintain their own sound preferences. Wouldn't it be better to patch those apps?
Besides the application doesn't even know about such things as on which physical output it's sound plays...
Jan
-
Alexandre Julliard -
Andreas Bierfert -
Austin English -
Bryan Haskins -
Chris Robinson -
James Hawkins -
Jan Zerebecki -
John Klehm -
Maarten Lankhorst -
Marcus Meissner -
Michael Stefaniuc -
Scott Ritchie -
Stefan Dösinger -
Stéphan Kochen -
Susan Cragin -
TheBlunderbuss