Re: [pulseaudio-discuss] Multiple users (kde) on Debian
'Twas brillig, and Mark Cross at 26/07/10 04:54 did gyre and gimble: In a situation where there is a single physical seat (i.e. one keyboard and monitor) but there are multiple logical seats, the PA logic is to cork (mute) the first user, and enable sound for the next logged-in user. However, with CTRL-ALT-F7 CTRL-ALT-F8, etc it is possible to switch user's X screens without logging in. Furthermore, if one user starts a console session to a different user with sudo -i -u user2 bash, there is no log-in process, and the second user (user2) does not get to activate sound. Assuming no user is in the audio group. Is there a way to allow concurrent (local) sounds for both users? There is always a way :D The problem is that this is not the normal setup (imaging User A setting up their Brittany Spears Discog on a loop and locking the screen! How evil can a human be?!?) But ultimately you can run PA in system mode. Lots of things don't work as nicely (such as module loading and such like) and efficiency mechanisms (i.e. using SHM for data passing which is much faster) will be lost. But the short answer is: 1. Create a pulse user and add it to the audio group. 2. Run pulseaudio in system mode (pulseaudio --system) 3. Put your users in the pulse-access groups. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Multiple users (kde) on Debian
Colin Guthrie wrote: 'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble: Colin Guthrie wrote: So, there must be a way supported by maintainers to have two PA instances form two users that share access to the sound system. Sadly there is no officially recommended way to do this. This is actually enforced at a lower level than PA with ConsoleKit ultimately being responsible for writing the ACLs on the device nodes (via udev) used for the sound h/w. We are talking of two instances of PA here, saying that the responsibility is somewhere else (in CK), looks like a way to squirrel away the responsibility to do the right thing. If user1 validates access to user2 (pahost + concept), what's the fuss? ck-list-sessions will tell you which user is active and typically this user will get access to various different resources on the machine by virtue of them being active. Hmmm, yes that is working. On user2 logging-in and getting it's Session as active, is able to play sounds. On switching with CTRL-ALT-F7 and CTRL- ALT-F8 (or using switch-user) the corresponding Session changes state to active and is allowed to play sounds. However, this concept of active deals with the logged-in user, there is no concurrency in it. Each user is switched on or off as needed. PA simply listens to messages from CK and gracefully releases it's control of the devices when it's not supposed to have access. In reality we're just being a good citizen in this regard. Yes, PA should acknowledge CK messages and act accordingly. I don't know if demanding exclusive, unchallenged ownership of the sound hardware is being a good citizen. The problem Pulseaudio was supposed to solve was to have mixing of several streams, but in doing so, PA took total ownership of the sound hardware, not allowing any other service to access the hardware, not even a second instance of PA. That have just shift the mixing issue from ALSA to PA, with seemingly equivalent basic problems. Yes, it has several interesting and useful features, but I wonder: what is the supported way to have several services access the sound system? As the developers decided to completely take ownership of the sound hardware: Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for PA? In theory this would be possible. There are however two basic problems. The first is that a physical socket file patch is currently used. This could be changed perhaps to be a more abstract socket, but as things stand, user2 would need to have physical write permission to that socket (there are various ownership checks and such in the code). But if user2 could access user1's PA socket, and he had access to the cookie used (~/user1/.pulse-cookie), then user2 could output sound to user1's PA daemon. Linking the cookie (~/user1/.pulse-cookie) is easy enough, what else is needed to access user1's PA socket? If user1 were a member of the audio group, then even if user1's session was not active (according to console-kit), he would be allowed to access the sound devices by virtual of them being group writeable. Not having any user as part of the audio group is a PA recommendation: http://pulseaudio.org/wiki/FAQ Section 3 - Troubleshooting, Item 10 Sound doesn't work when switching users By removing all users from the audio group (the PulseAudio server still runs in the audio group), PulseAudio is able manage access to sound devices (/dev/snd/*) amongst multiple users with the help of ConsoleKit. That enforces the concept of PA being the owner of (/dev/snd/*), so, it should be PA who should deal with this concurrent situation IMO. Also, audio group ownership creates this kind of problems: http://swiss.ubuntuforums.org/showthread.php?t=1417647page=2 A perhaps simpler (and slightly less efficient) mechanism to enable this is to simply enable networking support for the primary user (either without authentication or with a copied cookie file). Then set default-server=localhost in the client.conf of other users. No, that will create this rather confusing situation occurs: http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg06635.html So, using such option breaks normal user switching. Of course the same problems regarding the ability of user2 to know what output user1 was making and generally sniff or otherwise interfere with them still exist (and user2 would also not be able to use SHM etc. too). I rather see this sniffing issue rather inconsequential IF user1 specifically has to validate user2 access. After that, user1 will know, as he has enabled such access. Besides, what is the issue with the output? Having the sound of a Brittany Spears song playing in the speakers is so annoying? Doesn't PA have the ability to mute individual streams? Just present user1 the running streams of user2 in pavucontrol and allow him to mute as needed. The only
[pulseaudio-discuss] Rate/Timing issues when streaming over BT from iPhone.....
Hi All, Hopefully everyone isn't receiving this twice, I think the first one was blocked due to being to large (I've trimmed the output below, hopefully not too much though!) Apologies if this is duplicated. Alex Hi All, I've setup pulse audio to stream music from my iPhone (connected using BlueTooth) and output it, using module-loopback This is working fine, the only issue I have appears to be related the bitrate/timing etc... The music is very crackly, and is playing back too slowly I've tried changing a number of options, but haven't been able to resolve it. I've tried lots of different combinations of the 'rate' option, but none helped... Any help really would be much appreciated, please find debug output below, along with the script I'm executing: Script: #!/usr/bin/pulseaudio -vvvnF load-module module-alsa-sink device=default:CARD=Live sink_name=output rate=48000 load-module module-bluetooth-device address=XX:XX:XX:XX:XX:XX path=/org/bluez/1662/hci0/dev_XX_XX_XX_XX_XX_XX profile=a2dp_source auto_connect=yes name=input rate=44100 load-module module-loopback source=1 sink=0 rate=44100 Partial output: I: main.c: Daemon startup complete. I: module-loopback.c: Loopback overall latency is 100.04 ms + 0.00 ms + 39.51 ms = 139.55 ms I: module-loopback.c: Should buffer 35280 bytes, buffered at minimum 0 bytes I: module-loopback.c: Old rate 44100 Hz, new rate 43218 Hz D: bluetooth-util.c: dbus: interface=org.bluez.AudioSource, path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged D: module-bluetooth-device.c: dbus: interface=org.bluez.AudioSource, path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged D: bluetooth-util.c: dbus: interface=org.bluez.AudioSource, path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged D: module-bluetooth-device.c: dbus: interface=org.bluez.AudioSource, path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged I: main.c: Got signal SIGUSR2. I: module.c: Loaded module-cli-protocol-unix (index: #3; argument: ). I: module-loopback.c: Loopback overall latency is 99.98 ms + 0.00 ms + 39.51 ms = 139.49 ms I: module-loopback.c: Should buffer 34576 bytes, buffered at minimum 0 bytes I: module-loopback.c: Old rate 43218 Hz, new rate 43236 Hz I: client.c: Created 0 UNIX socket client D: bluetooth-util.c: dbus: interface=org.bluez.AudioSource, path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged D: module-bluetooth-device.c: dbus: interface=org.bluez.AudioSource, path=/org/bluez/1662/hci0/dev_64_B9_E8_19_DD_FA, member=PropertyChanged I: module-loopback.c: Loopback overall latency is 99.99 ms + 400.66 ms + 42.02 ms = 542.67 ms I: module-loopback.c: Should buffer 34592 bytes, buffered at minimum 2560 bytes I: module-loopback.c: Old rate 43236 Hz, new rate 43300 Hz I: module-loopback.c: Loopback overall latency is 99.98 ms + 806.05 ms + 39.69 ms = 945.71 ms I: module-loopback.c: Should buffer 34640 bytes, buffered at minimum 69240 bytes I: module-loopback.c: Old rate 43300 Hz, new rate 44965 Hz I: module-loopback.c: Loopback overall latency is 99.98 ms + 781.78 ms + 40.83 ms = 922.60 ms I: module-loopback.c: Should buffer 35976 bytes, buffered at minimum 134708 bytes I: module-loopback.c: Old rate 44965 Hz, new rate 46568 Hz I: module-loopback.c: Loopback overall latency is 99.98 ms + 429.80 ms + 40.62 ms = 570.40 ms I: module-loopback.c: Should buffer 37256 bytes, buffered at minimum 79028 bytes I: module-loopback.c: Old rate 46568 Hz, new rate 45144 Hz I: module-loopback.c: Loopback overall latency is 100.00 ms + 409.27 ms + 41.85 ms = 551.11 ms I: module-loopback.c: Should buffer 36120 bytes, buffered at minimum 73904 bytes I: module-loopback.c: Old rate 45144 Hz, new rate 45044 Hz I: main.c: Daemon shutdown initiated. Thanks in advance Alex a...@apics.co.uk Homer Simpson: Facts are meaningless. You could use facts to prove anything that's even remotely true!___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Multiple users (kde) on Debian
'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble: So, there must be a way supported by maintainers to have two PA instances form two users that share access to the sound system. Sadly there is no officially recommended way to do this. This is actually enforced at a lower level than PA with ConsoleKit ultimately being responsible for writing the ACLs on the device nodes (via udev) used for the sound h/w. We are talking of two instances of PA here, saying that the responsibility is somewhere else (in CK), looks like a way to squirrel away the responsibility to do the right thing. If user1 validates access to user2 (pahost + concept), what's the fuss? If it's squrreling out then I apologise, but really different components of a system should work together right? Different layers should generally be interoperable right? Or should every layer just do it's own thing and screw the decisions and designs of lower layers? That said, I'm certainly not against the principle of a validation, but that is fundamentally different to the whole design of PA as it stands. The concept may sound simple, but it'll basically require a full rewrite of large parts of PA, not to mention changing several parts of consolekit and udev with regards to the ACLs. ck-list-sessions will tell you which user is active and typically this user will get access to various different resources on the machine by virtue of them being active. Hmmm, yes that is working. On user2 logging-in and getting it's Session as active, is able to play sounds. On switching with CTRL-ALT-F7 and CTRL- ALT-F8 (or using switch-user) the corresponding Session changes state to active and is allowed to play sounds. However, this concept of active deals with the logged-in user, there is no concurrency in it. Each user is switched on or off as needed. That's the way it works yes. If you don't like this approach it's really something to bring up with the Console Kit folks and make your case there. PA simply listens to messages from CK and gracefully releases it's control of the devices when it's not supposed to have access. In reality we're just being a good citizen in this regard. Yes, PA should acknowledge CK messages and act accordingly. I don't know if demanding exclusive, unchallenged ownership of the sound hardware is being a good citizen. Well all we're doing is acting on the messages given from a lower layer in the system. I'm not really sure how we can do more than that. Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for PA? In theory this would be possible. There are however two basic problems. The first is that a physical socket file patch is currently used. This could be changed perhaps to be a more abstract socket, but as things stand, user2 would need to have physical write permission to that socket (there are various ownership checks and such in the code). But if user2 could access user1's PA socket, and he had access to the cookie used (~/user1/.pulse-cookie), then user2 could output sound to user1's PA daemon. Linking the cookie (~/user1/.pulse-cookie) is easy enough, what else is needed to access user1's PA socket? Well it's just a matter of getting the path correct. On a typical X11 login, have a look at the output of xprop -root | grep PULSE this will show you the format of the PULSE_SERVER variable. This can be put into the env var PULSE_SERVER or the client.conf file as the default-server option. If user1 were a member of the audio group, then even if user1's session was not active (according to console-kit), he would be allowed to access the sound devices by virtual of them being group writeable. Not having any user as part of the audio group is a PA recommendation: http://pulseaudio.org/wiki/FAQ Section 3 - Troubleshooting, Item 10 Sound doesn't work when switching users By removing all users from the audio group (the PulseAudio server still runs in the audio group), PulseAudio is able manage access to sound devices (/dev/snd/*) amongst multiple users with the help of ConsoleKit. That enforces the concept of PA being the owner of (/dev/snd/*), so, it should be PA who should deal with this concurrent situation IMO. Also, audio group ownership creates this kind of problems: http://swiss.ubuntuforums.org/showthread.php?t=1417647page=2 Yes it is indeed the part of the recommended set up, but then so is the method of operating where only the active user has access to the sound system and you've already stated that you don't accept that recommendation so it follows that you may also have to deviate in other ways too. Also I don't think, that PA being the owner of /dev/snd/* is correct. I will try and update that FAQ to clarify, but the PA server does *not* run in the audio group as quoted. It runs as the user, and consolekit gives the active user write permission on /dev/snd/* by
Re: [pulseaudio-discuss] pulseaudio debug mode
On Fri, 2010-07-23 at 08:58 +0100, Colin Guthrie wrote: 'Twas brillig, and Chris at 23/07/10 02:04 did gyre and gimble: What is the best way to start PA for debugging and still have all the usual clients running? If you mean having all the clients connect (e.g. applications with libcanberra support or similar for sound events), then there are basically two ways. The first is as Luke suggests. These clients will automatically reconnect to PA if they need to (provided you have a vaguely recent libcanberra), after it is restarted and run in debug mode. Alternatively you can simply set debug-level to debug in daemon.conf (in /etc/pulse or ~/.pulse), and then grep pulseaudio /var/log/messages Col Colin, the link below is for some more debug output. Notice in the first section that 8 seconds after spamd starts processing a message the the Alsa error starts, 2 seconds after that the overruns start. Notice in line 145 that it took 145 seconds to process a message, that's about 125 too long. I've noticed that when I start getting the overrun errors that the processing of a message takes forever, though this doesn't happen every time, just periodically. All I know is that while this is going on the drive is constantly being accessed for minutes at a time in the first case from 9:03 to 9:08. http://pastebin.com/tZNYaqRV -- Chris KeyID 0xE372A7DA98E6705C signature.asc Description: This is a digitally signed message part ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Multiple users (kde) on Debian
'Twas brillig, and Mark Cross at 26/07/10 22:57 did gyre and gimble: Colin Guthrie wrote: 'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble: That said, I'm certainly not against the principle of a validation, but that is fundamentally different to the whole design of PA as it stands. The concept may sound simple, but it'll basically require a full rewrite of large parts of PA, not to mention changing several parts of consolekit and udev with regards to the ACLs. Then, perhaps, the design is flawed from the beginning? I don't think so. To do something as you suggest essentially means that a whole user-based permissions model has to be built into PA and PA itself has to be turned into a system service. This in itself means that lots of nice things like the zero copy core will have to be sacrificed because the overhead of secure SHM access across users is likely to not be worth the benefit. In other words the whole user-based principles of a unix based system are essentially thrown away and a whole new user-based system is built into the sound server subsystem. This isn't the right place for a user management system in the first place and it doesn't make sense really to implement it there. Just because the system does not do what you want it to do, does not mean that: a) There are not good reasons against doing what you want. b) That the design is flawed. You're perfectly within your rights to ask the question, but I happen to think that the design is not flawed, and it's simply a use case that, while attractive to some niche use cases, has implementation repercussions that are a long way from desirable. That's the way it works yes. If you don't like this approach it's really something to bring up with the Console Kit folks and make your case there. I really don't know the details, but: Is CK controlling the (xhost +...) made by the X-server? Or is it a service/task that the server covers by itself? No but CK will control access to e.g. /dev/dri which is used by the xserver. It has nothing to do with the permission to access the X server socket and the right to use the Xserver. In actual fact the X server case is a pretty good example of what we do. We are very similar to the X server. I'll describe it below. Well it's just a matter of getting the path correct. On a typical X11 login, have a look at the output of xprop -root | grep PULSE this will show you the format of the PULSE_SERVER variable. This can be put into the env var PULSE_SERVER or the client.conf file as the default-server option. No result from that command here: $ xprop -root PULSE PULSE: no such atom on any window. $ xprop -root | grep PULSE $ $ _ I guess you've either a) restarted PA since logging in to X11, or b) do not have an XDG compliant login manager that processes XDG autostart .desktop files. The file start-pulseaudio-x11 should be run via XDG autostart at X11 init. This script will make these properties available. These properties allow you e.g. to ssh to a remote machine and have the display *and* the sound locally. Yes it is indeed the part of the recommended set up, but then so is the method of operating where only the active user has access to the sound system and you've already stated that you don't accept that recommendation so it follows that you may also have to deviate in other ways too. Why, oh my, why, such answer? I thought it was a perfectly reasonable answer? I'm not suggesting there is anything particularly wrong with your approach. It's not the typical use case but the software can do it and I'm trying my best to tell you how to use it that way. It isn't anything to do with what I accept or not. I am trying (very hard) to comply with all the pulseaudio recommendations and special conditions and, at the same time, cover a simple, specific need. One that seems impossible to get you to agree exists, much less provide a solution to. Sorry you feel that way. I've tried my best to describe what you need to do to get it working. If those instructions are not clear then please let me know which bits you are having trouble understanding. You are correct that I don't agree that your use case is one which has any real life, practical uses, but I've certainly given you a two or three different ways in which you can achieve the end result you want. The fact is that your simple, specific need is orthogonal to the special conditions. You can't have both at the same time. If you can't sacrifice the special conditions, then you have to give up on achieving your solution. Also I don't think, that PA being the owner of /dev/snd/* is correct. I will try and update that FAQ to clarify, but the PA server does *not* run in the audio group as quoted. It runs as the user, and consolekit gives the active user write permission on /dev/snd/* by virtual of an ACL. The audio group does not come into it. That's what the
