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
Re: [pulseaudio-discuss] Moving sources and sinks
On Fri, 02.05.08 11:01, Nick Thompson ([EMAIL PROTECTED]) wrote: Awesome Matt, if you can share your source I would love to see it. What you are doing sounds interesting. For my app I'd like to have two classes of data. For arguments sake these are normal and alert. Normal audio (mp3, wav, application data) needs to be routed to the currently selected output. Alert audio, which would include system sounds, tactile feedback and the like, would need to be routed to a different source (and possibly also the default output source as well). Initially I was looking at some sort of stream tagging mechanism using something like the class filed in ALSA, but this is clunky and I cannot guarantee that all audio will pass through alsa (for example the gstreamer pulse plugin looks interesting for certain apps). At the moment I'm trying to prototype this on a regular x86 desktop system, later I'll move it to an embedded system, once I've figured out a means to implement it. It think the issue I have can be described as follows: based on my current understanding I would need to track every stream to determine where to route it. I'd like to cluster my normal and alert streams together and route them all en-masse to a sink. As mentioned, in the glitch-free branch you have those properties you can attach to each stream. To implement policy routing a module should be written that hooks into the stream creation code (similar to what module-volume-restore already does) looks for the class property and adjusts the sink the stream is attached to properly. 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 11:48, Nick Thompson ([EMAIL PROTECTED]) wrote: fully accept that my use of pulse might be somewhat unorthodox since it is in a speciailsed embedded system, however I also think that multiple device support and routing is of great interest, especially to the music community. One of the issues of audio support on Actually PA's focus does include embedded stuff, but it doesn't include music production that much. As mentioned, policy routing has been requested before, and added most infrastructure that was necessary to implement it. It's in the glitch-free banch. The missing bits and pieces are actually minor in contrast to the infrastructure chnages. mainstream OS's like Max OS X is the lack of simultaneous synchronized multiple device support and this is an area where pulse has a great deal of potential. Since the archives are online one would hope that Uh, this is not correct Mac OSX does have aggregate audio devices. They never worked for me though. 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 23:55, Tanu Kaskinen ([EMAIL PROTECTED]) wrote: Phew. Anyway the second question was not really answered fully. It might be my imprecision in stating the problem so let me try to distill it to the bare bones: For pulseaudio I'd like to know how or if a virtual stream can be created in pulse allowing on the fly redirection to an ALSA sink, that is the crux of the question that I'm searching for an answer. I'd like in an alsa program (or set of programs) to write to a virtual device and have pulse route all audio on that device to a sink, and be able to switch sinks on the fly. I've spent a couple weeks looking into this and I think I've made quite a lot of progress but that part is not clear. It's not possible with current virtual devices. The virtual devices that you can create don't allow their streams (the ones from the virtual device to the destination sinks) to be moved. This is an artificial limitation, btw. It's the respective module that sets the PA_SINK_INPUT_DONTMOVE flag to tell the PA core not to allow moving of the streams. I added this because it kind of contradicts the explicit configuration the user gave before. But primarily the reason is that I was to lazy to implement the code that makes sure that the sink description follows the move. I.e. that LADSPA sink on foobar changes to LADSPA sink on waldo if you move it's stream from foobar to waldo. Also in the case of module-combine (especially in automatic mode) moving those backend streams is really pointless. Patches welcome. I guess I could be talked into dropping PA_SINK_INPUT_DONTMOVE for the LADSPA and remap sinks if someone supplies a patch that implements the description fix properly. As I mentioned somewhere else: the right way to do this thing is writing a small module that hooks into the stream creation and chooses a device based on the role (or class or whatever you call it) of a stream. A bit like module-match+module-volume-restore+some more magic. And of course, we'd need to teach all apps to send PA the class of their streams. A temporary fix is to set the environment var for PULSE_PROP_media.role to video, and so one before starting the client in question. Like this: PULSE_PROP_media.role=phone pacat /dev/urandom PULSE_PROP_media.role=music pacat /dev/urandom You get the idea. 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
Colin Guthrie wrote: Tomas Carnecky 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. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. 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 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. 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. 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
Colin Guthrie wrote: 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. The reason why a native pulse audio won't be included in Wine anytime soon is this. The alsa audio driver in Wine used to be very bad. Lots of bugs in it etc. Last summer there was a GSoC project to fix the driver. That project was successful in that the driver now works. There basically aren't any problems with the Wine alsa driver anymore. Now that Wine has a working audio driver for Linux, they want to focus on that, rather then having a second driver that works only half-way. There was someone who wrote a native pulse driver for Wine. Unfortunately I haven't see the code and I don't think the code was ever released. It probably sits in someones private repository. It would be possible to maintain the pulse driver in a separate repository. For example the ASIO driver for Wine is developed that way. And it works for the people who need that driver. However to merge the driver with 'upstream', you'd have to prove that you are willing to maintain it, that it works perfectly and has no bugs in it. Otherwise they won't even consider including it. 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
On Sat, May 03, 2008 at 04:48:05PM -0700, Nick Thompson wrote: Given what you say (above) about per device routing not being possible I think the area I'd like to concentrate on is figuring out how a module can detect streams as they are being created. That way it could get the call in to switch sink input before the stream is started. So figuring this out would be a great start. This is how I think it might work: 1. Register yourself to listen to new sink input events. The pa_core structure (core.h) has an array of hooks, each corresponding to one type of event. The following will do the registration: pa_hook_connect(core-hooks[PA_CORE_HOOK_SINK_INPUT_NEW], my_callback, my_userdata); There the core variable is a pointer to pa_core. my_callback is a function that gets called when the event happens, and my_userdata is pointer to any data you want the callback function to have access to. 2. Change the destination sink. The callback gets as parameters a pointer to pa_core, a pointer to pa_sink_input_new_data, and the userdata pointer you gave in the registration function. pa_sink_input_new_data has the field sink, which you can set in the callback to be the sink you want the sink input to connect to. This probably conflicts at least with module-volume-restore, which uses the same hook and does sink redirection too. I've been looking at a client app (it is, I think necessary to have one to relay policy info about routings to the module), but I don't think stream routing via a client would be a good way to address the issue. There is likely to be a fair lag between a stream being created, a notification being received that the stream has been created, to communication to the client, and the communication back to the client to switch a sink input. There doesn't appear to be a means to do most of this from a command line, and its not clear to me how the ipc mechanism between the client and the daemon can be exploited to this end. You could still do the tracking based on which null sink the stream tries to connect to. Otherwise, if you decide to manage the routing information in a separate program, I don't think you can use the client API in any way, so you'll have to use some other ipc solution. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Nikolai Beier wrote: 2008/5/4 Tomas Carnecky [EMAIL PROTECTED]: Colin Guthrie wrote: Tomas Carnecky 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. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. 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 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. 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. This case is a bit confusing. I have tried to look at the realted bug reports this morning. (nothing seemed to have happened since February). Yeah, because I posted all I know, my patches etc, and I've been waiting for someone familiar with the inner workings of PA to comment on the issues. As I said, sound in Wine works for me, but the patches I'm using I consider hacks and not a real solution. There are mentioned two patches for Wine that should fix some of the problems, like the bad hard coded defaults on names for default devices and volume controls. (here: pulseaudio.org/ticket/198 and winehq.org/pipermail/wine-patches/2008-February/050561.html ). I wonder if they are included now? (Really a question for people working on the wine code) The first issue with the device names seems to be fixed. As of March 4, 2008 Wine uses default instead of default:0. The only patch to Wine I'm using now is the one I posted to wine-patches. That one was not merged into Wine - I haven't asked why. I'm not even sure it's necessary. I'll test without my Wine patch to confirm that. But the biggest problem seems to be the delay/latency computation in the alsa-pulse plugin. What about Wines OSS and ESD output? If they work, it could be recommended to try these if alsa output does not work. I disabled OSS support in my kernel, so I can't test paoss. It might work, but it would still be a workaround and not a real fix. Note that there are reported separate problems with DirectSound Where did you see that? Where can I read more about that? 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
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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Colin Guthrie wrote: 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!) I just looked at the current alsa-plugins code. Takashi fixed the symptoms, but not the cause of the bug(s). He removed the assertions. Errors now are propagated to the application instead of crashing the whole application. But the bug that is causing it still remains in the code. See comment number 0018163 in the alsa bugtracker. I fixed that in the patch I attached to the bug report. Anyhow, that patch fixes speaker-test. Wine however needs two additional changes. First, alsa-pulse doesn't honor the 'start threshold', that is how much the application has to write until the pcm is automatically started. The alsa pulse plugin harcodes that to 'buffer_size - period_size' but Wine sets it to '1'. When Wine writes the first byte, it expects the pcm to start. There is a test in Wine where it writes very few data and then waits for it to be played. But PA never starts the pcm and Wine ends up in an endless loop. The 'start threshold' is part of the software params of an alsa pcm. The second fix needed is for pulse_dealy(). As described in the pulseaudio.org ticket, there seems to be a rounding issue. The current code uses: lat = pa_stream_get_latency() delay = snd_pcm_bytes_to_frames(pa_usec_to_bytes(lat)) but I had to change it to: delay = snd_pcm_bytes_to_frames(ti-write_index-ti-read_index) - 3000 The '-3000' is needed. If I set it to less, then some of the Wine tests fail. Wine uses snd_pcm_delay() to find out how much has already been played. Without my change it can happen that snd_pcm_delay() never reaches the number of frames that have been written, even after a long time. 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
Nikolai Beier wrote:
Oh, now I looked at the bug reports and got confused again. Is this
the key points? (Ses below:)
== Wine and the alsa plugin for PulseAudio (alsa pulse plugin) ==
PulseAudio normally takes control of the hardware through the device
driver/ALSA. Thereby the hardware device in ALSA is blocked for
other clients like Wine.
PA blocks access to the hardware. Therefore users are advised to create
~/.asoundrc and add 'pcm.!default { type pulse }' to the file. Doing so,
all applications which use alsa magically start using the alsa pulse
plugin. Unfortunately the alsa pulse plugin has bugs, so some
applications don't work. Wine is one of those applications.
Perhaps Winealsa (the output driver for ALSA) needs direct hardware
access? Or it is/was just coded that way, but does not need to be. Or
it was never a problem?
Wine should not need hardware access. Maybe it mistakenly did in the
past. But it should not. If it still does, then it needs to be fixed.
Winealsa is now (may 4. 20008) fixed, so it uses the alsa device
default instead of default:0 (or like numbers), and does not
require a volume control called PCM but uses the default volume
control.
Yes, that is correct. This part of the Wine alsa driver should now be fixed.
Finally there are the delay problem(s).
* wereHamster noted that the ALSA pulse plugin might set Wine in an
endles loop. http://www.pulseaudio.org/ticket/198#comment:8
FYI, I'm wereHamster. I have a fix for that. I'll submit the patch after
I figure out how to use mercurial.
* Some have notices large delays (like one second), which is tracked
back to some delay calculations in the ALSA pulse plugin.
I haven't come across this problem. Are there bug reports that track
this issue?
If a gamer wants lowest possible latency, and does not need any other
app to play sound (like voice chats like Teamspeak), then they
should use pasuspender.
Yes, pro-gamers most definitely want to do that. But for normal users
the alsa pulse plugin should 'just work'. In my (subjective) tests,
running World of Warcraft, I haven't found the PA latency to be much
bigger then dmix.
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
Nick Thompson wrote: OK so I figured out the error of my ways, but I have to say this list is pretty unresponsive in helping the community so I have to ask myself is pulse is a sensible choice for audio development today? Particularly since there is little in the way of useful setup documentation for actually using the library on a programatic way, the error messages from the library and utilities are not particularly helpful and so on. 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. From what I can tell you've posted a couple questions but answered them yourself within a day! It's not really fair of you to answer your questions yourself so quickly without giving anyone a chance to try and be helpful :p The docs for the API from a coding perspective could do with some TLC I agree. I'm just jumping in to the coding now and it's a bit of an uphill struggle but Lennart typically gives good advice on IRC if he's around. I firmly believe that pulse is the most sensible choice for audio development :) Col ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
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. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. Sorry for hijacking the thread, but the community has been largely unresponsive to this particular issue. Just wanted to bring that up. 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
Hi Colin, On May 3, 2008, at 5:53 AM, Colin Guthrie wrote: From what I can tell you've posted a couple questions but answered them yourself within a day! It's not really fair of you to answer your questions yourself so quickly without giving anyone a chance to try and be helpful :p Lol. I take your point. I don't want to waste time so if I have an answer then I should let people know in case they are spending time typing up a response, and forgive me if the email was a little terse, I was becoming quite frustrated at the slowness of my progress. I fully accept that my use of pulse might be somewhat unorthodox since it is in a speciailsed embedded system, however I also think that multiple device support and routing is of great interest, especially to the music community. One of the issues of audio support on mainstream OS's like Max OS X is the lack of simultaneous synchronized multiple device support and this is an area where pulse has a great deal of potential. Since the archives are online one would hope that my answers are of some use to others new to this sport. And I will try to continue to share what I learn in the hope that it is of use to others who are following in the same track. Phew. Anyway the second question was not really answered fully. It might be my imprecision in stating the problem so let me try to distill it to the bare bones: For pulseaudio I'd like to know how or if a virtual stream can be created in pulse allowing on the fly redirection to an ALSA sink, that is the crux of the question that I'm searching for an answer. I'd like in an alsa program (or set of programs) to write to a virtual device and have pulse route all audio on that device to a sink, and be able to switch sinks on the fly. I've spent a couple weeks looking into this and I think I've made quite a lot of progress but that part is not clear. I could write a pulse module that will implement routing policy for individual stream, but since streams are created often I'd need to to track them (not too hard) and know when they are created (harder) and set the routing before the stream starts (no sure how to do this). It seems there might be an easier way, but I don't know what that is. So if you, or someone else, can fill be in on this it would be greatly appreciated. Thanks! Nick ___ 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, May 03, 2008 at 11:48:04AM -0700, Nick Thompson wrote: I fully accept that my use of pulse might be somewhat unorthodox since it is in a speciailsed embedded system, however I also think that multiple device support and routing is of great interest, especially to the music community. If you're part of the music community, you probably should be looking at Jack (http://jackaudio.org/). Except that even though it has marvelous support for routing audio, it doesn't support multiple devices directly. You might have success by using a program called Jack Diplomat (which connects multiple Jack servers). Better support for multiple sound cards is planned for future versions, but I don't expect it to happen anytime soon. Phew. Anyway the second question was not really answered fully. It might be my imprecision in stating the problem so let me try to distill it to the bare bones: For pulseaudio I'd like to know how or if a virtual stream can be created in pulse allowing on the fly redirection to an ALSA sink, that is the crux of the question that I'm searching for an answer. I'd like in an alsa program (or set of programs) to write to a virtual device and have pulse route all audio on that device to a sink, and be able to switch sinks on the fly. I've spent a couple weeks looking into this and I think I've made quite a lot of progress but that part is not clear. It's not possible with current virtual devices. The virtual devices that you can create don't allow their streams (the ones from the virtual device to the destination sinks) to be moved. I could write a pulse module that will implement routing policy for individual stream, but since streams are created often I'd need to to track them (not too hard) and know when they are created (harder) and set the routing before the stream starts (no sure how to do this). It seems there might be an easier way, but I don't know what that is. Writing a module is one possibility. A virtual sink, of which master sink can be changed, doesn't sound a bad idea to me. module-remap-sink could be a good starting point, but I believe it would still take quite a bit of time to figure out the internal APIs. The routing table approach on the other hand could probably be done as a pulse client instead of a module. You could create one or more null sinks (one for each stream class) and maybe set one of them as the default sink. Then your router program listens for new stream events, and if a stream is connected to one of the null sinks, it is added to the tracked streams list and is moved to the appropriate alsa sink. Not the prettiest solution, but it's the easiest I could come up with. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Tomas Carnecky 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. Ubuntu now ships with PA enabled by default, which causes big troubles for those wanting to play games under Wine. I know the best solution would be to have a native PA driver in Wine, but that won't happen anytime soon. There are bugs in the pulse alsa driver. Fixing those shouldn't be such big problem for someone familiar with the inner workings of PA. 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. 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. Sorry for hijacking the thread, but the community has been largely unresponsive to this particular issue. Just wanted to bring that up. That's OK in my book. I don't personally use wine otherwise I'd have probably fixed it by now! It wouldn't take long for someone with suitable motivation to do it. I'm surprised no-one has to be honest. Col. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Hi Tanu, On May 3, 2008, at 1:55 PM, Tanu Kaskinen wrote: On Sat, May 03, 2008 at 11:48:04AM -0700, Nick Thompson wrote: I fully accept that my use of pulse might be somewhat unorthodox since it is in a speciailsed embedded system, however I also think that multiple device support and routing is of great interest, especially to the music community. If you're part of the music community, you probably should be looking at Jack (http://jackaudio.org/). Except that even though it has marvelous support for routing audio, it doesn't support multiple devices directly. You might have success by using a program called Jack Diplomat (which connects multiple Jack servers). Better support for multiple sound cards is planned for future versions, but I don't expect it to happen anytime soon. Thanks for this. My project is purely ALSA and pulse based for an embedded system, however it was my contention that a facility for switching all streams on a virtual device to a sink, then possibly reconfiguring all the streams to render on another sick would be a good thing for music people on x86 and other platforms (unfortunately not what I'm using for deployment :) Although I am doing experiments on x86 to understand how pulseaudio works. I don't think Jack currently has what I need, but thank you for the suggestion. Phew. Anyway the second question was not really answered fully. It might be my imprecision in stating the problem so let me try to distill it to the bare bones: For pulseaudio I'd like to know how or if a virtual stream can be created in pulse allowing on the fly redirection to an ALSA sink, that is the crux of the question that I'm searching for an answer. I'd like in an alsa program (or set of programs) to write to a virtual device and have pulse route all audio on that device to a sink, and be able to switch sinks on the fly. I've spent a couple weeks looking into this and I think I've made quite a lot of progress but that part is not clear. It's not possible with current virtual devices. The virtual devices that you can create don't allow their streams (the ones from the virtual device to the destination sinks) to be moved. I could write a pulse module that will implement routing policy for individual stream, but since streams are created often I'd need to to track them (not too hard) and know when they are created (harder) and set the routing before the stream starts (no sure how to do this). It seems there might be an easier way, but I don't know what that is. Writing a module is one possibility. A virtual sink, of which master sink can be changed, doesn't sound a bad idea to me. module-remap-sink could be a good starting point, but I believe it would still take quite a bit of time to figure out the internal APIs. I think I'm going to have to figure out the internals of pulse to do this, no way round that. Given what you say (above) about per device routing not being possible I think the area I'd like to concentrate on is figuring out how a module can detect streams as they are being created. That way it could get the call in to switch sink input before the stream is started. So figuring this out would be a great start. I've been looking at a client app (it is, I think necessary to have one to relay policy info about routings to the module), but I don't think stream routing via a client would be a good way to address the issue. There is likely to be a fair lag between a stream being created, a notification being received that the stream has been created, to communication to the client, and the communication back to the client to switch a sink input. There doesn't appear to be a means to do most of this from a command line, and its not clear to me how the ipc mechanism between the client and the daemon can be exploited to this end. So I think a client would provide the current policy for a pulse module and the module would bang on the streams as they are created to ensure their routing meets the requirements of the currently implemented policy. But the actual work of switching the streams would, I think, happen in a pulse module. Unfortunately more questions :) Nick ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Awesome Matt, if you can share your source I would love to see it. What you are doing sounds interesting. For my app I'd like to have two classes of data. For arguments sake these are normal and alert. Normal audio (mp3, wav, application data) needs to be routed to the currently selected output. Alert audio, which would include system sounds, tactile feedback and the like, would need to be routed to a different source (and possibly also the default output source as well). Initially I was looking at some sort of stream tagging mechanism using something like the class filed in ALSA, but this is clunky and I cannot guarantee that all audio will pass through alsa (for example the gstreamer pulse plugin looks interesting for certain apps). At the moment I'm trying to prototype this on a regular x86 desktop system, later I'll move it to an embedded system, once I've figured out a means to implement it. It think the issue I have can be described as follows: based on my current understanding I would need to track every stream to determine where to route it. I'd like to cluster my normal and alert streams together and route them all en-masse to a sink. Thanks!! Nick On May 2, 2008, at 10:37 AM, Matt Patterson wrote: I do agree that coding for pulse can be a steep learning curve, which is why I opted to build all my solutions by simply connecting to the text mode control socket and sending commands/parsing text output. I have built what is essentially a multiplex audio switch allowing any of x number input sources to play out of any x number of output sinks, all controlled via a python or php app. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
So I think what I would do is make a combined sink for each class of data that routes all audio to all sources. If you disable the module to gets rid of idle streams this will leave you with active but corked streams to all output devices from each sink. You can then update which streams are muted. If you need to do this literally stream by stream (as in playback event by playback event) this might not work because I am just using the text interface (basically what pacmd is) and would have no way of being notified when a new stream is played. If on the other hand the routing is more global and based on external events you could easily update the current config and then all future sounds would play as expected. I'm not at home right now, but I will try to remember to forward my code tonight or tomorrow morning. If you really can't wait I sent an older version to the mailing list a while back, it should be in the archives. Matt Nick Thompson wrote: Awesome Matt, if you can share your source I would love to see it. What you are doing sounds interesting. For my app I'd like to have two classes of data. For arguments sake these are normal and alert. Normal audio (mp3, wav, application data) needs to be routed to the currently selected output. Alert audio, which would include system sounds, tactile feedback and the like, would need to be routed to a different source (and possibly also the default output source as well). Initially I was looking at some sort of stream tagging mechanism using something like the class filed in ALSA, but this is clunky and I cannot guarantee that all audio will pass through alsa (for example the gstreamer pulse plugin looks interesting for certain apps). At the moment I'm trying to prototype this on a regular x86 desktop system, later I'll move it to an embedded system, once I've figured out a means to implement it. It think the issue I have can be described as follows: based on my current understanding I would need to track every stream to determine where to route it. I'd like to cluster my normal and alert streams together and route them all en-masse to a sink. Thanks!! Nick On May 2, 2008, at 10:37 AM, Matt Patterson wrote: I do agree that coding for pulse can be a steep learning curve, which is why I opted to build all my solutions by simply connecting to the text mode control socket and sending commands/parsing text output. I have built what is essentially a multiplex audio switch allowing any of x number input sources to play out of any x number of output sinks, all controlled via a python or php app. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Moving sources and sinks
Thanks Matt, it can wait a day or so! Nick On May 2, 2008, at 11:27 AM, Matt Patterson wrote: I'm not at home right now, but I will try to remember to forward my code tonight or tomorrow morning. If you really can't wait I sent an older version to the mailing list a while back, it should be in the archives. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
