Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. That is the *right* way and the default way. If you want something different then you can but you'll have to get your hands a little dirty. 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] system-wide daemon
On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] voulme control
Hi all, I have soume problem to control audio volume. I am using: pa_cvolume a; a.channels = channels; a.values[0] = PA_VOLUME_MUTED; a.values[1] = PA_VOLUME_MUTED; if(pa_cvolume_valid(a)) qDebug() VALID; pa_cvolume_mute(a, channels); but volume remain set NORMAL why??? -- Ing. Gian Lorenzo Meocci http://www.meocci.it ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] voulme control
Hi Gian, For muting you could use pa_context_set_sink_mute_by_index ? To control volume, you need to set the volume on a pa_cvolume and then set the volume on the device with this struct. something like one sink_info* s (passed in) pa_volume_t new_volume = pa_sw_volume_from_linear(linear_input); pa_cvolume dev_vol; pa_cvolume_set(dev_vol, s-volume.channels, new_volume); pa_operation_unref(pa_context_set_sink_volume_by_index(pulse_context, s-index, dev_vol, NULL, NULL)); The docs on the wiki are pretty comprehensive about this. Conor On Tue, Feb 9, 2010 at 9:39 AM, Gian Lorenzo Meocci glmeo...@gmail.comwrote: Hi all, I have soume problem to control audio volume. I am using: pa_cvolume a; a.channels = channels; a.values[0] = PA_VOLUME_MUTED; a.values[1] = PA_VOLUME_MUTED; if(pa_cvolume_valid(a)) qDebug() VALID; pa_cvolume_mute(a, channels); but volume remain set NORMAL why??? -- Ing. Gian Lorenzo Meocci http://www.meocci.it ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
I think this is one area where PulseAudio could be improved, though I can't quite figure out how! Surely, there must be some way to allow specific processes or users to have full sound access, while otherwise sticking to the one-user-at-a-time model. I'm trying to port SBL (another console screen reader) to Ubuntu, now, and so I've got yet another piece of code that will need substantial changes to work with the one-user-at-a-time model, in addition to speechd-up, espeakup, and speech-dispatcher. Grr... Can't we just add the concept of an allowed user, who gets to play sound no matter who's logged in? Bill On Tue, Feb 9, 2010 at 3:43 AM, Markus Rechberger mrechber...@gmail.com wrote: On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 08:43 did gyre and gimble: On Tue, Feb 9, 2010 at 9:38 AM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 02:16 did gyre and gimble: On Tue, Feb 9, 2010 at 3:01 AM, olin.pulse@shivers.mail0.org wrote: Bill Cox: While the right way is not system-wide mode, in practice, I find system-wide mode to be very stable and usable on Ubuntu systems that have multiple users trying to send sound to the speakers. So, I'm still wondering: what *is* the right way for this use case? Is it the case that PulseAudio just doesn't address it? There is no right way pulseaudio was not designed to support multiple users at the same time (without the depreciated exception of running it as system wide daemon). Indeed. PA is principally meant to be run per-user. Each user logged in will have their own PA process running and each will monitor a system service called ConsoleKit which tracks which user is active. We adhere to whatever ConsoleKit tells us with regards to which user is currently active (see ck-list-sessions) and only the active user has access to the sound hardware. Think about how switching users works (on Linux and on Windows/OSX). Only the user whose desktop is currently presented will be allowed to use sound, the other user's sound is corked until they become active again. Bad example as usual, on OSX everyone (who's permitted to use the audio unit) can just log in and use the audio unit. Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. This is *exactly* the same behaviour as we promote in PulseAudio too. If you can show me something that proves the above invalid, I'm all ears, but I'm pretty confident that what I said originally is correct and the above test seems to support that. 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] system-wide daemon
Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. maybe iTunes is requesting this, but then hey this option would be on enduser application level and not at audio stack level. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. This is *exactly* the same behaviour as we promote in PulseAudio too. unfortunately I can not confirm this with iTunes either... I tested this with OSX 10.4 and OSX 10.5. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote: snip 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. snip using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. snip Am I the only one who sees a bit of a difference between what you and Colin are testing? He's testing fast user switching on the same machine and you're testing remote logins? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 4:44 PM, Ng Oon-Ee ngoo...@gmail.com wrote: On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote: snip 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. snip using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. snip Am I the only one who sees a bit of a difference between what you and Colin are testing? He's testing fast user switching on the same machine and you're testing remote logins? no you are right but all together it's only about multiuser audio support. I never tested fast user switching, but for this it might make sence to lock the audio stack even though the corking mechanism is coordinated on app client level and not on stack/userlogin level. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. I guess the only other really nasty e-mails I read about PA are due to old unmaintained code (typically games) that have too much delay in PA. Is there any good reason that the default latency in PA for programs that don't bother setting a desired latency is greater than zero? Bill On Tue, Feb 9, 2010 at 10:49 AM, Markus Rechberger mrechber...@gmail.com wrote: On Tue, Feb 9, 2010 at 4:44 PM, Ng Oon-Ee ngoo...@gmail.com wrote: On Tue, 2010-02-09 at 15:52 +0100, Markus Rechberger wrote: snip 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. snip using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. snip Am I the only one who sees a bit of a difference between what you and Colin are testing? He's testing fast user switching on the same machine and you're testing remote logins? no you are right but all together it's only about multiuser audio support. I never tested fast user switching, but for this it might make sence to lock the audio stack even though the corking mechanism is coordinated on app client level and not on stack/userlogin level. Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox waywardg...@gmail.com wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. you cannot compare it with mac, on mac multiuser access works like it worked with alsa and OSS. The only point is that this behavior should be considered to be fixed up again in future. I would not wonder if a remote login in windows as a different permitted user would provide audio support. I do agree that when the user behind the PC is switched that those audio instances should be exclusive. But remote terminals are a different topic and should be handled different. the problem I see with that design is that as soon as the user logs out the PA process might vanish again so you are really stuck with the system daemon if you want to get multiuser support. although another possibility might that other PA daemons connect to the first PA instance and just pass through the first instance might do some user accounting and only shut down when all other PA instances are gone but in that case the system wide mode seems to be more elegant again... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
They way I worked out a similar situation (I am doing an ssh from the box into the box and sometimes from a different box into it) was to setup the PA of the user I ssh as and it IS a user that I would never login directly as to use PA over the network. So as long as someone is logged in then it's PA works. You could have a couple of different configurations sitting around and do some shell trickery and start different configurations depending on the environment. Does PA support conditional config files? Maybe it can be all kept in the PA file and just set an environment variable. Fred F On Tue, Feb 9, 2010 at 11:59 AM, Markus Rechberger mrechber...@gmail.comwrote: On Tue, Feb 9, 2010 at 5:17 PM, Bill Cox waywardg...@gmail.com wrote: The corking stuff in PA is very cool. I don't think anyone objects to it. But couldn't we quell all the PA stinks! posts by just allowing some processes/groups/users to have constant access to audio? Comparisons to MAC and Windows have been going on for a while, and the PA guys are basically right that PA is more like Windows and Mac than the older sound systems. If I'm not mistaken, the real issue is all the very valid reasons people out in Linux land have for multi-user simultaneous access to sound. I'd say those guys are generating most of the negative PA e-mails I read, and not just on this forum. you cannot compare it with mac, on mac multiuser access works like it worked with alsa and OSS. The only point is that this behavior should be considered to be fixed up again in future. I would not wonder if a remote login in windows as a different permitted user would provide audio support. I do agree that when the user behind the PC is switched that those audio instances should be exclusive. But remote terminals are a different topic and should be handled different. the problem I see with that design is that as soon as the user logs out the PA process might vanish again so you are really stuck with the system daemon if you want to get multiuser support. although another possibility might that other PA daemons connect to the first PA instance and just pass through the first instance might do some user accounting and only shut down when all other PA instances are gone but in that case the system wide mode seems to be more elegant again... Markus ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On 9 Feb 2010, olin verbalised: OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. The model is 'the person at the console is the person near the speakers and thus the person who should get sound output when requested'. This doesn't seem like a terribly unrealistic model to me. How many computers do you know of which have speakers in a completely different place to the keyboard and screen? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble: Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. This is a totally different scenario to what we were discussing. Please try to keep this discussion on topic rather than twisting it to suit your particular bugbear. We've discussed to death the the technical reasons why *simultaneous* output from multiple users is not supported and I've shown by example that this is the exact same basic behaviour as on OSX with regards to multiple users. You've taken a different example showing that for some bizarre reason, a user (root or otherwise) is permitted access to the sound hardware on OSX. If this is possible (and I have no reason to doubt you) then this is simply something that I would argue very strongly *against* wanting to support in PA. A random SSH user should *never* have access to various h/w devices on my machine. A security model that supports this is broken IMHO, regardless of the 0.01% of niche cases where people would like to use it. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. maybe iTunes is requesting this, but then hey this option would be on enduser application level and not at audio stack level. iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. This is *exactly* the same behaviour as we promote in PulseAudio too. unfortunately I can not confirm this with iTunes either... I tested this with OSX 10.4 and OSX 10.5. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can eavesdrop on all your VoIP connections??? No thank you. At all user facing levels, for the 99.9% use case of desktop users, we behave exactly the same as OSX. In the niche case of SSH user logging in, we DO NOT support the SSH user having control of our sound hardware, and for good reason. If you wanted this second senario to be supported you would have to: 1) Convince the people in charge that this is a good idea. 2) Design a new layer that runs as a system service and takes exclusive control of the physical sound h/w. This would have to support the PA glitch-free driving mechanism. 3) Define a method of authenticating users to access
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and olin.pulse@shivers.mail0.org at 09/02/10 00:11 did gyre and gimble: OK, so that's X11. I cannot figure out what PA's mechanism for this is. I sort of get the sense, from this per-user-login server model that PA has the horrible one-persone/one-computer model of the person at the console is the person using the computer, which was inflicted on the world by Microsoft Windows. If so, this is a real design error, one that doesn't sync up with Unix, which has always had a multi-user model of the world. For X11, PA will follow where the physical *person* is. Even if the App itself is running remotely, the user is seeing the app on a local screen. And PA supports exactly the same principle but for sound. Even tho' the App is running remotely, any sound it produces is heard *locally*, not remotely. There is nothing wrong with me logging into my colleagues machine and running e.g. RhythmnBox on his machine. He currently has full, exclusive access to his machine's sound hardware, but by virtue of my local machine running PA and his machine being configured for PA output from applications, I just SSH in and run the application and the sound it produces and the display it draws are both heard/seen on *my* computer. It does not interfere with his computer in any way (other than using some CPU cycles!) and I never even ask to use his sound h/w. I've written about the various X11 scenarios here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/ perhaps that'll help explain things a bit. 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] system-wide daemon
On Tue, Feb 9, 2010 at 6:54 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 14:52 did gyre and gimble: Can you demonstrate this? In the past when I've tested this behaviour on OSX (it was quite a while ago) it behaves exactly as I described above, and I've literally just now re-tested this on a colleagues Mac (latest version): 1. Enable Fast User Switching (System Settings - Accounts - Login Options). 2. Login as user. 3. Fast user switch (top right, next to clock) to a different user. 4. With new user download and run e.g. VLC or iTunes. 5. Start playing some tunes. 6. Fast user switch back to your original user. 7. Note the blissful silence. 8. Do whatever you like with the original user login. Play tunes, check mail etc. 9. Switch back to the user who *was* playing. 10. If you used iTunes, it will now be in the Pause state so will be quiet. If you used VLC the music will continue playing now the user is active again. 1. default Mac from a company 2. open a terminal and play an mp3 with mplayer as normal user 3. going to another PC and logging in with ssh (as root) and playing an mp3 ) -- works 4. again going to another PC and in order you cannot blame it on login as root I added another user and played back another mp3 -- it worked too in any case 2 different users were playing back the mp3. This is a totally different scenario to what we were discussing. Please try to keep this discussion on topic rather than twisting it to suit your particular bugbear. We've discussed to death the the technical reasons why *simultaneous* output from multiple users is not supported and I've shown by example that this is the exact same basic behaviour as on OSX with regards to multiple users. You've taken a different example showing that for some bizarre reason, a user (root or otherwise) is permitted access to the sound hardware on OSX. If this is possible (and I have no reason to doubt you) then this is simply something that I would argue very strongly *against* wanting to support in PA. A random SSH user should *never* have access to various h/w devices on my machine. A security model that supports this is broken IMHO, regardless of the 0.01% of niche cases where people would like to use it. I guess the reason there is a difference between iTunes and VLC is that iTunes presumably listens to the cork notifications from CoreAudio and issues an application level pause, whereas VLC does not and thus is forcibly corked, but will automatically play again. maybe iTunes is requesting this, but then hey this option would be on enduser application level and not at audio stack level. iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). something must tell the app to 'cork' in OSX but it it no hard requirement. By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. well something must have told iTunes to pause, but it definitely was not the audio stack which forced iTunes to stop or be silent. Sending a notification to the App that it should go into a corking mode (if requested by the app) would be better. This is *exactly* the same behaviour as we promote in PulseAudio too. unfortunately I can not confirm this with iTunes either... I tested this with OSX 10.4 and OSX 10.5. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble: iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). something must tell the app to 'cork' in OSX but it it no hard requirement. It's not the app that corks. The app's audio stream is corked for it and the app is told about this. The app does not have any choice in the matter. By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. The audio group is a legacy and is no longer needed. ACLs on the audio device are far more flexible. Also this only controls *physical* access to the device nodes which requires hardware mixing support to actually drive independently. Most sound hardware does NOT support hardware mixing. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. well something must have told iTunes to pause, but it definitely was not the audio stack which forced iTunes to stop or be silent. Yes it was. iTunes mearly paused itself because that made sense from a UI perspective. The sound system didn't say Pretty please stop playing or I'll cry and cry and cry, it basically held it's hand over it's mouth and said this will be a whole lot easier if you don't scream. Sending a notification to the App that it should go into a corking mode (if requested by the app) would be better. No it wouldn't. Corking is done by the sound system, not by the apps. If all apps *had* to implement corking support, then we'd have to reimplment *all* apps sound systems. That doesn't make any sense and besides, it's not a preference or a nice to have, it's a dictatorship-driven you have had your rights removed system. This isn't something that is specific to PA, it's lower down the stack in console kit. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can eavesdrop on all your VoIP connections??? No thank you. of course people will capture the audio device, this is a scenario which is 99.9% unlikely. Yeah you're right, noone would ever be that nasty. Maybe you got hacked that way in the past and that's your experience, I have never seen someone hacking a system like that. Nah, you're right, no one will ever think of doing it and even if they did there are probably less than a thousand different ways they could exploit this right? Hardly worth bothering about!! But imagine even worse people who are in the videogroup are able to enable the webcam! Doh! Incase you didn't realise the above two comments were sarcastic... your point is exactly correct tho'. I don't want any other user to be able to view my webcam! That's why the groups are no longer used for device access!!! ACLs controlled by console-kit are what permits a given user access ot the webcam on any half-way modern desktop. That's the whole point!!! Do not have any users in the video group, do not have any users in the audio group. In fact I'd go the whole hog and remove those groups completely!! If someone writes down his password and pins it onto the wall the hacker might know all the passwords - what a terrible scenario! I don't disagree I'm not entirely sure what your point in relation to this discussion is tho'. How about a FM USB Transceiver which uses UAC (USB Audio Class) Why the heck should only the person sitting infront of it be allowed to use it The person sitting infront of it could listen to audio while another one could transmit audio (I do have such an engineering sample here). So you transmit something in
Re: [pulseaudio-discuss] voulme control
Hi, To control volume, you need to set the volume on a pa_cvolume and then set the volume on the device with this struct. something like one sink_info* s (passed in) pa_volume_t new_volume = pa_sw_volume_from_linear(linear_input); pa_cvolume dev_vol; pa_cvolume_set(dev_vol, s-volume.channels, new_volume); pa_operation_unref(pa_context_set_sink_volume_by_index(pulse_context, s-index, dev_vol, NULL, NULL)); I am using simple api. This is a problem? Because I don't have a pulse_context. Sorry but I am new about pulseaudio :) thanks a lot -- GL ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] voulme control
ti, 2010-02-09 kello 19:55 +0100, Gian Lorenzo Meocci kirjoitti: I am using simple api. This is a problem? You can't do volume control with the simple API. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Tue, Feb 9, 2010 at 7:51 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Markus Rechberger at 09/02/10 18:25 did gyre and gimble: iTunes *requests* nothing. It simply *adheres* to what it has been told is happening. The same would be true of any application that listens to the PulseAudio generated cork notifications (IOW what iTunes and VLC are doing is nigh on identical to what a native PA client can do - i.e. a PA client that listens for and takes action on cork notifications will behave like iTunes, one that doesn't have any specific support for corking will behave like VLC). something must tell the app to 'cork' in OSX but it it no hard requirement. It's not the app that corks. The app's audio stream is corked for it and the app is told about this. The app does not have any choice in the matter. By the way normally only the users who are in the audio group are allowed to access audio (not entirely sure how this is handled with osx though), so it's not like a random user is allowed to access the audio device. The audio group is a legacy and is no longer needed. ACLs on the audio device are far more flexible. Also this only controls *physical* access to the device nodes which requires hardware mixing support to actually drive independently. Most sound hardware does NOT support hardware mixing. Seen from my side setting this option (the possibility to lock audio to one user) on App level instead of Stack level this would be much better. No idea what you mean here, but if you are think that I was suggesting some kind of iTunes is more capable than VLC then that's not really what I'm saying. Both are subject to exactly the same restrictions, it's just that iTunes presents it to the user by pausing itself and VLC does not. If iTunes had not paused itself it still would not have been able to output audio - the core fact does not change - it's simply dealing with the you are barred from producing audio signal that CoreAudio generated in a more user friendly way. well something must have told iTunes to pause, but it definitely was not the audio stack which forced iTunes to stop or be silent. Yes it was. iTunes mearly paused itself because that made sense from a UI perspective. The sound system didn't say Pretty please stop playing or I'll cry and cry and cry, it basically held it's hand over it's mouth and said this will be a whole lot easier if you don't scream. Sending a notification to the App that it should go into a corking mode (if requested by the app) would be better. No it wouldn't. Corking is done by the sound system, not by the apps. If all apps *had* to implement corking support, then we'd have to reimplment *all* apps sound systems. That doesn't make any sense and besides, it's not a preference or a nice to have, it's a dictatorship-driven you have had your rights removed system. This isn't something that is specific to PA, it's lower down the stack in console kit. using iTunes and logging in remotely also worked - including audio playback. I can make a video of this if you don't believe it heh. It doesn't matter if I believe it or not, the fact is that this part of the model is fundamentally broken and insecure. I mean someone roots your machine (running as nobody or apache via some week vuln in something or other) and all of a sudden they can eavesdrop on all your VoIP connections??? No thank you. of course people will capture the audio device, this is a scenario which is 99.9% unlikely. Yeah you're right, noone would ever be that nasty. Maybe you got hacked that way in the past and that's your experience, I have never seen someone hacking a system like that. Nah, you're right, no one will ever think of doing it and even if they did there are probably less than a thousand different ways they could exploit this right? Hardly worth bothering about!! But imagine even worse people who are in the videogroup are able to enable the webcam! Doh! Incase you didn't realise the above two comments were sarcastic... your point is exactly correct tho'. I don't want any other user to be able to view my webcam! That's why the groups are no longer used for device access!!! ACLs controlled by console-kit are what permits a given user access ot the webcam on any half-way modern desktop. That's the whole point!!! Do not have any users in the video group, do not have any users in the audio group. In fact I'd go the whole hog and remove those groups completely!! If someone writes down his password and pins it onto the wall the hacker might know all the passwords - what a terrible scenario! I don't disagree I'm not entirely sure what your point in relation to this discussion is tho'. How about a FM USB Transceiver which uses UAC (USB Audio Class) Why the heck should only the person sitting infront of it be allowed to use it The person sitting infront of it could listen to audio while
Re: [pulseaudio-discuss] voulme control
thanks :) On Tue, Feb 9, 2010 at 8:06 PM, Tanu Kaskinen ta...@iki.fi wrote: ti, 2010-02-09 kello 19:55 +0100, Gian Lorenzo Meocci kirjoitti: I am using simple api. This is a problem? You can't do volume control with the simple API. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- Ing. Gian Lorenzo Meocci http://www.meocci.it ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Markus Rechberger at 09/02/10 19:07 did gyre and gimble: How about a FM USB Transceiver which uses UAC (USB Audio Class) Why the heck should only the person sitting infront of it be allowed to use it The person sitting infront of it could listen to audio while another one could transmit audio (I do have such an engineering sample here). So you transmit something in the clear and you are suprised that someone hijacks your data? Again the relevance to this discussion is lost on me I'm afraid. the user sitting infront of it could listen to FM radio, while another one is using the FM Transmit (line-out) unit. In your scenario such devices do not exist and are prohibited. If this is how the device is designed to be used, then it should present itself as two separate devices to the kernel and appropriate ACLs could be placed on each to allow different users to access it simultaneously. I see your 'designed' way just as a valid usecase as my one (which basically was requested multiple times by multiple people already). Personally I don't. The active user has control of the sound hardware. If the machine is inactive then a pseudo session can be registered (i.e. in the case of gdm login). If the active user (be it a real user or gdm) decides he wants the audio from the lower level system then they should configure their system to recieve the audio via some kind of controlled IPC mechinism and play it back accordingly. Bypassing this layer and accessing things directly is not IMO a good design. Everything is possible with the appropriate mechanisms in place and no functionality is sacrificed, but you have to be prepared to accept that old approaches will not last forever nor survive the tests of time. your scenario is definitely over engineered for many people out there. I wouldn't call this overdesign. Quite the opposite. Yes to get this rather bizarre scenario working it would be complex, but to make it work out of the box in this way in PA itself is far from simple. I've already listed the 5 relevant points that would need addressing for this to work and there are significant design hurdles to overcome there. That is what I would consider overdesign - doing something very complex to support a pretty niche use case. 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] system-wide daemon
'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble: On Tue, Feb 9, 2010 at 09:41, Tanu Kaskinen ta...@iki.fi mailto:ta...@iki.fi wrote: That's easier said than done. Only one process can have direct access to the sound card at a time. Each user has his own pulseaudio instance running. How do you implement constant access in such scenario? I fear it would require a major redesign effort in pulseaudio. I haven't seen any concrete design proposals enabling simultaneous access for multiple users while at the same time retaining all the desirable properties that the current system has. Off the top of my head root or other system-level pulseaudio instance opens and owns the physical hardware for the entire time a computer is up. All the user pulseaudio instances connect through that. What's the downside here? Mainly due to latencies resulting from the IPC mechanism. Currently PA operates a zero-copy core, but this would likely introduce data copying. Also user access would then have to be governed by the PA process. Which user is allowed to access it and for which devices. Console-kit integration could be used to say which users are active, so we could authenticate that way in some capacity but how do you implement multi-seat device allocation with a single PA process? There are likely many other problems too but you'll probably have to wait for Lennarts comments to get a full picture. Alternatively, rely on the underlying layer to do multiplexing. If the hardware supports it, awesome. If it doesn't, let dmix handle it. Dmix is very smart but it does not support the power saving features possible in PA. This whole thing has been discussed to death, and I really don't feel like being drawn into the whole thing again. 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] system-wide daemon
Dnia 2010-02-09, wto o godzinie 19:31 +, Colin Guthrie pisze: I wouldn't call this overdesign. Quite the opposite. Yes to get this rather bizarre scenario working it would be complex, but to make it work out of the box in this way in PA itself is far from simple. I've already listed the 5 relevant points that would need addressing for this to work and there are significant design hurdles to overcome there. That is what I would consider overdesign - doing something very complex to support a pretty niche use case. It might drop in the same 'overdesigned' category, but maybe it would be possible to create a scenario where: 1. remote user or a daemon wants to play audio 2. PA looks for an active user session on local PC 3. the remote user's PA tries to connect (over native protocol) to the active user session 4. there's a dialog on the active user's session with 'User tries to access your audio equipment with application , allow / deny?' 5. if the active user agrees, the remote user is able to play, otherwise it remains corked until the active user changes or allows the stream to play. This would also simplify how remote tunnels are created - now you can either turn off authentication or hack the config file to only allow certain Oh, and apart from VoIP calls being eavesdropped, if someone hacks in and has access to the hardware he can hear _everything_ that is said near the microphone. Big problem. Not even root should be able to do that. -- Cheers Michał (Saviq) Sawicz signature.asc Description: To jest część wiadomości podpisana cyfrowo ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and Michał Sawicz at 09/02/10 20:57 did gyre and gimble: Dnia 2010-02-09, wto o godzinie 19:31 +, Colin Guthrie pisze: I wouldn't call this overdesign. Quite the opposite. Yes to get this rather bizarre scenario working it would be complex, but to make it work out of the box in this way in PA itself is far from simple. I've already listed the 5 relevant points that would need addressing for this to work and there are significant design hurdles to overcome there. That is what I would consider overdesign - doing something very complex to support a pretty niche use case. It might drop in the same 'overdesigned' category, but maybe it would be possible to create a scenario where: 1. remote user or a daemon wants to play audio 2. PA looks for an active user session on local PC 3. the remote user's PA tries to connect (over native protocol) to the active user session 4. there's a dialog on the active user's session with 'User tries to access your audio equipment with application , allow / deny?' 5. if the active user agrees, the remote user is able to play, otherwise it remains corked until the active user changes or allows the stream to play. This would also simplify how remote tunnels are created - now you can either turn off authentication or hack the config file to only allow certain This is possible but not with the current structure. Until the authentication is successful, there can be no stream and thus it cannot be corked... but the principle is not all bad and with luck the notification framework I'll eventually commit will help with part of this approach should it be undertaken. That said, I'm not sure the complications resulting from this approach are really worth the benefits. I think we should concentrate on getting the typical use cases working as near to perfect as possible before devoting too much time on rather more exotic multi-user interaction scenarios. Oh, and apart from VoIP calls being eavesdropped, if someone hacks in and has access to the hardware he can hear _everything_ that is said near the microphone. Big problem. Not even root should be able to do that. Couldn't agree more :) -- 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] system-wide daemon
Colin Guthrie wrote: 'Twas brillig, and Jeremy Nickurak at 09/02/10 19:24 did gyre and gimble: This whole thing has been discussed to death, and I really don't feel like being drawn into the whole thing again. From what I've read here, I'm afraid it's going to keep coming up until we solve it somehow. There are just too many people for where the ordinary PA setup (all soundcards are of exclusive use to the person logged into the current X session) is not acceptable, and worse, it isn't easy for them to either reconfigure PA, or replace PA, with something that suits their needs. I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio Let's hope we can get something constructive out of this, and I'm hopeful we can solve those people's problems, without sacrificing latency, power usage or security. // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. 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
[pulseaudio-discuss] Behavior of pa_threaded_mainloop_wait ()
I have a stream state change callback that fires a signal when the stream is
PA_STREAM_READY, PA_STREAM_FAILED, or PA_STREAM_TERMINATED
When trying to get a ready stream state in pulseaudio, I first wrote this. This
hangs
do {
stream_state = pa_stream_get_state (device.stream);
if (! PA_STREAM_IS_GOOD (stream_state))
{
error_number = pa_context_errno (device.context);
fprintf (stderr, Could not acquire PulseAudio stream: %s\n,
pa_strerror (error_number));
return;
}
else
{
fprintf (stderr, PulseAudio stream state is %d.\n,
stream_state);
}
pa_threaded_mainloop_wait (device.mainloop);
} while (stream_state != PA_STREAM_READY);
Then I wrote this, based on the pa_simple code, and this doesn't hang
stream_state = pa_stream_get_state (device.stream);
while (stream_state != PA_STREAM_READY)
{
stream_state = pa_stream_get_state (device.stream);
if (! PA_STREAM_IS_GOOD (stream_state))
{
error_number = pa_context_errno (device.context);
fprintf (stderr, Could not acquire PulseAudio stream: %s\n,
pa_strerror (error_number));
return;
}
else if (stream_state == PA_STREAM_READY)
break;
else
fprintf (stderr, PulseAudio stream state is %d.\n,
stream_state);
pa_threaded_mainloop_wait (device.mainloop);
}
Why do I have to explicitly check inside the loop to see if the stream is
ready, and then break? Do I have to have called wait() while the callback
executes?
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. Right, this would make sense for some use cases as well and worth considering. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] system-wide daemon
On Wed, Feb 10, 2010 at 7:14 AM, David Henningsson launchpad@epost.diwic.se wrote: Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 09/02/10 21:52 did gyre and gimble: I wrote down a few use cases here, I'm sure there are more: https://wiki.ubuntu.com/BluePrints/multiuser-soundcards-pulseaudio For user Foo, the sound card sounds like it's dedicated for Foo. If this is the case the a udev rule should be written to ensure that only Foo has ACL rights on this file and any console-kit udev-acl callouts are ignored. That makes sense, thanks. I added that reply to the blueprint. For user Bar, I feel this is invalid. Why should user Bar have the right to output a sound any more than he has the right to display a popup window on my desktop? Here's another analogy; what about the printer? If printers were considered a part of the seat, then user Bar wouldn't have more right to print a document either. (The corresponding spy-on-mic analogy would be that someone puts a document in a scanner and another user scans it...) But printers are more of a system-wide resource, and for some use cases, so is the soundcard. And then, sharing makes sense. If another user is allowed to print a document while I'm logged in, why shouldn't he be able to play a sound? So would then the solution be to run PA as a system-wide daemon, and possibly assign soundcards to it via udev? Also imagine TV tuners, webcams are basically handled the same way. One user might want to capture a TV movie, while the other one doesn't need access to it. The ck assignment would not be valid for this. Now imagine we have a DVB device, multiple users can access the same TV channel. While another user might stream or capture the TV content the user sitting behind the PC might watch the current tuned in TV channel. This is a not so unlikely scenario with our devices. This is also just another example where the MS-DOS like single user scenario does not fit. Best Regards, Markus If either scenario is to be supported, then what I suggested elsewhere in this thread is still valid I reckon. i.e something needs to be run as the active user that acts as an agent for some kind of (system?) service that actually generates said alarm. The agent will be running as the active user and it will be responsible for playing the sound/displaying the popup. Right, this would make sense for some use cases as well and worth considering. As for multi-seat, this is already in hand. Console-Kit has support for multi-seat stuff (tho' it may not be complete - I'm not overly sure here). What may still remain to be done is to tag certain devices as being for particular seats so that console-kit/udev can apply the appropriate ACLs when the set becomes active for a given user. All the multi-seat stuff is below PA tho' We'll just honour what it tells us. I don't think we don't need to add specific support for it. And the way ck/udev tells PA what devices it can use, is through device permissions? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
