Re: [pulseaudio-discuss] Moving sources and sinks
On Wed, 07.05.08 07:43, Tomas Carnecky ([EMAIL PROTECTED]) wrote: > > Lennart Poettering wrote: > > On Wed, 07.05.08 00:43, Tomas Carnecky ([EMAIL PROTECTED]) wrote: > >> 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? > > I've heard that a PA driver exists, but it never was released and > probably still lies in someones private repository. > > The reason not willing to accept a the pulse driver it best descried > here: http://www.winehq.org/pipermail/wine-devel/2008-February/062860.html > I personally think his arguments are bogus. As I read it they are happy to merge a PA driver as long as someone wants to maintain it. Pretty understandable. I wouldn't call that "zero" chance. ;-) 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: > On Wed, 07.05.08 00:43, Tomas Carnecky ([EMAIL PROTECTED]) wrote: >> 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? I've heard that a PA driver exists, but it never was released and probably still lies in someones private repository. The reason not willing to accept a the pulse driver it best descried here: http://www.winehq.org/pipermail/wine-devel/2008-February/062860.html I personally think his arguments are bogus. tomc ___ 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-d
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
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
On Sun, 04.05.08 14:15, Tanu Kaskinen ([EMAIL PROTECTED]) wrote: > > 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 is exactly how it should be done! 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
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 Fri, 02.05.08 11:27, Matt Patterson ([EMAIL PROTECTED]) wrote: > 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. Using the combined sink for this kind of stuff is not a good idea. The point of module-combine is to deal with sampling rate deviations. It resamples audio to fix them. If you already complained about CPU usage, then this is not going to help it. 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 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 Fri, 02.05.08 10:37, Matt Patterson ([EMAIL PROTECTED]) 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. BTW. Some people seem to assume that I as the author PA do believe that the native PA API is the best thing ever invented. Be assured: I don't think so. It is powerful, and not redundant, but it is admittedly hard to use due to its asynchronous nature. However, I do have a plan to fix this. 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 Fri, 02.05.08 10:20, Nick Thompson ([EMAIL PROTECTED]) 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. Yes, our documentation is not perfect. Nothing is perfect. But complaining about Free Software like this doesn't really make you any friends in the community, you know? This is not how Free Software works. Our resources are not infinite. Actually they are very much finite, it's only me who works on PA full-time. All other contributors do it in their spare time or supply only patches from time to time. Also, coling and tanuk and others do a very good job with responding on this mailing list (and I am very thankful for what they are doing. Thanks, dudes!). I am not constantly monitoring this list. However, I try my best to respond to every single post that is left unanswered, from time to time. So please be patient, eventually most people should get an answer from me, even if it might take a while, like this reply did. In short: we're not your support monkeys! Thank you very much. > What I need to be able to do is route audio around. I suspect write a > module for pulse that will look at the alsa stream class and based on that > use the input index to set the sick for that stream. It would be nice to > have a feature whereby I can rout all output sent to a particular sink, to > another sink. I guess what I'd like to do is be able to create virtual > devices whose output can be changed on the fly. So for example I could > define an mp3 output that I can switch between headphone output and speaker > output depending on a system setting. Or between one speaker output and > another. If pulse has a means to do this already I'd appreciate someone > pointing me in the direction that can help. Something like this has been asked for before. In the glitch-free branch in SVN you'll find a "proplist" feature that allows you to attach all kinds of meta information to streams, sinks, sources, clients. One of the reasons to add this is to allow implementation of policy routing like you suggest. > It seems ALSA will do most of this and the ALSA list seems to be a lot more > active, so maybe I was mistaken in thinking that Pulse would really be a > useful addition to our audio stack, particularly since on an embedded > system it consume disproportionate resources for the benefit it > provides. Oh come on, dude. You make it sound like I should feel bad because you won't use my software. I am not sure in what strange a world you live. You should be thankful that the Free Software people allow you to use your software for free -- no the other way around. And for fuck's sake, if there's something that the software you are interested in lacks, then please stop complaining and supply a patch. That is how free software works. Also, if you don't need PA, then don't use it. Nobody forces you. Especially in embedded space you should really know if you need something before you add it to your stack. I am happy for every complaint I get less from people with no clue about open source like you. > Also where is the mixer implemented and how is it controlled. Or is the > mixer just a dumb "you have 3 streams coming in and I will make them one" > type deal. In other words is there bussing or output switching in the > mixer. If not, is this planned? I am not sure I get what exactly you are asking for. But yes, PA mixes audio. Surpised? > Anyway, in case this helps anyone else, the sources that are listed by > list-sources are not really sources to pulse. So trying to move them > around will not work. Here's something I wrote up on the subject: I think you didn't understand the distinction PA makes between sinks and source-outputs, resp. sources and sink-inputs. I.e. clocked vs. non-clocked. Please shut up with your complains. Learn how Free Software works. I don't take complains. I only take patches, suggestions and bug reports. 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
Nikolai Beier wrote: > 2008/5/4 Tomas Carnecky <[EMAIL PROTECTED]>: >> Nikolai Beier wrote: >> > 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. > > So you know that the talk about DirectSound _needs_ hardware access, > and cannot be emulated in a sensible and efficient way is wrong? > Oh, it seems that Microsoft has produces an "DirectSound emulator" > (meaning that the sound is send from DirectSound to a software mixer > and the to the device driver) for Vista, so it should only be a > question about latency to make wine get DirectSound go to a virtual > ALSA interface, i.e. the ALSA device named "pulse". The DirectSound DLL uses a special interface of the low-level sound driver. If that is not available it falls back to software emulation. This is the same for the original Windows DLL as well as the one shipped with Wine. So you have these two situations in Wine: Software emulation: - DirectSound -> WinMM WaveOut functions -> alsa DirectSound acceleration: - DirectSound -> special DirectSound interface -> alsa The special DirectSound interface allows the DirectSound DLL to access alsa directly. Going through the WinMM WaveOut functions adds an additional layer, and therefore delay and CPU consumption. But last I checked the Wine alsa driver didn't use hardware mixing capabilities of the sound card, not when using the special DirectSound interface. So you have no real hardware acceleration, it's always mixing sound in software. You see that DirectSound is using the alsa API in any case. On my desktop I configured alsa to use the pulse plugin. And therefore DirectSound is going through PA. The additional delay is barely noticeable. >> > * "wereHamster" noted that the ALSA pulse plugin might set Wine in an >> > endless 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. > > So it is still a problem that can occur, and triggered by something > else than the problem below? There are currently two bugs in the alsa pulse plugin I know of. One affects Wine directly, the other is triggered by speaker-test. >> >> > * 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? > Only your own: http://bugs.winehq.org/show_bug.cgi?id=10910#c8 > (mentioned previous in this email thread) > I thought it was the same bug that your fix for pulse_dealy() should > remove. We may have confused each other That probably was an old test I did there. I tested today and I haven't seen any audible delay compared to using alsa/dmix directly. The patch to pulse_delay() does not aim at decreasing delay, it only fixes one of the bugs. > I hope you get the feedback on your patches that you want/need. E.g. the line > delay = snd_pcm_bytes_to_frames(ti->write_index-ti->read_index) - 3000 > > I have not seen that c file that line belongs to, nor did I understand > why 3000 was the magic number, and not random symptom treatment. > Does "the thing" fail when delay is too big? > If snd_pcm_bytes_to_frames() can return values below 3000, does the > rest of alsa-pulse and Wine work as it should when delay gets a > negative number? It was symptom treatment. I just tested some random values until the Wine test didn't fail anymore. It's not needed anymore. I removed it from my local patch. 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
2008/5/4 Tomas Carnecky <[EMAIL PROTECTED]>: > Nikolai Beier wrote: > > 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. So you know that the talk about DirectSound _needs_ hardware access, and cannot be emulated in a sensible and efficient way is wrong? Oh, it seems that Microsoft has produces an "DirectSound emulator" (meaning that the sound is send from DirectSound to a software mixer and the to the device driver) for Vista, so it should only be a question about latency to make wine get DirectSound go to a virtual ALSA interface, i.e. the ALSA device named "pulse". > > * "wereHamster" noted that the ALSA pulse plugin might set Wine in an > > endless 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. So it is still a problem that can occur, and triggered by something else than the problem below? > > > > * 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? Only your own: http://bugs.winehq.org/show_bug.cgi?id=10910#c8 (mentioned previous in this email thread) I thought it was the same bug that your fix for pulse_dealy() should remove. We may have confused each other I hope you get the feedback on your patches that you want/need. E.g. the line delay = snd_pcm_bytes_to_frames(ti->write_index-ti->read_index) - 3000 I have not seen that c file that line belongs to, nor did I understand why 3000 was the magic number, and not random symptom treatment. Does "the thing" fail when delay is too big? If snd_pcm_bytes_to_frames() can return values below 3000, does the rest of alsa-pulse and Wine work as it should when delay gets a negative number? -- Nikolai Beier ___ 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
2008/5/4 Tomas Carnecky <[EMAIL PROTECTED]>: > > 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? At http://www.pulseaudio.org/ticket/198#comment:7 (comment by "proyvind", apparently testet with a patch that fixes both the hardcoded volume control and the use of default:0 . And here: http://bugs.w
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
Thank you, Tanu. I'll take a look at this way. No doubt I'll have lots of questions once I get into it. Regards Nick On May 4, 2008, at 4:15 AM, Tanu Kaskinen wrote: > 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 ___ 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
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
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
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). 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) What about Wines OSS and ESD output? If they work, it could be recommended to try these if alsa output does not work. Note that there are reported separate problems with DirectSound Because Wine is not "just working" (or has been working badly recently) it also deserves to be mentioned at the wiki at pulseaudio.org (So I'll try to do that). -- Nikolai Beier ___ 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
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
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
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
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
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
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
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
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
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
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
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. You should check out module-combine-sink. You could combine all your outputs, then simply mute all but the one you currently want to use. I am using this as a 4x4 switch for audio and it works great. I also have simple (but poorly commented) python/php source I am happy to share if it helps. Matt 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. What I need to be able to do is route audio around. I suspect write a module for pulse that will look at the alsa stream class and based on that use the input index to set the sick for that stream. It would be nice to have a feature whereby I can rout all output sent to a particular sink, to another sink. I guess what I'd like to do is be able to create virtual devices whose output can be changed on the fly. So for example I could define an mp3 output that I can switch between headphone output and speaker output depending on a system setting. Or between one speaker output and another. If pulse has a means to do this already I'd appreciate someone pointing me in the direction that can help. It seems ALSA will do most of this and the ALSA list seems to be a lot more active, so maybe I was mistaken in thinking that Pulse would really be a useful addition to our audio stack, particularly since on an embedded system it consume disproportionate resources for the benefit it provides. Also where is the mixer implemented and how is it controlled. Or is the mixer just a dumb "you have 3 streams coming in and I will make them one" type deal. In other words is there bussing or output switching in the mixer. If not, is this planned? Anyway, in case this helps anyone else, the sources that are listed by list-sources are not really sources to pulse. So trying to move them around will not work. Here's something I wrote up on the subject: To see the output devices we have created use the list-sinks command >>> list-sinks 2 sink(s) available. * index: 0 name: driver: flags: LATENCY HARDWARE state: IDLE volume: <0: 100% 1: 100%> mute: <0> latency: <97959 usec> monitor source: <0> sample spec: channel map: used by: <0> linked by: <0> module: <0> description: index: 1 name: driver: flags: LATENCY HARDWARE state: IDLE volume: <0: 100% 1: 100%> mute: <0> latency: <75827 usec> monitor source: <1> sample spec: channel map: used by: <0> linked by: <0> module: <1> description: Currently no sound is playing, so if you look to see the sink inputs, you'll see that none have currently been created: >>> list-sink-inputs 0 sink input(s) available. Play a file in a different terminal window (or using your preferred method to make sound). For this experiment I used paplay: [EMAIL PROTECTED]:~$ paplay -v Sony\ CD-ROM\ Test\ Disk\ Type\ 3.0/14\ Cantibile\ Op.\ 17.wav Using sample spec 's16le 2ch 44100Hz' Connection established. Stream successfully created I used the -v option to get verbose output from the command, which has no bearing on this experiment. Now if you look at the sink inputs you can see that one has been created for the stream we are currently rendering. >>> list-sink-inputs 1 sink input(s) available. index: 9 name: driver: flags: state: RUNNING sink: <0> 'usbAudio' volume: <0: 100% 1: 100%> mute: <0> latency: <50 usec> sample spec: channel map: resample method: auto module: <3> client: <7> 'paplay' By inspection it can be seen that this stream is being rendered on the "usbAudio" device. To switch this stream to the built-in audio source is a straightforward operation, use the move-sync-input command in pacmd. We can see from the output above that the stream index is 9 (note that the index is incremented for each time a new stream is created, so it has to be determined for each stream). >>> move-sink-input 9 hdaAudio Now if the sink inputs ar
Re: [pulseaudio-discuss] Moving sources and sinks
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. What I need to be able to do is route audio around. I suspect write a module for pulse that will look at the alsa stream class and based on that use the input index to set the sick for that stream. It would be nice to have a feature whereby I can rout all output sent to a particular sink, to another sink. I guess what I'd like to do is be able to create virtual devices whose output can be changed on the fly. So for example I could define an mp3 output that I can switch between headphone output and speaker output depending on a system setting. Or between one speaker output and another. If pulse has a means to do this already I'd appreciate someone pointing me in the direction that can help. It seems ALSA will do most of this and the ALSA list seems to be a lot more active, so maybe I was mistaken in thinking that Pulse would really be a useful addition to our audio stack, particularly since on an embedded system it consume disproportionate resources for the benefit it provides. Also where is the mixer implemented and how is it controlled. Or is the mixer just a dumb "you have 3 streams coming in and I will make them one" type deal. In other words is there bussing or output switching in the mixer. If not, is this planned? Anyway, in case this helps anyone else, the sources that are listed by list-sources are not really sources to pulse. So trying to move them around will not work. Here's something I wrote up on the subject: To see the output devices we have created use the list-sinks command >>> list-sinks 2 sink(s) available. * index: 0 name: driver: flags: LATENCY HARDWARE state: IDLE volume: <0: 100% 1: 100%> mute: <0> latency: <97959 usec> monitor source: <0> sample spec: channel map: used by: <0> linked by: <0> module: <0> description: index: 1 name: driver: flags: LATENCY HARDWARE state: IDLE volume: <0: 100% 1: 100%> mute: <0> latency: <75827 usec> monitor source: <1> sample spec: channel map: used by: <0> linked by: <0> module: <1> description: Currently no sound is playing, so if you look to see the sink inputs, you'll see that none have currently been created: >>> list-sink-inputs 0 sink input(s) available. Play a file in a different terminal window (or using your preferred method to make sound). For this experiment I used paplay: [EMAIL PROTECTED]:~$ paplay -v Sony\ CD-ROM\ Test\ Disk\ Type\ 3.0/14\ Cantibile\ Op.\ 17.wav Using sample spec 's16le 2ch 44100Hz' Connection established. Stream successfully created I used the -v option to get verbose output from the command, which has no bearing on this experiment. Now if you look at the sink inputs you can see that one has been created for the stream we are currently rendering. >>> list-sink-inputs 1 sink input(s) available. index: 9 name: driver: flags: state: RUNNING sink: <0> 'usbAudio' volume: <0: 100% 1: 100%> mute: <0> latency: <50 usec> sample spec: channel map: resample method: auto module: <3> client: <7> 'paplay' By inspection it can be seen that this stream is being rendered on the "usbAudio" device. To switch this stream to the built-in audio source is a straightforward operation, use the move-sync-input command in pacmd. We can see from the output above that the stream index is 9 (note that the index is incremented for each time a new stream is created, so it has to be determined for each stream). >>> move-sink-input 9 hdaAudio Now if the sink inputs are listed again you can see the output sink has changed, verifying this by listening, the output does indeed get switched. >>> list-sink-inputs 1 sink input(s) available. index: 9 name: driver: flags: state: RUNNING sink: <1> 'hdaAudio' volume: <0: 100% 1: 100%> mute: <0> latency: <50 usec> sample spec: channel map: resample method: auto module: <3> client: <7> 'paplay' The api routines for this are in the file /pulseaudio-0.9.8/src/pulse/ introspect.c Look at these routines: int pa_stream_connect_playback (pa_stream *s,const char *dev, const pa_buffer_attr
[pulseaudio-discuss] Moving sources and sinks
Hi there, I have a system where I need to move sources to different sinks according to a policy. I thought I'd try this out using pacmd before I start trying to code this up with pulse, put pacmd does not behave as expected (by me :). I tried the following command in pacmd: >>> move-sink-input 0 hdaAudio.monitor No sink input found with this index. When I list the sinks and sources I get the output listed below. Is anyone familiar with pacmd. According to the help, this looks as if it should work. Eventually I want to publish several virtual devices, route them to a mixer (possibly via an SRC) and route the mixer output to a specific ALSA sink. I need two instances of mixers so that I can mix some streams to one output device and some streams to another. I need to be able to dynamically rout the entire output to another ALSA sink depending on the policy set. I'd also like to rout sources to the different mixer instances as required. If I can do routing within a single mixer instance, so much the better. Is Pulse capable of this or do I need to find another route to implement this. Thanks for any advice, Nick here is the output of list for sources and sinks: >>> list-sources 3 source(s) available. index: 0 name: driver: flags: state: IDLE volume: <0: 100% 1: 100%> mute: <0> latency: <0 usec> sample spec: channel map: used by: <0> linked by: <0> monitor_of: <0> module: <0> description: (USB Audio) via DMA> index: 1 name: driver: flags: state: IDLE volume: <0: 100% 1: 100%> mute: <0> latency: <0 usec> sample spec: channel map: used by: <0> linked by: <0> monitor_of: <1> module: <1> description: Analog) via DMA> * index: 2 name: driver: flags: HW_VOLUME_CTRL LATENCY HARDWARE state: IDLE volume: <0: 0% 1: 0%> mute: <0> latency: <23219 usec> sample spec: channel map: used by: <0> linked by: <0> module: <2> description: >>> ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
