Re: [pulseaudio-discuss] multiseat and PulseAudio?
Op 16-5-2011 8:49, David Henningsson schreef: On 2011-05-14 17:46, Tomasz Chmielewski wrote: Traditionally, UNIX systems were supporting multiseat desktop sessions (i.e. multiple keyboards, video cards, monitors attached to one PC). According to: http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode What is wrong with system mode? Or with other words: if you run it that way on your desktop, then you are doing it the wrong way. What is the correct way to use PulseAudio with multiseat systems? Assuming there is also one sound card per seat, you should run one PulseAudio per seat, and as the user currently logged in to that seat. Exactly how to do that, i e set up access to the right sound card for the logged in user (with ConsoleKit etc) is beyond my knowledge though. Currently i use a script to set the users' default sink according the display he is on, because you do not know which user is logged in on which display. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] multiseat and PulseAudio?
On 16.05.2011 08:49, David Henningsson wrote: On 2011-05-14 17:46, Tomasz Chmielewski wrote: Traditionally, UNIX systems were supporting multiseat desktop sessions (i.e. multiple keyboards, video cards, monitors attached to one PC). According to: http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode What is wrong with system mode? Or with other words: if you run it that way on your desktop, then you are doing it the wrong way. What is the correct way to use PulseAudio with multiseat systems? Assuming there is also one sound card per seat, you should run one PulseAudio per seat, and as the user currently logged in to that seat. Exactly how to do that, i e set up access to the right sound card for the logged in user (with ConsoleKit etc) is beyond my knowledge though. I only have one sound card in the PC. It works fine when I start PulseAudio in the system mode, but according to documentation, this is unsupported, strongly discouraged and should only be used in some embedded setups. So I'd like to do it the right way - unfortunately, PulseAudio documentation does not explain how to setup PulseAudio with multiseat. If I start PulseAudio in the user mode, only one user gets a sound card; the second one gets Dummy Output. -- Tomasz Chmielewski http://wpkg.org ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] multiseat and PulseAudio?
On 16.05.2011 10:43, duportail wrote: Currently i use a script to set the users' default sink according the display he is on, because you do not know which user is logged in on which display. I only have one sound card for all users, so I guess your scripts wouldn't help much? -- Tomasz Chmielewski http://wpkg.org ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-mixer: When setting hw volume, round always up with playback and always down with capture.
'Twas brillig, and David Henningsson at 16/05/11 07:23 did gyre and gimble: On 2011-05-15 16:45, Tanu Kaskinen wrote: On Sun, 2011-05-15 at 17:43 +0300, Tanu Kaskinen wrote: This was discussed on the mailing list: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-May/010091.html --- src/modules/alsa/alsa-mixer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c index f236da0..8375a2f 100644 --- a/src/modules/alsa/alsa-mixer.c +++ b/src/modules/alsa/alsa-mixer.c @@ -893,7 +893,7 @@ static int element_set_volume(pa_alsa_element *e, snd_mixer_t *m, const pa_chann if (e-has_dB) { long value = to_alsa_dB(f); -int rounding = value 0 ? -1 : +1; +int rounding = e-direction == PA_ALSA_DIRECTION_OUTPUT ? +1 : -1; if (e-volume_limit= 0 value (e-max_dB * 100)) value = e-max_dB * 100; David, are you happy with this change, or does this require more discussion? I think it's OK. I think your theory is at least as good as mine, so let's give it a try. For HDA Intel this does not make much of a difference as Playback almost always only goes up to 0 dB whereas Recording usually is above 0 dB (although not always). Cool. I'll have to try this out in my tree with Source Output volumes as I'm having a brain freeze as to whether or not this is the right way round for what I observed. If it's not working I'll post back with some numbers. Might be worth adding a comment referring to the discussion behind the reasoning though. Yeah, I think a comment would be wise when this goes in. I'll take care of it and report back sometime this week. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] multiseat and PulseAudio?
'Twas brillig, and Tomasz Chmielewski at 16/05/11 09:49 did gyre and gimble: On 16.05.2011 08:49, David Henningsson wrote: On 2011-05-14 17:46, Tomasz Chmielewski wrote: Traditionally, UNIX systems were supporting multiseat desktop sessions (i.e. multiple keyboards, video cards, monitors attached to one PC). According to: http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode What is wrong with system mode? Or with other words: if you run it that way on your desktop, then you are doing it the wrong way. What is the correct way to use PulseAudio with multiseat systems? Assuming there is also one sound card per seat, you should run one PulseAudio per seat, and as the user currently logged in to that seat. Exactly how to do that, i e set up access to the right sound card for the logged in user (with ConsoleKit etc) is beyond my knowledge though. I only have one sound card in the PC. It works fine when I start PulseAudio in the system mode, but according to documentation, this is unsupported, strongly discouraged and should only be used in some embedded setups. So I'd like to do it the right way - unfortunately, PulseAudio documentation does not explain how to setup PulseAudio with multiseat. Well in this evironment, I'd say that if you only have one card to be shared between the seats, then system wide mode is likely the right option. It's not nice generally because: 1. We cannot use SHM for memory transfer leading to more memcpy overhead. 2. One user can spy on the other user monitor their VOIP streams etc. 3. Module loading is disabled (for security) by default on system wide which IIRC affects hotplug etc. 4. There are some issues with Bluetooth permissions for BT devices (it can be configured of course but finding it is tricky - I've got mails flagged in my inbox to add this documentation at some point). And we don't test it particularly heavily, but all in all it should work fine (assuming you write your own init script and/or your distro does that for you). If I start PulseAudio in the user mode, only one user gets a sound card; the second one gets Dummy Output. Yeah, that's either because the second user does not have permission to access the device (due to ConsoleKit ACLs only the active (ck-list-sessions) user should get the ACL, but this could actually cover both users in your setup) or due to the fact that the card can only be opened once. Normally what you'd due is define some kind of udev magic that defines seats and thus contextually assigns certain USB ports and/or h/w to a given seat. Then when a user (any user - it's not tied to the seat) logs in, console-kit and udev both apply the right ACLs and PA can start and only show the relevant sound cards to the relevant seats. This is how it should work in an ideal world - everyone getting their own stuff. But in a situation where you accept all the problems listed above (things like security likely don't apply when people know each other :)) then system wide is fine. Hope that helps :) 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] multiseat and PulseAudio?
On 16.05.2011 11:37, Colin Guthrie wrote: Well in this evironment, I'd say that if you only have one card to be shared between the seats, then system wide mode is likely the right option. It's not nice generally because: 2. One user can spy on the other user monitor their VOIP streams etc. Since all users hear the same audio from loudspeakers, it's not a concern :) And we don't test it particularly heavily, but all in all it should work fine (assuming you write your own init script and/or your distro does that for you). Unfortunately, it does not work fine, and was a reason why I'm investigating running PulseAudio per-user. When I run it in system mode, it crashes (or exits? not sure). It's not something what happens very often - once every 3 days perhaps. But annoying (no music anymore, normal user can't start PA in system mode etc.). Since the documentation said I'm not likely to get any help when asking for system mode issues, I though I'm really doing something wrong and I should use it per-user. If I start PulseAudio in the user mode, only one user gets a sound card; the second one gets Dummy Output. Yeah, that's either because the second user does not have permission to access the device (due to ConsoleKit ACLs only the active (ck-list-sessions) user should get the ACL, but this could actually cover both users in your setup) or due to the fact that the card can only be opened once. Normally what you'd due is define some kind of udev magic that defines seats and thus contextually assigns certain USB ports and/or h/w to a given seat. Then when a user (any user - it's not tied to the seat) logs in, console-kit and udev both apply the right ACLs and PA can start and only show the relevant sound cards to the relevant seats. This is how it should work in an ideal world - everyone getting their own stuff. But in a situation where you accept all the problems listed above (things like security likely don't apply when people know each other :)) then system wide is fine. Hope that helps :) Well, the theory is nice :) but from user's perspective, sound with multiseat became unreliable when distributions migrated to PulseAudio (not that the life of a multiseat user was ever easy, but still, it's yet one thing which discourages multiseat). Perhaps I'll try to see why PA crashes/exits when used by multiple users in the system mode, report it to the mailing list, and hope won't get too many system mode is unsupported, go away replies ;) -- Tomasz Chmielewski http://wpkg.org ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] multiseat and PulseAudio?
Dnia 2011-05-16, pon o godzinie 10:51 +0200, Tomasz Chmielewski pisze: I only have one sound card for all users, so I guess your scripts wouldn't help much? No, for proper multiseat you need a card per user (note that might be USB speakers, too). I believe when you use a USB hub at each seat, you could have the speakers bound to seats using the hubs' bus-ids or similar. Cheers -- Michał Sawicz mic...@sawicz.net 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
[pulseaudio-discuss] [PACKAGERS] New dep
Hi, I've just pushed Arun's (mostly, Pierre-Louis also had a hand!) passthrough work to master. This carries with it a new dependency: json-c We may yet remove this and write our own parser for the simple subset of JSON formatting we use but there may ultimately be other reasons to keep this longer term. But in the interests of simplicity, I'd certainly not be against any native implementation patches that came along provided they were simple and clean. Please test these changes. I'm sure Arun will post more details and test requests in due course. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] multiseat and PulseAudio?
Op 16-5-2011 10:51, Tomasz Chmielewski schreef: On 16.05.2011 10:43, duportail wrote: Currently i use a script to set the users' default sink according the display he is on, because you do not know which user is logged in on which display. I only have one sound card for all users, so I guess your scripts wouldn't help much? I use a usb soundcard per display.I log in at each display to detect the sink of the usb soundcard that is for that display. Than a script to set the default sink per display, this script is called in the users' autostart function. If the user logs in, the script finds out what $DISPLAY and sets the default sink. The .pulse dir should be empty. I did some work regarding udev rules and consolekit stuff, but it is so difficult to re-configure remote systems if somehow a hub is broken or replaced on the computer. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] volume ramping
Hi, There used to be some test/sample code that did volume ramping on pulseaudio git source. Recently it has been taken out. Any idea as to why, the revert commits did not mention a reason. I've been testing it out and it seems stable, I did have to change some of the logic and code to get it working without glitches. Thanks Baek ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss