[pulseaudio-discuss] Moving sources and sinks

[Colin Guthrie]

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