Re: [pulseaudio-discuss] Pulseaudio alsa configure hook
On Mon, 28.04.08 09:53, Colin Guthrie ([EMAIL PROTECTED]) wrote: Sjoerd Simons wrote: The attached patch extends the alsa pulse plugin set with a alsa configuration hook. Allowing one to specify some configuration parameters that only come into effect when pulseaudio is running. I was waiting with baited breath after your chat on IRC as to what your solution would actually be! I like it! I think the overhead at initialisation is probably OK, although I guess it depends on how an application works - e.g. if it constant opens and closes alsa connections then does this overhead mount up? If not then this looks like a good solution. That said Lennart has said in the past that he didn't like the idea of Alsa automatically falling back to h/w access if pulse isn't responding. (this was in reference to tweaking the alsa plugin itself, rather than this approach which is slightly different conceptually, albeit with the same end goal). I think his comment at the time was it masks configuration problems. Do you have any thoughts on this Lennart? I think that the patch is OK although it does have some problems as Sjoerd already pointed out. My plan for the future is to enable auto-spawning by default in addition to starting PA by gnome-session. This will tape over these problems, too. The reason for this is that as it stands right now, PA doesn't really work from the console. Since console logins don't have anything like a session manager, we cannot really start PA from there. Same with SSH logins or System services using PA. Unfortunately console logins are still very important for a11y people, and audio happens to be too. So, PA will be started as user-daemon (not session daemon!) from session managers, in addition to be started by auto-spawning. This will tape over configuration problems, but heck, I see no better way. Then I will write a small module that terminates PA if a) no client is connected anymore and b) the user owning it is not logged in anymore according to CK and c) some time has passed. Then I'll add some code that PA won't terminate anymore when an X11 connection dies. And then everything is bright an shiny. That way PA will probably feel more robust to many people and we'll win the hearts of our a11y people ;-) So, in summary: I don't think Sjoerd's patch is flawless, or that it is the way to the future. But it's an OK temporary fix on our way to world domination. It get's the Approved by Lennart stamp. ;-) Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
On Sat, 03.05.08 15:05, Tomas Carnecky ([EMAIL PROTECTED]) 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. 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. 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. I do acknowledge though that the PA plugin for libasound is not perfect. There are some issues in ioplug and one one in the backend itself that I am aware of. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ 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
eOn Wed, 07.05.08 00:43, Tomas Carnecky ([EMAIL PROTECTED]) 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 PoetteringRed Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de
