Re: [pulseaudio-discuss] Moving sources and sinks
Lennart Poettering wrote: I could repeat here what I wrote in response to Nick Thompson. Complaining about Free Software is nothing that makes you any friends in the community. Fine. I'm complaining. But let me tell you this. I dug through the Wine alsa driver, the alsa pulse plugin and the PA sources. I now pretty much know how these three components interact and where the problems are. I simply arrived at a point where I wasn't willing to dig any deeper. I'm simply not ready to study the codebase any more. I've seen my share. Enough to be able to create a fairly precise bug report. So I wrote to this mailinglist and asked for help. I didn't demand that you fix the bugs. I just wanted some advice. And to that I didn't get any response. I am not using wine myself, and haven't looked into fixing this. I had a quick peek into it though. They did almost everything wrong that you can do wrong if you care about supporting more than a single backend driver for your ALSA code. They made invalid assumptions about mixer tracks, they use the super-ugly and not-portable snd_async_add_pcm_handler() where it is almost guranteed that people get it wrong (because those handlers are run from signal handler context, which has some very special semantics, ranging from errno handling to a lot of other things) and a lot more. It is nearly impossible to write a backend for ALSA that works with applications like these. Basically, the task is to clean up WINE's ALSA use, before looking on the PA backend for libasound. The async handler was removed last summer, as part of the driver rewrite in a GSoC2007 project. And a lot other fixes also went into the Wine alsa driver since then. Most of the issues have already been fixed. The mixer code still may be a bit unclean, but that has nothing to do with the audio playback problems. If you know of any other outstanding issues in the Wine driver (apart from the _delay() misuse), please tell the Wine folks or me, I'll gladly forward the mail to the current maintainer. As the chances of including a native PA driver in Wine are zero, the focus is on improving the current Wine alsa driver and the alsa pulse plugin. That is what I'm trying to do. tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Colin Guthrie wrote: Tomas Carnecky wrote: Colin Guthrie wrote: I disagree that this community is unresponsive. You just have to be patient. Lennart is the main developer but he does not sit slavishly reading the mailing list and responding immediately. He'll usually have a big purge every couple weeks, but generally does respond to almost everyone who asks something, unless someone else has jumped in already. PulseAudio + Wine is still a big no-no. Like described in my earlier mail to this mailing list (sent 24.2.2008) I've come to a point where I don't know any further and asked for help. Nobody answered. Not even to the ticket in PA trac or the ticket in the alsa bugtracker. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. What are the bugs in the pulse alsa plugin you refer to? There are some feature limitations but they are typically down to what any ioplug plugin is capable of. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601 (see the comments made by wereHamster, that's me). http://pulseaudio.org/ticket/198 When I last looked at the wine alsa layer it was *really* nasty. It didn't even open the default device, it would instead try to open default:0 I think it was cleaned up a bit, but it should be very simple for someone to rewrite it or write a direct pulse driver. The main wine folks don't use PA so don't really care about this. If there is something in pulse that can be fixed, it shoudl be reported, but as tonnes of apps out there work fine with pulse+alsa, I suspect strongly (and this is based on actually having a quick peak at the code a while back) that the problems lie at the wine end. There may be applications that work fine, but you only have to find a single app that works with native alsa and fails with alsa-pulse emulation to prove that there's a bug in your code. Wine is probably one of the more complex users of the alsa API, and therefore exposing bugs in alsa-pulse that other applications don't hit. I have patched the Wine alsa driver and the alsa-pulse plugin and sound works for me, tested in World of Warcraft and foobar2000. The Wine patch maybe isn't necessary. But the patch to alsa-pulse is required, see my comments in the alsa bugtracker or the PA ticket. tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Colin Guthrie wrote: When I last looked at the wine alsa layer it was *really* nasty. It didn't even open the default device, it would instead try to open default:0 I think it was cleaned up a bit, but it should be very simple for someone to rewrite it or write a direct pulse driver. The main wine folks don't use PA so don't really care about this. The reason why a native pulse audio won't be included in Wine anytime soon is this. The alsa audio driver in Wine used to be very bad. Lots of bugs in it etc. Last summer there was a GSoC project to fix the driver. That project was successful in that the driver now works. There basically aren't any problems with the Wine alsa driver anymore. Now that Wine has a working audio driver for Linux, they want to focus on that, rather then having a second driver that works only half-way. There was someone who wrote a native pulse driver for Wine. Unfortunately I haven't see the code and I don't think the code was ever released. It probably sits in someones private repository. It would be possible to maintain the pulse driver in a separate repository. For example the ASIO driver for Wine is developed that way. And it works for the people who need that driver. However to merge the driver with 'upstream', you'd have to prove that you are willing to maintain it, that it works perfectly and has no bugs in it. Otherwise they won't even consider including it. tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Nikolai Beier wrote: 2008/5/4 Tomas Carnecky [EMAIL PROTECTED]: Colin Guthrie wrote: Tomas Carnecky wrote: Colin Guthrie wrote: I disagree that this community is unresponsive. You just have to be patient. Lennart is the main developer but he does not sit slavishly reading the mailing list and responding immediately. He'll usually have a big purge every couple weeks, but generally does respond to almost everyone who asks something, unless someone else has jumped in already. PulseAudio + Wine is still a big no-no. Like described in my earlier mail to this mailing list (sent 24.2.2008) I've come to a point where I don't know any further and asked for help. Nobody answered. Not even to the ticket in PA trac or the ticket in the alsa bugtracker. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. What are the bugs in the pulse alsa plugin you refer to? There are some feature limitations but they are typically down to what any ioplug plugin is capable of. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601 (see the comments made by wereHamster, that's me). http://pulseaudio.org/ticket/198 When I last looked at the wine alsa layer it was *really* nasty. It didn't even open the default device, it would instead try to open default:0 I think it was cleaned up a bit, but it should be very simple for someone to rewrite it or write a direct pulse driver. The main wine folks don't use PA so don't really care about this. If there is something in pulse that can be fixed, it shoudl be reported, but as tonnes of apps out there work fine with pulse+alsa, I suspect strongly (and this is based on actually having a quick peak at the code a while back) that the problems lie at the wine end. There may be applications that work fine, but you only have to find a single app that works with native alsa and fails with alsa-pulse emulation to prove that there's a bug in your code. Wine is probably one of the more complex users of the alsa API, and therefore exposing bugs in alsa-pulse that other applications don't hit. I have patched the Wine alsa driver and the alsa-pulse plugin and sound works for me, tested in World of Warcraft and foobar2000. The Wine patch maybe isn't necessary. But the patch to alsa-pulse is required, see my comments in the alsa bugtracker or the PA ticket. This case is a bit confusing. I have tried to look at the realted bug reports this morning. (nothing seemed to have happened since February). Yeah, because I posted all I know, my patches etc, and I've been waiting for someone familiar with the inner workings of PA to comment on the issues. As I said, sound in Wine works for me, but the patches I'm using I consider hacks and not a real solution. There are mentioned two patches for Wine that should fix some of the problems, like the bad hard coded defaults on names for default devices and volume controls. (here: pulseaudio.org/ticket/198 and winehq.org/pipermail/wine-patches/2008-February/050561.html ). I wonder if they are included now? (Really a question for people working on the wine code) The first issue with the device names seems to be fixed. As of March 4, 2008 Wine uses default instead of default:0. The only patch to Wine I'm using now is the one I posted to wine-patches. That one was not merged into Wine - I haven't asked why. I'm not even sure it's necessary. I'll test without my Wine patch to confirm that. But the biggest problem seems to be the delay/latency computation in the alsa-pulse plugin. What about Wines OSS and ESD output? If they work, it could be recommended to try these if alsa output does not work. I disabled OSS support in my kernel, so I can't test paoss. It might work, but it would still be a workaround and not a real fix. Note that there are reported separate problems with DirectSound Where did you see that? Where can I read more about that? tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Colin Guthrie wrote: Tomas Carnecky wrote: Colin Guthrie wrote: What are the bugs in the pulse alsa plugin you refer to? There are some feature limitations but they are typically down to what any ioplug plugin is capable of. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601 (see the comments made by wereHamster, that's me). http://pulseaudio.org/ticket/198 To be honest I thought all of the patches on that bug were now in alsa repo their bugtracker is such a pain to work with, it's like trying to find a needle in a haystack :( All the recent comments were talking about speaker-test being at fault. I didn't realise there was still some issues with the actual alsa-plugin end. I guess I'll try and read through it again with a strong cup of coffee and see if I can understand it again. Not that I'd be able to do much about it but I would like to appreciate what is going on :) FWIW, I consider all patches on the alsa bug as being part of the plugin... I've not looked at our alsa repository for a while but as I say I thought they were all committed now. It may be worth posting a little prompt to the alsa mailing list. Takashi recently committed some of Sjoerd's pulse related stuff to HG, so a gentle prod would probably help (perhaps highlighting exactly which patches are required to save him wading through that alsa bug!) I just looked at the current alsa-plugins code. Takashi fixed the symptoms, but not the cause of the bug(s). He removed the assertions. Errors now are propagated to the application instead of crashing the whole application. But the bug that is causing it still remains in the code. See comment number 0018163 in the alsa bugtracker. I fixed that in the patch I attached to the bug report. Anyhow, that patch fixes speaker-test. Wine however needs two additional changes. First, alsa-pulse doesn't honor the 'start threshold', that is how much the application has to write until the pcm is automatically started. The alsa pulse plugin harcodes that to 'buffer_size - period_size' but Wine sets it to '1'. When Wine writes the first byte, it expects the pcm to start. There is a test in Wine where it writes very few data and then waits for it to be played. But PA never starts the pcm and Wine ends up in an endless loop. The 'start threshold' is part of the software params of an alsa pcm. The second fix needed is for pulse_dealy(). As described in the pulseaudio.org ticket, there seems to be a rounding issue. The current code uses: lat = pa_stream_get_latency() delay = snd_pcm_bytes_to_frames(pa_usec_to_bytes(lat)) but I had to change it to: delay = snd_pcm_bytes_to_frames(ti-write_index-ti-read_index) - 3000 The '-3000' is needed. If I set it to less, then some of the Wine tests fail. Wine uses snd_pcm_delay() to find out how much has already been played. Without my change it can happen that snd_pcm_delay() never reaches the number of frames that have been written, even after a long time. tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Nikolai Beier wrote:
Oh, now I looked at the bug reports and got confused again. Is this
the key points? (Ses below:)
== Wine and the alsa plugin for PulseAudio (alsa pulse plugin) ==
PulseAudio normally takes control of the hardware through the device
driver/ALSA. Thereby the hardware device in ALSA is blocked for
other clients like Wine.
PA blocks access to the hardware. Therefore users are advised to create
~/.asoundrc and add 'pcm.!default { type pulse }' to the file. Doing so,
all applications which use alsa magically start using the alsa pulse
plugin. Unfortunately the alsa pulse plugin has bugs, so some
applications don't work. Wine is one of those applications.
Perhaps Winealsa (the output driver for ALSA) needs direct hardware
access? Or it is/was just coded that way, but does not need to be. Or
it was never a problem?
Wine should not need hardware access. Maybe it mistakenly did in the
past. But it should not. If it still does, then it needs to be fixed.
Winealsa is now (may 4. 20008) fixed, so it uses the alsa device
default instead of default:0 (or like numbers), and does not
require a volume control called PCM but uses the default volume
control.
Yes, that is correct. This part of the Wine alsa driver should now be fixed.
Finally there are the delay problem(s).
* wereHamster noted that the ALSA pulse plugin might set Wine in an
endles loop. http://www.pulseaudio.org/ticket/198#comment:8
FYI, I'm wereHamster. I have a fix for that. I'll submit the patch after
I figure out how to use mercurial.
* Some have notices large delays (like one second), which is tracked
back to some delay calculations in the ALSA pulse plugin.
I haven't come across this problem. Are there bug reports that track
this issue?
If a gamer wants lowest possible latency, and does not need any other
app to play sound (like voice chats like Teamspeak), then they
should use pasuspender.
Yes, pro-gamers most definitely want to do that. But for normal users
the alsa pulse plugin should 'just work'. In my (subjective) tests,
running World of Warcraft, I haven't found the PA latency to be much
bigger then dmix.
tom
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Colin Guthrie wrote: I disagree that this community is unresponsive. You just have to be patient. Lennart is the main developer but he does not sit slavishly reading the mailing list and responding immediately. He'll usually have a big purge every couple weeks, but generally does respond to almost everyone who asks something, unless someone else has jumped in already. PulseAudio + Wine is still a big no-no. Like described in my earlier mail to this mailing list (sent 24.2.2008) I've come to a point where I don't know any further and asked for help. Nobody answered. Not even to the ticket in PA trac or the ticket in the alsa bugtracker. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. Sorry for hijacking the thread, but the community has been largely unresponsive to this particular issue. Just wanted to bring that up. tom ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Issues with Wine and alsa pulse plugin
I've reached a point where I need some help from the PA developers to solve the problems. Basically there seems to be a problem with how the latency is calculated inside PA. I described the problems in [1] (comment #10). Any help how to solve it would be appreciated. tom [1] http://www.pulseaudio.org/ticket/198 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
