Re: [pulseaudio-discuss] Moving sources and sinks
Lennart Poettering wrote: > On Wed, 07.05.08 00:43, Tomas Carnecky ([EMAIL PROTECTED]) wrote: >> As the chances of including a native PA driver in Wine are zero, the > > Why are those chances zero? I mean, is there any reason besides that > noone bothered writing a native driver? I've heard that a PA driver exists, but it never was released and probably still lies in someones private repository. The reason not willing to accept a the pulse driver it best descried here: http://www.winehq.org/pipermail/wine-devel/2008-February/062860.html I personally think his arguments are bogus. tomc ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
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
Nikolai Beier wrote: > 2008/5/4 Tomas Carnecky <[EMAIL PROTECTED]>: >> Nikolai Beier wrote: >> > 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. > > So you know that the talk about DirectSound _needs_ hardware access, > and cannot be emulated in a sensible and efficient way is wrong? > Oh, it seems that Microsoft has produces an "DirectSound emulator" > (meaning that the sound is send from DirectSound to a software mixer > and the to the device driver) for Vista, so it should only be a > question about latency to make wine get DirectSound go to a virtual > ALSA interface, i.e. the ALSA device named "pulse". The DirectSound DLL uses a special interface of the low-level sound driver. If that is not available it falls back to software emulation. This is the same for the original Windows DLL as well as the one shipped with Wine. So you have these two situations in Wine: Software emulation: - DirectSound -> WinMM WaveOut functions -> alsa DirectSound acceleration: - DirectSound -> special DirectSound interface -> alsa The special DirectSound interface allows the DirectSound DLL to access alsa directly. Going through the WinMM WaveOut functions adds an additional layer, and therefore delay and CPU consumption. But last I checked the Wine alsa driver didn't use hardware mixing capabilities of the sound card, not when using the special DirectSound interface. So you have no real hardware acceleration, it's always mixing sound in software. You see that DirectSound is using the alsa API in any case. On my desktop I configured alsa to use the pulse plugin. And therefore DirectSound is going through PA. The additional delay is barely noticeable. >> > * "wereHamster" noted that the ALSA pulse plugin might set Wine in an >> > endless 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. > > So it is still a problem that can occur, and triggered by something > else than the problem below? There are currently two bugs in the alsa pulse plugin I know of. One affects Wine directly, the other is triggered by speaker-test. >> >> > * 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? > Only your own: http://bugs.winehq.org/show_bug.cgi?id=10910#c8 > (mentioned previous in this email thread) > I thought it was the same bug that your fix for pulse_dealy() should > remove. We may have confused each other That probably was an old test I did there. I tested today and I haven't seen any audible delay compared to using alsa/dmix directly. The patch to pulse_delay() does not aim at decreasing delay, it only fixes one of the bugs. > I hope you get the feedback on your patches that you want/need. E.g. the line > delay = snd_pcm_bytes_to_frames(ti->write_index-ti->read_index) - 3000 > > I have not seen that c file that line belongs to, nor did I understand > why 3000 was the magic number, and not random symptom treatment. > Does "the thing" fail when delay is too big? > If snd_pcm_bytes_to_frames() can return values below 3000, does the > rest of alsa-pulse and Wine work as it should when delay gets a > negative number? It was symptom treatment. I just tested some random values until the Wine test didn't fail anymore. It's not needed anymore. I removed it from my local patch. 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: > 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: > 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: > 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
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: > 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
