Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
2011-11-09 12:19, Colin Guthrie skrev: 'Twas brillig, and Martin Steigerwald at 07/11/11 21:49 did gyre and gimble: Am Montag, 7. November 2011 schrieb Maarten Bosmans: 2011/11/7 Martin Steigerwald: Hi! Hi Maarten, hi, Before using Pulseaudio sound from both sessions has been played simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, but I bet stopping the audio comes from Pulseaudio. I read about system-wide mode. But first I shouldn't use it and second it doesn't solve this issue anyway, cause sound is still stopped. Maybe I missed setting autospawn on clients to off - cause I saw three pulseaudio daemons, one system-wide and two from the users -, but I do not like messing around with my Pulseaudio setup anymore - especially when its not recommended. Reason for trying Pulseaudio for me mostly was cause thats whats coming with Debian KDE standard install out of the box in the meanwhile. So whats the official way to achieve what I had before out of the box? The default per-session handling of audio makes sense for unix users being used by different human users on a shared computer but it does not make too much sense for my use case. I would load module-protocol-native-tcp with ip-acl=127.0.0.1. Then for other users set PULSE_SERVER=localhost. Could this work with a three server setup: 1) one system-wide on 127.0.0.1 2) two session based ones that communicate with the system wide one? This ins't really what was suggested. I haven't followed this thread closely, but I think this is a real use case and thus something we should officially support, and just not some very sparse but vocal minority. For me, I'm imagining something like a GUI where you can consciously assign one or more cards to be "system-wide" instead of "user-wide". That would in turn control consolekit/systemd and possibly other stuff that needs to be done to ensure that this card is to be used by the "pulse" user instead of the current user. We would also set up a system-wide instance for this card. The user-wide pulseaudio would be set up to talk to the system-wide one if present (presumably through a protocol-native tunnel? There are so many different ways of talking that I don't remember if there is a better one). Sure, the user would have to live with no SHM support - in most cases I assume this overhead would be quite neglible. Sure, recording can be eavesdropped, but if the user has made that choice in the first place, that would be a feature. This obviously needs integration with other projects and downstream distros, and trying to think with both hats on, I think PA upstream is better off with trying to make some recommendations for this use case, as the alternative would be to have distros doing things on their own and then being beat up by PA for doing things the wrong way. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Colin, first, thanks for your long, detailled answers! Just a short reply: On 09.11.2011 11:56, Colin Guthrie wrote: Now consider two users on an accessible system: One is visually impaired the other is not - at the same time. OK, but that's really an unrealistic case now. The blind guy needs the sound output, so likely he doesn't have somebody else working on the same machine at the same time. More realistic is: An average couple, he is a unix geek. He has a notebook and a tablet. The notebook is connected to speakers, running mpd for music. Tablet is running mpdroid and controls the mpd. The notebook has 2 users (but never at the same time), so the geek doesn't want to log in to any particular account just to listen music, but wants mpd to work irregardless of the logged-in user. There's no conflict, because if the music disturbs her, she'll just turn around and tell him to stop. Which, I think, will be true for almost all cases where you have 2 humans around the same computer at the same time. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/6] Cards now has ports directly, and device port has list of profiles
'Twas brillig, and David Henningsson at 09/11/11 14:12 did gyre and gimble: > But; I persist in saying that this is something to be separately > considered, and after merging the existing jack detection patches Yeah I agree on this point. I do understand Arun's concern tho'. Ad-hoc API and structure changes will turn us into alsa-lib after a while! I don't think I share this concern for this particular series tho', so I agree that and change like Arun suggests is something that should be done after, if/when Arun reckons it's worth it and there is consensus. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/6] Cards now has ports directly, and device port has list of profiles
On 11/09/2011 01:50 PM, Arun Raghavan wrote: On Tue, 2011-11-08 at 16:00 +0530, Arun Raghavan wrote: On Thu, 2011-11-03 at 21:04 +0200, Tanu Kaskinen wrote: Somehow keeping a list of profiles in the ports doesn't feel right - it's as if that list would have been thrown there just to make things convenient for some random code... But I guess there's a reason, which just isn't apparent from this patch yet, for having that list there. This is my largest concern as well. It's the same concern that I had with Mengdong's suggestion that profiles should have an intended role -- this feels conceptually incorrect, but becomes necessary because we don't know anything about the sink that will appear when the profile is activated. So this is my proposal -- all possible sinks for a card should be created upfront, in an "inactive" state. This way, from both the jack-detection and routing fronts, we can see what sink we want, and if it is inactive, we activate it by going to the profile it "belongs" to and activating that (clearly some conflict-resolution will be needed here too). This isn't a trivial change, but it's something that's been coming up repeatedly, and I'd be much happier if we took a little longer and did it right. Just to expand on the idea since my post was a bit sketchy (I'm talking about sinks only for simplicity, but the same applies for sources as well): 1. Cards will create all sinks that might ever be created during profile switches. This will basically need a refactoring of pa_sink_input_new into two parts -- one for init only, one for registration. 2. Everything except the sink(s) related to the active profile will not be in the core sinks list (=> nothing that's not looking for these inactive sinks will see them). We'd have an inactive_sinks list for these (and these will have a new INACTIVE state (nomenclature can be chosen as anything)). 3. Corresponding to the registration step, there will be a deregistration step to bring the sink back to the INACTIVE state. 4. Profile switches basically now only register/deregister sinks. In the short run, we have a (IMO) cleaner architecture. In the long run, this will provide a lot more metadata that can be used in routing decisions. I hope this is clearer. I'm not sure I agree that this is a cleaner architecture. As long as nothing is actually using the stuff, the extra objects seem mostly superfluous to me. I can see an advantage though: if two profiles now can share sink object (is that part of your idea?), then one could potentially switch from e g "Analog Stereo Output" to "Analog Stereo Duplex" without a glitch on the sink side. I'd like that. But; I persist in saying that this is something to be separately considered, and after merging the existing jack detection patches. Especially so if you're going to build on top of them. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 3/6] Cards now has ports directly, and device port has list of profiles
On Tue, 2011-11-08 at 16:00 +0530, Arun Raghavan wrote: > On Thu, 2011-11-03 at 21:04 +0200, Tanu Kaskinen wrote: > > Somehow keeping a list of profiles in the ports doesn't feel right - > > it's as if that list would have been thrown there just to make things > > convenient for some random code... But I guess there's a reason, which > > just isn't apparent from this patch yet, for having that list there. > > This is my largest concern as well. It's the same concern that I had > with Mengdong's suggestion that profiles should have an intended role -- > this feels conceptually incorrect, but becomes necessary because we > don't know anything about the sink that will appear when the profile is > activated. > > So this is my proposal -- all possible sinks for a card should be > created upfront, in an "inactive" state. This way, from both the > jack-detection and routing fronts, we can see what sink we want, and if > it is inactive, we activate it by going to the profile it "belongs" to > and activating that (clearly some conflict-resolution will be needed > here too). > > This isn't a trivial change, but it's something that's been coming up > repeatedly, and I'd be much happier if we took a little longer and did > it right. Just to expand on the idea since my post was a bit sketchy (I'm talking about sinks only for simplicity, but the same applies for sources as well): 1. Cards will create all sinks that might ever be created during profile switches. This will basically need a refactoring of pa_sink_input_new into two parts -- one for init only, one for registration. 2. Everything except the sink(s) related to the active profile will not be in the core sinks list (=> nothing that's not looking for these inactive sinks will see them). We'd have an inactive_sinks list for these (and these will have a new INACTIVE state (nomenclature can be chosen as anything)). 3. Corresponding to the registration step, there will be a deregistration step to bring the sink back to the INACTIVE state. 4. Profile switches basically now only register/deregister sinks. In the short run, we have a (IMO) cleaner architecture. In the long run, this will provide a lot more metadata that can be used in routing decisions. I hope this is clearer. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 09/11/11 10:43 did gyre and gimble: > I would even do not have any problem when there would still be two session > based pulseaudio daemons just using dmixing for audio output and grabbing > input for recording explicitely. Only then there would need to be some > mechanism to decide which user gets recording. It could by on a case base, > so that Pulseaudio grabs input sinks only on demand. And it should not be > possible to record the dmixed audio output by any user. Each user may only > record his own audio output. > > Maybe thats a workable idea? It's possible. Just configure the default.pa to use dmix for it's alsa sink, and then ensure that you set the profile for the udev-detected card for each user to an input only profile such that it doesn't create a sink too. Of course dmix adds overhead, messes about with timing, and screws up sample rate conversion (and uses the shitty quality resamplers too), but other than that it would work OK. Unless the card supports hardware mixing, the recording would only work for the first user to get it as the other tasks would fail. This is of course a hideous setup with horrible connotations for handling gracefully in UIs etc the cases when the audio doesn't work... It's certainly not something I'd be able to recommend with a straight face. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 09/11/11 10:28 did gyre and gimble: > Easy enough: > > dmix is set by standard as of ALSA 1.0.9rc2 [1] dmix is good system but we've moved on from there. If you are using a pure alsa setup I'd certainly recommend it, but it does strange things to sample rates etc. > but getfacl shows that only one of my users is added to the ACL list for > device files in /dev/snd. Whyever... It's likely (at present due to the information in console-kit. See ck-list-sessions. Only one user is ACTIVE than that user will get ACL access to audio (and numerous other devices too) via udev-acl. In the future, this will be done instead by systemd-logind as console-kit is deprecated. > So its going to be the good old way around: I added both users to group > audio. I removed them from there for the perfect pulseaudio setup. > > Now I get simultaneous audio on both sessions without a glitch. And > frankly I don´t care whether thats by design or not. I even don´t care > about the recording issue for these two users, cause they are both mine. That's fine. If this system works for you and you can happily use the devices you own and run the apps you want, then it's all good. I think it's still a fundamentally flawed system and we cannot design for this use case where security and access is "good enough" or with unnecessary layers and admin overheads. > A mailing list reader suggested a VM for the second user, but all I just > want is two KDE sessions with audio simultaneously and now I just got want > I wanted. Why use a VM when its not needed? I think that's massively overkill. > I still hope that Pulseaudio can give me this by a simple configuration > option one time. I stand by it that this is a perfectly valid setup and do > not want to dictacted to organize my stuff differently by software or > design. I think this is the problem many systems face. We try to design both the audio and all plumbing layers in Linux to deal with a wide variety of situations in a robust and secure manner. That means that some setups will not work, that's the trade off. People don't want to compromise their configuration for good design and that's fine. It's Free Software after all, it's your right. But you also have to consider that the path you are taking is your own and thus the problems you encounter will have to be solved by yourself and a lot of the time when you ask people for support, you'll be given the "it's not supported" response. That's just the way it goes. If you are happy with that then, the best of luck to you :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Martin Steigerwald at 07/11/11 21:49 did gyre and gimble: > Am Montag, 7. November 2011 schrieb Maarten Bosmans: >> 2011/11/7 Martin Steigerwald : >>> Hi! > > Hi Maarten, hi, > >>> Before using Pulseaudio sound from both sessions has been played >>> simultaneously with Phonon + Xine. Now I am using Phonon + GStreamer, >>> but I bet stopping the audio comes from Pulseaudio. >>> >>> I read about system-wide mode. But first I shouldn't use it and >>> second it doesn't solve this issue anyway, cause sound is still >>> stopped. Maybe I missed setting autospawn on clients to off - cause >>> I saw three pulseaudio daemons, one system-wide and two from the >>> users -, but I do not like messing around with my Pulseaudio setup >>> anymore - especially when its not recommended. Reason for trying >>> Pulseaudio for me mostly was cause thats whats coming with Debian >>> KDE standard install out of the box in the meanwhile. >>> >>> So whats the official way to achieve what I had before out of the >>> box? The default per-session handling of audio makes sense for unix >>> users being used by different human users on a shared computer but >>> it does not make too much sense for my use case. >> >> I would load module-protocol-native-tcp with ip-acl=127.0.0.1. >> Then for other users set PULSE_SERVER=localhost. > > Could this work with a three server setup: > > 1) one system-wide on 127.0.0.1 > > 2) two session based ones that communicate with the system wide one? This ins't really what was suggested. Basically for "ease of setup" (although this is a loosely defined term!), Maarten was suggesting that the first user (one who is maybe pretty much always logged in anyway) just runs the only PA server, but runs it as a per-user daemon as normal. But that user customises their default.pa: e.g. create a ~/.pulse/default.pa containing: .include /etc/pulse/default.pa load-module module-protocol-native-tcp ip-acl=127.0.0.1 You should also do touch ~/.pulse/client.conf (I've not checked the syntax but I think it's right). Then for the other users write a /etc/pulse/client.conf with: default-server = localhost autospawn = no The primary user's personal client.conf overrides these settings, but all other users get them. You may also need to disable the XDG scripts from running at login (the start-pulseaudio-* scripts can't remember if this is handled or not - either way the fix is simple, just edit the scripts and put a "[ "$USER" = "yourprimaryuser" ] || exit" near the top of them. You also need to make sure that the primary user is in the "audio" group such that they can always access the sound hardware. With this setup, provided your primary user is always logged in, everyone will have sound. > Or preferably not over TCP/IP at all but using unix sockets? Your primary user will go via unix sockets and get the benefits of SHM for memory transfer (you should therefore run mpd as this user if you run it). The other users would use TCP. In a full system-wide setup, all users could use unix sockets, but none could use SHM for memory transfer, so there is still a tradeoff. > Would this then solve the security issues mentioned on > > http://www.pulseaudio.org/wiki/WhatIsWrongWithSystemMode No. The system is wide open to abuse from all users. > Please tell me when I am completely off track with that idea. Then feel > free to skip answering the more detailed questions below. > >> Security: Much like the X server as soon as you are authenticated you >> have complete control of the sound server, no further per-object access >> checks are done. > > That should be solved, shouldn´t it? A networked server should look at > permissions when other Pulseaudio daemons access it, right? > > But then it is needed to make sure, that the 127.0.0.1 or unix socket is > the only way, the per session servers can access the system wide one. So > users shall not be in the group for accessing the system wide pulseaudio > server directly. Not quite sure what you're suggesting here but obviously for TCP connections there is no concept of "user" unless you make PA support e.g. SASL based authentication or something crazy like that (and please see my previous, much longer explanation of things in reply to Ben's email for why we'd get massively criticised if we started adding that kind of junk to PA!). For sockets, we already have a "pulse-access" group that is needed to be able to access it via a system-wide socket. And as above, the "pulse" user running the PA deamon would need to be in the audio group. >> When in system mode, module loading after startup is disabled for >> security reasons, which means: no hotplug handling in system mode > > Well as thats an option I could enable it again, given that the security > issues are solved. With the above suggestion of not using a real system-wide mode, just a "primary user" mode, there would be no problem with module loading etc. as that user is just
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
'Twas brillig, and Ben Bucksch at 07/11/11 19:43 did gyre and gimble: > On 07.11.2011 19:59, Maarten Bosmans wrote: >> I would load module-protocol-native-tcp with ip-acl=127.0.0.1. >> Then for other users set PULSE_SERVER=localhost. > > Yes, that's what I recommended a friend, too. > Problem is: which pulse server is the main one and which one connects? > Any user can log in first. > > Also, what do you do in cases of e.g. mpd running as daemon (by design) > and needing to output sound, and GNOME running on the same machine. Note > that a lot of pulseaudio depends on an active X11 session, including the > dbus stuff, and bails if there isn't. > > Also note that many of the official disclaimers / stated problems of the > system-wide solution apply when you enable a network port and do stuff > as you suggest. > > May I recommend to officially support the system-wide solution and make > it work well? I don't see another solution for multi-user systems and > daemons. The term "multi-user systems" here is misleading. PA goes out of it's way to be multi-user friendly. What it does not do particularly well OOTB is multiple users at the same time, which, as stated, is by design. I do not want user A to login and play their Brittany Spears discog and lock their station meaning that I have to turn off all sound. I do not want user A to lock their station while running a program that would let them eavesdrop on my private VoIP calls. Now keep in mind that this method of working is NOT really a PA design anyway - yes the PA design fits in with this, but its the underlying layers of the system that set the permissions in the first place. Whether it's console-kit (rapidly becoming obsolete, but in use currently) or systemd-logind, both ultimately work with udev to ensure the ACLs for only the appropriate (i.e. active) user are written to the audio device nodes. The fact that Linux does not have a revoke() system to pull device access away from people meant that if a user had the audio device open when his privileges were revoked, he could still output sound. That's a bad situation but PA fixes that by noticing the permission changes and being a good citizen. But once closed, the user who has no writes on the device should not be able to play. Plain and simple, that's what the lower level permission system imposes. Now another thing that also works very well in the multi-user domain is mutli-seat systems. If you have systems where two people can login at the same time with separate keyboards, pointers and screens, then systemd is very capable of defining seats and allocating e.g. PCI devices or USB ports to each seat. PA will honour this and give each user access to his own USB or PCI sound card. While the practicalities are different, you cannot share single screen for graphics in this case, and sound is pretty much in the same boat. >> This recording thing is, among other things, one of the reasons >> multiple users aren't allowed to connect to eachothers pulse daemon by >> default. > > Exactly. But Martin and me now stated a few usecases where this is > *needed*. Saying "it's not recommended" and "yes, we know it's insecure" > doesn't solve the actual problem. If that's the result of the design, > then the design is obviously wrong and needs to be revised. Needed use cases are still possible. You have to do more work yourself. Depending on how distros package things, you may or may not have to do much more then tick a box in a GUI, but that is very much beyond our control. You have to run a system-wide daemon. It's not something we actively support because this use case is very much in the minority and it causes a lot of headaches and unnecessary overhead - one of the primary disadvantages is the inability to support ho tplugging properly (because any kind of system-wide process will totally ignore the users carefully configured seat configurations etc), causes obvious security problems relating to eavesdropping and also cannot use SHM memory and thus causes a lot more overhead when dealing with client-server communications - i.e. you need to copy the audio data over the wire. So while conceptually it's easy to say "you should support it, it's easy" you end up having to build a whole security manager into PA itself rather than rely on underlying systems. If we were to ever do that we'd get an equally vocal group of people saying "why the hell are you building security policy into PA, that's totally not it's job you idiots". So I say this: If you want system-wide PA, use system-wide PA. We do not recommend it, but it doesn't mean we'll sneak into your house at night and kill your kittens. You have extra overhead which may affect latency in games or voip and you have to make sure your users are in the pulse-access group. You might have to tweak certain files to get bluetooth working, you may not be able to use certain funky features such as network support etc. (tho' it should still be possible to tea
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Mittwoch, 9. November 2011 schrieb Ben Bucksch: > On 09.11.2011 10:50, Martin Steigerwald wrote: > > Am Montag, 7. November 2011 schrieb Maarten Bosmans: > >>> When I start to playback sound from > >>> the session of the first user and then switch to the second user > >>> pulseaudio stops to play back sound from the first user. > >> > >> Correct. This is by design. > > > > I have removed Pulseaudio from my main machine now again. > > ... > > I can have Amarok playback music, while I work on my company´s > > user session and that was all I wanted and what Pulseaudio won´t give > > me easily. > > Tip, for you and others: > If you want to separate stuff for security reasons, you can use a VM > with kvm -soundhw es1370. kvm supports pulse and will redirect all the > sound of the VM to your pulse server. Just set, under the kvm-starting > user, ~/.pulse/client.conf with default-server = ..., and enable the > pulse networking on the server, and you'll hear the Windows-Login-Sound > from your pulse. The VM guest doesn't need to know about pulse. I find > that awesome. Thanks for the hint. Its mainly for data separation, not for security. I trust my laptop setup enough to have two users running on it. And when its off the data is encrypted. I do use virtualization, like for example for the Cisco Anywhere VPN client thats messing with network configuration beyond sanity. > For the pulse people: > Please don't tell people that the problems they run into are by design. > You'll have people running away, or even have quite negative feelings > about pulse. Rather, fix the limitations, please. I am all for innovation. But only as far as it does not take features away that I got used to and really like. I see the point in per session setup, and I even think its suitable for many users. But as it is now, it doesn´t support my use case. I would even do not have any problem when there would still be two session based pulseaudio daemons just using dmixing for audio output and grabbing input for recording explicitely. Only then there would need to be some mechanism to decide which user gets recording. It could by on a case base, so that Pulseaudio grabs input sinks only on demand. And it should not be possible to record the dmixed audio output by any user. Each user may only record his own audio output. Maybe thats a workable idea? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 09.11.2011 11:28, Martin Steigerwald wrote: So its going to be the good old way around: I added both users to group audio. I removed them from there for the perfect pulseaudio setup. ... I still hope that Pulseaudio can give me this by a simple configuration option one time. If you can have applications play directly to ALSA from both sessions, you can also have 2 pulseaudio servers, one per user, both connecting to ALSA, no? That should work, no? Why use a VM when its not needed? Why use 2 user accounts? If it's for mental organization, there are easier solutions, like 2 virtual screens. If it's for security, the VM is better. It was just a suggestion, because I *can* sympathize. I ... do not want to dictacted to organize my stuff differently by software or design. I agree here. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
On 09.11.2011 10:50, Martin Steigerwald wrote: Am Montag, 7. November 2011 schrieb Maarten Bosmans: When I start to playback sound from the session of the first user and then switch to the second user pulseaudio stops to play back sound from the first user. Correct. This is by design. I have removed Pulseaudio from my main machine now again. ... I can have Amarok playback music, while I work on my company´s user session and that was all I wanted and what Pulseaudio won´t give me easily. Tip, for you and others: If you want to separate stuff for security reasons, you can use a VM with kvm -soundhw es1370. kvm supports pulse and will redirect all the sound of the VM to your pulse server. Just set, under the kvm-starting user, ~/.pulse/client.conf with default-server = ..., and enable the pulse networking on the server, and you'll hear the Windows-Login-Sound from your pulse. The VM guest doesn't need to know about pulse. I find that awesome. For the pulse people: Please don't tell people that the problems they run into are by design. You'll have people running away, or even have quite negative feelings about pulse. Rather, fix the limitations, please. Ben ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Mittwoch, 9. November 2011 schrieb Martin Steigerwald: > Am Montag, 7. November 2011 schrieb Maarten Bosmans: > > > Hi! > > > > > > I have two users on my laptop. When I start to playback sound from > > > the session of the first user and then switch to the second user > > > pulseaudio stops to play back sound from the first user. This way I > > > also do not hear appointment reminders from the session thats > > > currently not active unless I switch again. > > > > Correct. This is by design. > > I have removed Pulseaudio from my main machine now again. > > To be fair, sound playback via ALSA does not work in mutiple sessions > in the moment too. If Amarok is playing on one session I can´t play > audio from the second one. I thought that this would be mixed > automatically. Maybe there was some asound.conf in place that I > replaced my one for Pulseaudio. Thus at least this seems to need > additional setup with ALSA too on my machine at the moment. Easy enough: dmix is set by standard as of ALSA 1.0.9rc2 [1] but getfacl shows that only one of my users is added to the ACL list for device files in /dev/snd. Whyever... So its going to be the good old way around: I added both users to group audio. I removed them from there for the perfect pulseaudio setup. Now I get simultaneous audio on both sessions without a glitch. And frankly I don´t care whether thats by design or not. I even don´t care about the recording issue for these two users, cause they are both mine. A mailing list reader suggested a VM for the second user, but all I just want is two KDE sessions with audio simultaneously and now I just got want I wanted. Why use a VM when its not needed? I still hope that Pulseaudio can give me this by a simple configuration option one time. I stand by it that this is a perfectly valid setup and do not want to dictacted to organize my stuff differently by software or design. [1] http://alsa.opensrc.org/Dmix Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/6] Turn device ports into reference counted objects
'Twas brillig, and David Henningsson at 09/11/11 09:42 did gyre and gimble:
> So; I think we've discussed the general case enough, back to where we
> started:
>
> I think this is cleaner and gives better error handling:
>
> void foo_free(foo* f)
> {
> if (!f)
> return;
> /* Possibly more destruction stuff here */
> pa_xfree(f);
> }
>
>
> /* Somewhere else */
>foo_free(bar->f);
>
> Than this:
>
> void foo_free(foo* f)
> {
> pa_assert(f);
> /* Possibly more destruction stuff here */
> pa_xfree(f);
> }
>
> /* Somewhere else */
> if (bar->f)
> foo_free(bar->f);
>
>
> The most common case for bar->f being null is that the bar object was
> not completely initialized. In addition, in destructors you should never
> throw exceptions.
>
> If adjusting my code from the IMO better approach to the IMO worse
> approach is what it takes to get the code in, I'll obviously do it. Let
> me know if that is necessary.
I could fairly easily be persuaded to agree that for "free" functions as
you listed above, asserting is likely overkill. After all pa_xfree(NULL)
is quite happy, so why should any higher level free function complain
more bitterly?
But free functions are arguably a particular class of function. Not
calling free properly only (usually) results in memory leaks.
I certainly wouldn't like a module to call pa_sink_input_move_to() with
invalid pointers and have that handled gracefully. I'd like the
conditions that lead up to the incorrect call to be very much reported
in a backtrace should it ever get out in a release.
Otherwise what happens? The stream is not moved and a something gets
written in a log and some key functionality just doesn't work but often
the user will be none the wise... "Hmm, I thought plugging in my USB was
meant to switch my music to it but it didn't... ho hum never mine"...
just an anonymous entry in a log and nothing gets reported etc. etc.
So for this class of problem, that is clear programming error - using
the APIs wrong - I'm still very much in favour of the assert usage.
But that's just my opinion, and I know it's certainly far from universal.
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] using pulseaudio with simultaneous playback from mutiple X sessions
Am Montag, 7. November 2011 schrieb Maarten Bosmans: > > Hi! > > > > I have two users on my laptop. When I start to playback sound from > > the session of the first user and then switch to the second user > > pulseaudio stops to play back sound from the first user. This way I > > also do not hear appointment reminders from the session thats > > currently not active unless I switch again. > > Correct. This is by design. I have removed Pulseaudio from my main machine now again. To be fair, sound playback via ALSA does not work in mutiple sessions in the moment too. If Amarok is playing on one session I can´t play audio from the second one. I thought that this would be mixed automatically. Maybe there was some asound.conf in place that I replaced my one for Pulseaudio. Thus at least this seems to need additional setup with ALSA too on my machine at the moment. Anyway, I can have Amarok playback music, while I work on my company´s user session and that was all I wanted and what Pulseaudio won´t give me easily. I might still followup the bugs I found on my Amarok playback machine, a ThinkPad T23, at home. Lets see. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 2/6] Turn device ports into reference counted objects
On 11/09/2011 01:15 AM, Colin Guthrie wrote:
'Twas brillig, and David Henningsson at 08/11/11 20:17 did gyre and gimble:
In my opinion assertions are proper error handling when the error in
question is a programming error in our own code.
Eh, I'd say proper error handling is to fix our own code's programming
error! :-)
I suspect what was meant was that when we accidentally call one of our
own functions incorrectly, then it should be good enough to hit an
assert to tell us we've hit the "error between the chair and the
keyboard" case. IMO, this is a valid use of asserts() to find and
eradicate this class of problem. Obviously it goes without saying that
the correct way to address this is to fix the calling code, but the
assert has done it's job well, so it's use is justified.
I'm not saying we should never use asserts, but I think we over-use
them. (And a lot of this goes back to Lennart's code as well.) Instead
of going the extra mile and thinking "hmm, what if this could actually
happen, what should we do in that case?", I suspect that sometimes we
just put in an assert instead, just out of laziness, and see if anyone
ever complains about it. True or not?
I think it's a fine line at times, but I think asserts() work well. What
I mean is that the laziness argument goes both ways and you can take the
opposite extreme that if you handle error cases more gracefully all you
get is a line in a log file for something that you really do want to
complain and or get upstream. Now an assert *is* brutal here, but if the
thing doesn't crash out on the user, we'll likely never know about the
issue and the underlying problem itself may go unnoticed.
So while it's arguably not user friendly at all times, I think it's a
good mechanism to ensure we have robust code over time. Yes, this means
we rely on downstreams cooperating and pushing bug reports (and
hopefully, as is often the case with your good self, bug fixes too) up
to us.
As code evolves, we'll commit new problems and asserts to PulseAudio.
Therefore we will never reach the "robust code" you're talking about in
practice, for PulseAudio as a whole. The result is PulseAudio getting
bad reputation.
But sure, from an upstream/developer perspective all these asserts make
perfect sense. For the end user, most of the time the "single log file
line" approach is better.
So; I think we've discussed the general case enough, back to where we
started:
I think this is cleaner and gives better error handling:
void foo_free(foo* f)
{
if (!f)
return;
/* Possibly more destruction stuff here */
pa_xfree(f);
}
/* Somewhere else */
foo_free(bar->f);
Than this:
void foo_free(foo* f)
{
pa_assert(f);
/* Possibly more destruction stuff here */
pa_xfree(f);
}
/* Somewhere else */
if (bar->f)
foo_free(bar->f);
The most common case for bar->f being null is that the bar object was
not completely initialized. In addition, in destructors you should never
throw exceptions.
If adjusting my code from the IMO better approach to the IMO worse
approach is what it takes to get the code in, I'll obviously do it. Let
me know if that is necessary.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
___
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 4/6] Notify port available status changes
On 11/08/2011 06:52 PM, Tanu Kaskinen wrote: On Tue, 2011-11-08 at 09:09 +0100, David Henningsson wrote: On 11/03/2011 08:22 PM, Tanu Kaskinen wrote: > I'd like ports to have their own subscription class. I also think that could be nice, and I looked into that, but as I understand it, it would require every port to be registered with the core (so it gets an index that is used when things change) and several API additions to make it useful. I'm not sure what you mean by "several API additions", but at least registering port objects to the core would be something that I'd actually like to see happen. Sure, and I'm not saying doing so would be wrong, but it would require changes to the core, the protocol, the client API, etc. It is not work I can sign up for at this time. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
