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!) >> 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. Firstly, it's not my code :) Secondly, that's not a 100% true statement. ioplug based plugins in alsa have limitations that true hardware devices don't. 99% of the time it's not needed to use these features (I think I've read something about asynchronous notifications and SIGIO when something happens on the card). This is why e.g. Flash fails. I wont pretend to fully appreciate all these issues, but most high level apps don't generally need to do this. Wine, as a kind of emulator may have valid reasons for poking about at a low level I guess. Flash probably doesn't have good reasons for it. So for that reason some applications just wont work until they change how they use the alsa api or the alsa api is extended to support the kind of thing they are trying to do with ioplug based plugins. These apps would probably fail in a similar way with e.g a bluetooth headset, which proves it's not totally pulse's fault. > 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. Like I say I thought all your patches on that ticket were in the alsa repo now (certainly I've been using them for a while in mdv packages)... I guess I've not looked for a while as I said above. Cheers Col
