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
