Re: [pulseaudio-discuss] Non-native connections don't respect padevchooser settings
On Mon, 19.11.07 01:26, Ed Catmur ([EMAIL PROTECTED]) wrote: Hi, I have something approaching the PerfectSetup[1], with a per-user daemon and using the ALSA module and the esound protocol module for legacy clients. When I change the default output device using padevchooser, it applies only to native PulseAudio streams, not to ALSA or esound clients - in particular, to Gnome sound events. I assume this is because padevchooser sets the default output device on the root X window, which is then read by native clients but isn't communicated to the daemon. Yes. Clients that do not use the native API do use only the algorithm that is native to their respective API for selecting servers. For ESD clients this means that only $ESPEAKER is checked. Is there any way to fix this - for example, could the per-user pulseaudio daemon listen for padevchooser's defaults on the root window and apply them to streams without output device set? padevchooser as it stands now is going to die anyway. Right now it's mostly a zeroconf browser. I will replace it with something that connects to a local sound server and allows to change the default output device of it. This will allow hot moving of all current streams to the new device. However connections will always be proxied through the local server. This has a bad effect on latency but a good effect on the bandwith used and is probably the best way to go. As soon as this is done, padevchooser will work for both native and ESD clients. Stay tuned. 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] Problem with 0.9.7 and Audacious
On Fri, 16.11.07 19:27, Hasse Hagen Johansen ([EMAIL PROTECTED]) wrote: Thomas == Thomas Jost [EMAIL PROTECTED] writes: Thomas Hi, I have the same kind of problem with mplayer (svn Thomas version) and its pulseaudio output : shorts pauses about Thomas every seconds, which makes it impossible to watch Thomas anything. Thomas I noticed that if I don't load module-x11-publish (or if I Thomas run pax11publish -r), things work nicely. And if I then Thomas run pax11publish -e it starts not working again. In the Thomas same time everything works perfectly with xine and mpd, Thomas without having to disable module-x11-publish or anything Thomas else. Thomas This problem first appeared when I upgraded from PA 0.9.6 Thomas to 0.9.7, without any modification of mplayer. I tried to Thomas recompile it since then, but it didn't change anything. It Thomas happens on my AMD64 Gentoo laptop as well as on my i686 Thomas Archlinux workstation. Thomas Any suggestion? Is it a known bug? (I didn't find any Thomas corresponding ticket on the website). Thomas Regards, Thomas Ahh..I think I read about that somewhere. That when using the esd-wrapper with gnome(maybe not specifically gnome) that you should disable the module-x11-publish module, because it was working in that configuration..I think it actually was in some of the announcements for 0.9.7 Thanks for getting me to remember it :-) I will try it right away This again sounds like an issue of TCP vs. UNIX sockets. PS: There's something wrong with the way your user agent quotes... 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] Problem with 0.9.7 and Audacious
On Fri, 16.11.07 18:36, Thomas Jost ([EMAIL PROTECTED]) wrote: Hi, I have the same kind of problem with mplayer (svn version) and its pulseaudio output : shorts pauses about every seconds, which makes it impossible to watch anything. HHmm, does Mplayer SVN ship a Pulse plugin now? Or did you apply the patch I wrote a long time ago but which afaik never got merged? I noticed that if I don't load module-x11-publish (or if I run pax11publish -r), things work nicely. And if I then run pax11publish -e it starts not working again. In the same time everything works perfectly with xine and mpd, without having to disable module-x11-publish or anything else. Hmm, my instinct tells me that this probably has something to do with using TCP vs. using UNIX sockets. If you use module-x11-publish then the order of protocols that are published to X11 and thus are used by clients to connect to the PA server depend on the order the native protocol modules have been loaded into the server. If module-x11-publish is not used then UNIX sockets are always preferred over TCP sockets. If you use module-x11-published is used then it *might* be the other way round. Please paste what pax11publish (without any arguments) outputs! Most likely MPlayer is using very short buffers in PA. They can be smaller if you use UNIX sockets, and need to be a bit larger if you use TCP. By default they are chosen quite large, so that they are safe on all transports. I wonder why that is not sufficient on mplayer. 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] pulse gui
On Thu, 15.11.07 10:41, Esteban Salazar ([EMAIL PROTECTED]) wrote: So I watched the video. I guess what I find confusing is this notion of Moving streams. I think a lot could be resolved instead by getting rid of the notion of moving streams and instead conceptually have streams exist always and independent (similar to now) but instead of moving streams you just specify which outputs they are conneced to. I am not sure if that's true. Having such a patchbay might make sense for pro audio stuff. But for normal users the most common case is output on all devices simultaneously, and alternatively output on only one device at a time, I would say. If people really want more complicated setups they are welcome to edit the PA configuration files to add arbitrarily configured module-combine sinks. Hiding/reconfiguring the virtual combine sink would come either at the cost of additional latency or at making the code of PA more exceptionally more difficult. Why? because evening out the different quartzes of the devices is done in a seperate thread -- this comes at the cost of an additional context switch and some buffering. Which makes it diserable to not do it if we only output on a single device. However, switching between these modes constantly and without interruptions in playback is very hard, makes the core of PA very complex and the latencies very unreliable. But yes, I agree to have this would be nice. However, I doubt that there is a good real-life use case for this that would justify the cost of doing things like this. So, if I want to direct a stream to my three outputs (o1,o2,o3), I can just specify in the gui by checking those three boxes. This really simplifies things because some of the more confusing concepts in pulse just go away. For example, you don't need virtual devices anymore (you might keep them around as a convenient shorthand for saying hook up these a,b,c devices to this stream but you don't need them anymore and only advanced users would care about the shortcut). Uh? On one hand you say it is confusing and then you call it convenience? The use case I have is that someone wants to switch playback from his internal laptop speakers to his usb headset, and such like. If we'd implement what you suggest then the user would first have to enable output on the target device and then disable output on the internal speakers. Two clicks instead of just one. Also, if we'd do what you suggest then the user might end up with having a stream that is not connected to any output. Something which is *really* confusing I would say. In short: I think that *moving* streams between devices is what the user wants. Not *copying* them. Also the confusion with multicast streams and looping back to speakers goes away. You just treat multicast output as another output device and if you also want audio to come out of your local speakers, you just also leave your local speakers checked. Uh, that's not quite the same. Also, multicast streams are very exotic things. The normal user shouldn't think about them, and see them ever. And for those who like to play with it it is fine to open paprefs and click on a few checkboxes. I see ne value in making multicast streams even more easy to use. They are already ridiculuously easy to enable. It probably takes more time to understand what Multicasting actually is then to enable them. I think the current gui actually has a bug because you are using check boxes instead of radio boxes for moving streams but in the change I'm talking about, that would actually be what you want except that you could check multiple boxes at once. Yes, this bug has been reported before. This will be fixed in the next release of pavucontrol. Here's the commit: http://svn.0pointer.de/viewvc/trunk/src/pavucontrol.cc?root=pavucontrolr1=62r2=67 My idea in the image I send was just in recognition of that fact that many gui apps are associated with a single stream so it makes sense to also expose this exact dialog in the window menu so you can direct the output of that app direct from the app instead of having to open and extra pulse dialogs. Yes, I acknowledge this part. And I plan to implement something like this as mentioned. However, I will do it with *moving* streams, not *copying* them. Having things associated with the window manager is also cool because just like remembering window locations and dimensions when a program is launched, the window manager (or whatever) could remember audio settings from previous launches so you wouldn't really have to ever set this stuff up except when you wanted to change it which for most streams you never would. For example, once I specify that I want all my desktop sounds only to go to the local speakers, I'm never going to change that, same thing with directing my audio player outputs to my living room stereo. PA already remembers the device and volume of all applications and restores them when they
Re: [pulseaudio-discuss] Pulseaudio as a systemwide deamon and as the default ALSA plugin doesn't seem to work right.... ?
On Tue, 20.11.07 03:49, Lennart Poettering ([EMAIL PROTECTED]) wrote: If you use PA this way then local authentication works by membership in the group pulse-rt. What you described sounds like authentication errors. So please make sure that all users who try to access PA are in that group. Oops, that group is pulse-access, not pulse-rt. Sorry for the confusion. 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] Pulseaudio as a systemwide deamon and as the default ALSA plugin doesn't seem to work right.... ?
On Thu, 15.11.07 11:48, Kevin Williams ([EMAIL PROTECTED]) wrote: On November 15, 2007 05:46:49 am Colin Guthrie wrote: I'm not 100% sure but with 0.9.7 pa I don't think there are many reasons to run PA system wide any more. User switching is supported so that switching from one user to another work pretty well (tho' I have to admit I've not personally tested this!) Does that mean, a systemwide instance is not recommended and wouldn't work as expected, likely to cause problems ? It's not recommended. But it should work as expected -- if you know what you do and set everything up properly. It boils down to this: Lennart isn't especially keen on helping you fixing problems caused by setting up system-wide setup incorrectly. It's more difficult to set up, and more difficult to get right. 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] Pulseaudio as a systemwide deamon and as the default ALSA plugin doesn't seem to work right.... ?
On Thu, 15.11.07 02:05, Kevin Williams ([EMAIL PROTECTED]) wrote: I have installed pulseaudio from the cvs repo and have configure the PA daemon to run as a system wide instance. To ensure all the apps work without needing to configure each of them individually, I have set the pulseaudio as the default ALSA plugin in /etc/asound.conf following the guide Perfect Setup. PA lauches without any problems. But, the problem shows up when I launch any of the multimedia apps. Sometimes, I see a message which says Audio device not available. May be it is in use by another application. I'm pretty sure, there're no other apps at that same time yet, I receive those messages, don't know why !?? If you set up PA as a system-wide instance you need to configure things differently than when using it per-session. If you run it as system-wide daemon than you are expected to understand very well what is happening. I do not recommend to run it as system daemon. I know that Gentoo sets up PA this way. This is against my recommendation. The only use case for running PA as system-wide instance is thin clients, where the users using PA are not local. If that's the only focus of Gentoo than great. But the last time I looked this wasn't quite the only focus of Gentoo. ;-) If you use PA this way then local authentication works by membership in the group pulse-rt. What you described sounds like authentication errors. So please make sure that all users who try to access PA are in that group. Again, if you use PA as system daemon, then it is your own fault if things don't work as expected. You are expected to know what you do if you run PA in this mode. 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
