[pulseaudio-discuss] Moving sources and sinks

[Lennart Poettering]

eOn Wed, 07.05.08 00:43, Tomas Carnecky (tom at dbservice.com) wrote:

> 
> 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 sorry I wrote what I wrote above. When I did this I wasn't aware
that you actually supplied patches for all issues you pointed out. You
have every right to complain if good patches you submitted are being
ignored. I am sorry. 

However, you're a bit at the wrong address here. It's more an issue
with ALSA here, not with PA, I have no commit access to ALSA HG, and
their BTS is not really something they regularly go through. Post
those patches to the ALSA ML. When I submit patches to the pulse
driver in alsa-plugins I do the same.

> > 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.

I guess I should have another look then.

snd_pcm_sw_params_set_xfer_align() is obsolete/redundant according to
Takashi. And some returns values are not checked. But those things
don't really matter.

The driver should use the new name hinting code in
ALSA. (i.e. what aplay -L shows), instead of creating device strings
itself. (But that's actually problematic, I don't do this in PA either
because the hinting is very very flaky)

WINE should never open an audio device like "hw" (or "plughw") as first
choice. It should use "default". And then "front:" (for stereo),
"surround40:" (for surround 4.0), and so on. Opening "hw" is call
for trouble, especially for people with emu10k1. It is only OK to
open hw: as last resort, since that's the only way to open mono
devices (like webcam mikes) properly, but certainly not as first
option. 

Always try to open the devices without "plug" first, and only as
second choice with "plug". 

Opening "default:0" doesn't make any sense.

The ctl device to open should first be the one you also open for
PCM. Only when that fails you might want to fall back to hw:xxx.

It's really bad style to parse the ALSA config tree to find the default
card id. Especially since not all alsa devices are really hw sound
cards.

ALSA silence foo doesn't make any sense for recording.

The DirectSound code seems to assume that mmap access is
available. That's an invalid assumption.

The code should use snd_pcm_recover() to recover from error conditions.

The code should use smixer, not fiddle directly with ctl/hctl.

But all in all it's quite ok, certainly not as bad as it used to
be. But I only had a rough look. And for those issues pointed out
one could probably blame ALSA's lacking docs. ;-)

The killer for PA is mostly the enumeration code and the assumption
that mmap is available.

> 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?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4