Re: [pulseaudio-discuss] Multiple users (kde) on Debian
Colin Guthrie schrob: As we discussed previously the pseudo session started for the GDM login prompt is the right approach here. There is always an active user, No!!! None of what you said above causes me to doubt the approach we have all previously discussed. The architecture is wrong. Provide a *single* system service that does all the work. Do not run several instances of it for each user or login shell. In the pseudo sessions or real user sessions, run an *agent* that is the lightweight layer that connects to the system process and does the sound output. This way you get *user specific* settings. FWIW, I agree that's the best aproach. But aren't you PA guys actively fighting this idea? You strongly advise against system mode. PA tightly couples per-user settings and per-system hw access, making such an agent difficult to write[1]. I'm seriously confused as to whether you're telling Halim here you need more effort than just dmix or in fact PA is not (and won't ever be) for you. regards, Jan [1] See e.g. https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-July/007588.html -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ 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 schrob: 'Twas brillig, and Jan Braun at 25/08/10 12:08 did gyre and gimble: Colin Guthrie schrob: FWIW, I agree that's the best aproach. But aren't you PA guys actively fighting this idea? You strongly advise against system mode. No, you're misunderstanding what I'm suggesting. I'm not referring to PA, I'm talking about your speech system. Oh, I see, sorry for that. Please scratch my previous mail then. Your systems should be split cleanly so that they provide a single system wide service that gathers all the necessary information (i.e. what is on screen to go via tts), but they should *not* actually play the speech they generate, but rather *make it available* to whomever wants to consume it. Users (or pseudo users) will run lightweight agents which can connect to this system-wide resource and play it accordingly. So what you want is an audio-broadcast-server, which can be used as an audio sink for the TTS, and several audio-broadcast-clients, which receive the broadcast and play it to their local PA instance? (AFAICS there's nothing to gain by tightly integrating audio-broadcast-server into the tts, and there'll be use cases besides tts for it, e.g. me playing music) Sounds workable, as long as you don't care about zero-copy. Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] and the winner is dmix
Hi, Halim Sahin schrob: 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. Yep, but maybe CK isn't such a good police^Hy. +1 if ck really doesn't support plain texconsole logins. I don't know whether it does, and didn't want to imply it doesn't. (And I don't care much. ck-list-sessions lists nothing for me even in X ;) I was merely objecting to treating sound output as an one user at a time only resource. Alsa supports[1] one application playing audio at a time. NACK. Alsa can do softmixing as well with it's dmix plugin. I know about dmix. However, it can't adjust the relative volume of multiple streams (at least I couldn't get it to). I consider that ability essential for actually using sw mixing. Hence: [1] for demanding interpretations of support ...and that's why I'm using PA :) Cheers, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] cmipci, pulseaudio and 5.1 — unable to contol center/LFE
Erik Boritsch schrob:
I have a CM8738-MC6 soundcard with 5.1 analog surround. With pulseaudios
5.1 profile I am unable to control center and LFE channels.
[...]
In my case, it seems that center/LFE are on hw:1,1 (with other channels
being on hw:1,0). I have tried adding followings to .asoundrc:
[...]
With this config I can control volume for all the channels
simultaneously in alsa using the Softmaster control.
However, I am lost about how can I make this work in pulseaudio.
I can edit analog-output.conf.common to make pulseaudio control
SoftMaster, but this control doesn't affect sounds routed through
pulseaudio.
(Warning: I'm just guessing here...)
By default, PA finds soundcards via module-{udev-|hal-|}detect, which
probably will pick up your physical card rather than the alsa !default.
So you might try something like
| load-module module-alsa-sink device=softvol
in default.pa to make PA use the softvol device.
Alternatively, you could try to duplicate the alsa config by following
http://www.pulseaudio.org/wiki/FAQ#CanIusePulseAudiotocombinetwostereosoundcardsintoavirtualsurroundsoundcard
HTH,
Jan
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
signature.asc
Description: Digital signature
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Volume control interactions
Tanu Kaskinen schrob: On Sun, 2010-08-15 at 21:32 +0200, Jan Braun wrote: What I'd want and expect is a (per-soundcard) master volume that's persistent and affects ALL streams on that device, [...] Yes, your master volume is the reference volume. And the UI logic has been changed after that message you linked - nowadays the UI shows the reference volume. Terminology wise, virtual volume has been renamed to real volume (due to the fact that the volume reflects the hardware volume that the device actually uses). The real volume is not visible to users unless they use e.g. alsamixer to check what's happening. Ah, thanks. I tested, and it does indeed seem to work as described. Sorry for not re-testing before sending my mail, I remembered different behaviour. Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ 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 schrob: Also most people expect to get exclusive access ot the sound h/w when switching users (it's how it works on Windows and Mac OS) While fiddling with a relative's computer today, I was surprised to find out the technical assertion is not true. The 32-bit XP Home Personal installation on it had vlc happily continuing audio playback on one user account while I was fast-user-switched to a different (admin) account. Sigh, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ 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
Ng Oon-Ee schrob: On Wed, 2010-08-11 at 00:51 +0200, Jan Braun wrote: Colin Guthrie schrob: Also most people expect to get exclusive access ot the sound h/w when switching users (it's how it works on Windows and Mac OS) While fiddling with a relative's computer today, I was surprised to find out the technical assertion is not true. The 32-bit XP Home Personal installation on it had vlc happily continuing audio playback on one user account while I was fast-user-switched to a different (admin) account. I believe the statement was made with reference to Windows Vista/7, which actually HAS some security features, instead of the oh, every process is allowed to do everything approach of XP. That approach surely did not prevent quite a lot of A program is doing something, allow it?-prompts, even when logged in as admin. ;) But even if Vista/7 don't allow simultaneous audio access by different users anymore, this still makes a point for allowing simultaneous access is the logical behaviour (but MS couldn't get the security right and had to backpedal). Well, since at this point I'm mostly repeating myself, I'll shut up until I'm ready to code. Sorry for the noise. Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] How to Use a Tunnel Source
Jim Duda schrob: If I open PulseAudioManger on host jim, I can seet that I have a source which is identified as tunnel.asterisk.local.sphinx_record.monitor. I want my application to attach to this source, however, my application can only use ALSA. As such, I assumed I need to use the pulseaudio alsa plugin. What do I need to put into my .asoundrc file in order to address tunnel.asterisk.local.sphinx_record.monitor? You don't specify the exact PA sink/source in .asoundrc, you just specify use pulse there. See http://www.pulseaudio.org/wiki/PerfectSetup#ALSAApplications Then your alsa app should connect to pulse, and you use pavucontrol (or possibly your PulseAudioManger) to move its stream to the tunnel... source. If you have module-stream-restore loaded, it'll remember that source for future invocations of your app. HTH, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Colin Guthrie schrob: 'Twas brillig, and Jan Braun at 15/07/10 06:07 did gyre and gimble: 1. Shouldn't PA do only obvious things automatically, and not bug the user about obvious things? The proposition PA automaticallly breaks stuff, so it needs to show the user how to unbreak it seems flawed. Depends on your definition. I'm a firm believer of doing the right thing automatically and if you can't work out what the right thing is, then don't do it at all. But when it does do something automatically, I'd quite like to be informed about it. This already happens on KDE with their Phonon system, so it's not unprecedented, but all the same it may not be liked by Gnomey folk. But hey, it will be optional. Ok, sonds reasonable. (Except for the assertion PA users = KDE xor Gnome. Grr. :) 2. Isn't PA a daemon and thus can't interact with the user? Or did you mean set a flag that pavucontrol etc. can read? But then the user still would have to run pavucontrol on their own... [...] It would be pretty trivial to load a notification module in the start-pulseaudio-x11 script and this was my intention. True, thanks. If you can't tell, I'm concerned about PA not staying out of my way. It'll be a module, so it will be optional. Yep. And being conditional on start-pulseaudio-x11 makes it stay out of my way automatically. Thanks! :D Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Colin Guthrie schrob: 'Twas brillig, and Jeremy Nickurak at 16/06/10 16:04 did gyre and gimble: Does pulseaudio perhaps need to be throwing some visual indication to the user that streams switched devices as a result of a plug event, maybe with a very simple pointer to where to go to fix things? I've got plans for that too even a git branch, but at present it's not overly easy as PA modules cannot integrate with the glib main loop too easily... Huh? Sorry for possibly being dense, but 1. Shouldn't PA do only obvious things automatically, and not bug the user about obvious things? The proposition PA automaticallly breaks stuff, so it needs to show the user how to unbreak it seems flawed. 2. Isn't PA a daemon and thus can't interact with the user? Or did you mean set a flag that pavucontrol etc. can read? But then the user still would have to run pavucontrol on their own... If you can't tell, I'm concerned about PA not staying out of my way. regards, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Changing default soundcard on attach/detach of soundcards
Colin Guthrie schrob: e.g. when a new BT Headset is discovered, module-intended-roles would basically check to see whether the device is already in the voip priority list and if not, it would inject it at the top, rather than the bottom of the list (there could be various caveats included in this logic). That means the new BT headset gets priority over the old Headset. I wouldn't want that. In fact, my voip priority list would look like this: Old Headset use default/non-voip priority list and the new BT headset should add itself to the bottom, just before use default priority list. Not sure if that's an important scenario, but I thought I'd throw out the notion of incomplete priority lists. Otherwise it would do nothing and the default behaviour would ultimately be triggered and put new devices at the end of any priority lists. Obviously, in my scenario, the default behaviour would be to put new devices at the end of the default priority list only. 'Twas brillig, and Jason Taylor at 16/06/10 00:58 did gyre and gimble: I want to be able to tell my sister that all she has to do to use her headset is plug it in. If she has just bought that headset, that's impossible. At least not without getting MY sister in trouble because she plugged her new headset in and her speakers stopped working. There's no default for that sitation that satisfies everyone, hence the default should be the least surprising action. Which IMHO is as you were and requiring manual intervention to play music on the new device. On the other hand, after having configured PA *once* to play your sister's music on the headphones, PA certainly should remember that. (AFAICT, it currently does, and nobody wants to change that.) regards, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Removing volume sliders from media player UIs
Tanu Kaskinen schrob: I'm trying to build a convincing argument so that media player programmers voluntarily change their UIs. See below. You didn't say why you think device volume in bad - I assume because you think that the natural user expectation is that a volume slider in an application affects only that application and no others. Yes. And I accept that argument, and that is why I'm proposing getting rid of the sliders entirely instead of replacing the per-app controls with device volume controls. Yes, but per-app sliders are only bad if you confuse them and the device volume control. And btw, I consider anything that involves the mouse too difficult for common usage. Hence your sound preferences utility is not an acceptable solution in my view. In my view changing per-app volumes is not a common activity. In my experience, it is. That's because our usage scenarios differ. Lennart's distinction in https://tango.0pointer.de/pipermail/pulseaudio-discuss/2010-January/006334.html |A) material you play is too faint/loud because it was digitized that way |B) your surrounding is too silent/loud |C) You play two things and want one thing louder then the other is very helpful. I hope (and think; please speak up if you disagree) we all agree that A (in an ideal setup) and C (always) call for per-stream volume adjustment and B calls for device volume adjustment.[1] What we DON'T agree on is the importance of the different scenarios. Lennart finds that case B [..] seems to be the common case and Case C you probably do very seldomly. My experience is A:very common, C:somewhat common, B:rarely. Joe User might (imho legitimately) have his own, diffferent view. So now the interesting question is how do we handle (or not) these differences? My view is that there can't be a one-size-fits-all solution, and I want the tools to build my personally ideal setup.[2] Your personal/user view is I want device volume easily accessible, and per-stream volume may be more remote. Your desktop developer view is We need a simple, general solution that 'just works' for the majority of desktop users. And you then proceed to assume C is rare, and A can still be done with device volume, so you don't _need_ per-stream volume, thus your solution is do everything with device volume. [ I'm getting distracted by the thought below, and the mail is long enough already, so I'm stopping here and give you the chance to speak up if I was misrepresenting you: please do, I am merely trying to sum up the discussion so far in a constructive manner. ] I'd wager a media player developer's view would be something like We provide per-stream volume control easily accessible embedded in our player, and the user probably has a keyboard knob for device volume, so what's the problem? And I think that view has a lot of merit. Actually, writing this I realize we may be on the wrong track: Why do we want to stop media player authors from embedding volume controls? The original reason, IIRC, was that writing good volume controls is hard and we think PA people would do a better job. Then there was the argument it'd be better to have all volume control to be centrally done. Well, I don't see the point in centrally, so unless somebody steps up to defend that, I'll ignore it. But wrt. writing better volume controls: I think the media player authors will do a better job of writing the UI part of a volume control than PA people can (after all, integrated UI tends to be better). So why not provide a nice API for them to hook into? One that tells them the various interesting things (default volume, 100%, maximum volume, whatever you think is needed to implement the perfect control) and lets them wonder about which key the user presses or how to display the current volume. Pitching look, a 0-100 scale really isn't the best way to do volume adjustment, here's how you do it better to media player authors surely sounds more promising than you're not doing volume adjustment the way we prefer it's done, so please stop doing it altogether and let us handle it. And if you're really sneaky, you can add a function the user doesn't wish you to provide volume control at all to that API, and if/when you manage to convince users that the PA volume control applet is all they want, you can remotely disable the embedded controls. Similarly, you could allow the users to centrally choose whether they want the embedded controls to affect the per-stream or the device volume, if you think that's a valid choice to make. You still haven't convinced me to believe that you actually need to script your hotkeys or whatever to control per-app volumes - scripting them to control the device volume should work ok for you :( I really do need to easily control per-app volumes. I'm afraid if I couldn't convince you so far, I'll have to give up on that front. But can you accept that I (and by extension probably a lot of other people not on this list) _feel_ I need this
Re: [pulseaudio-discuss] Removing volume sliders from media player UIs
Tanu Kaskinen schrob: Aha. So you propose/defend making the per-app volume sliders difficult to change to prevent users shooting themselves in the foot? Yes. Well, just in order to avoid misunderstanding, I don't propose making it difficult, just significantly less convenient than changing the device volume (i.e. changing per-app volumes would require navigating to a sound preferences utility of some sort). By that reasoning, the media players would be allowed to have a volume control for changing the device volume. (That's a very bad idea imho.) And btw, I consider anything that involves the mouse too difficult for common usage. Hence your sound preferences utility is not an acceptable solution in my view. But if you use per-app volume, you can't use the (hypothetical) volume slider on your keyboard, which is a good reason to use device volume only. Well, this is why I requested a scriptable way to adjust the per-stream volume of the current application: Then the (hypothetical) volume slider on my keyboard could adjust per-application volumes. I usually use the volume dial on my keyboard, but it has happened that I didn't quite think what I was doing and I changed the stream volume ^^^ using the volume slider in Rhythmbox, causing some minor but unnecessary inconvenience - the conclusion: a conveniently available stream volume slider in Rhythmbox is a bad thing, My conclusion is different. ;) I want the tools to shoot myself in the foot, and I think giving them to users is one of the big strengths of unix. Please stick to that principle. in addition to being mostly redundant (it's only needed when the relative volume to other apps needs to be changed, which mostly (only?) means situations where two applications are playing simultaneously). If that situation is rare, there's not much point in PA, from my user's POV.[1] If I've understood correctly, too loud event sounds are your only major gripe with my proposal. If so, I guess this smart event volume is some kind of a priority for me, in case it isn't for Lennart. Too loud event sounds are my example for showing you why trying to do everything with the hw volume is wrong (if you have more than one audio source playing simultaneously). If event sounds is not sufficient for you or you think you can avoid the problem by treating them specially, consider voip + gaming: The other person moves their mic or shouts at someone in their room. You want to adjust the voip volume, but the game volume must stay the same. That said, event sounds is probably the most prominent case for me. But please don't use that as an excuse to band-aid around the problem, which is lack of easy scriptability in PA. regards, Jan [1] per-application volume restoration, easy device switching and power savings are nice, but not enough to make up for the extra hassle from incompatibilities. YMMV, obviously. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My computer thinks I'm schizophrenic, is PA for me?
Lennart Poettering schrob: On Fri, 16.04.10 21:02, Jan Braun (janbr...@gmx.de) wrote: You see, currently I'm the only person with access to my desktop pc, but I have several user accounts on it[1]. And I use them all. Simultaneously. As in: several consoles open, often more than 1 xserver running, You know, they invented window managers that support multiple workspaces. Fantastic stuff. You should try it once. I'm using one of them (ratpoison, calls it groups). But the point of having multiple xservers is having X running for different users. xterms ssh'd to otheru...@localhost . Why would you ssh to the local machine? Because su() doesn't play nice with programs requiring access to the terminal, e.g. screen(). Anyway, having one user with a split personality and hence is actually five users is certainly nothing I designed PA for. Sorry, No, problem, if passing around the cookie is a valid approach, then I'm happy. Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My computer thinks I'm schizophrenic, is PA for me?
Lennart Poettering schrob: On Sat, 17.04.10 16:42, Jan Braun (janbr...@gmx.de) wrote: Hmm, why not? I've set up PA as you describe (except for the additional auth-group parameter), and PA is creating entries in /dev/shm , even for other users than albert. The PA client libs always allocate their memory from an shm region, regardless whether it is later used for data transfer or not. Yep, and I get: | D: protocol-native.c: Protocol version: remote 16, local 16 | I: protocol-native.c: Got credentials: uid=1002 gid=1002 success=1 | D: protocol-native.c: SHM possible: yes | D: protocol-native.c: Negotiated SHM: no So this looks like 2392 in protocol-native.c : | /* Only enable SHM if both sides are owned by the same | * user. This is a security measure because otherwise data | * private to the user might leak. */ | | const pa_creds *creds; | if (!(creds = pa_pdispatch_creds(pd)) || getuid() != creds-uid) | do_shm = FALSE; ...and you're explicitly disallowing cross-user shm transfer. :( I guess I'll have to figure out the security implications of messing with that. regards, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My computer thinks I'm schizophrenic, is PA for me?
Lennart Poettering schrob: ...and you're explicitly disallowing cross-user shm transfer. :( I guess I'll have to figure out the security implications of messing with that. Well, the story goes like this: we need to make sure that a user A cannot trigger a SIGBUS in processes by user B simply by ftruncating an shm region A controls and B maps and accesses. Since handling SIGBUS from a library context is ugly to impossible we hence generally don't allow shm data transfer between users. Thanks for the explanation. But this is only a DoS, isn't it? A can terminate B's audio applications. That's something I could happily live with, particularly as it means one of my personalities would need to use a malicious (mis-)implementation of the PA protocol. But of course, I see how you wouldn't want to oficcially distribute that, so I'll probably be compiling my own version of PA in the future. The joys of Free Software. :) Thanks again, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My computer thinks I'm schizophrenic, is PA for me?
[I accidentally sent this only to Marti, you're getting it twice, sorry] Marti Raudsepp schrob: Can't you just copy ~/.pulse-cookie to all users' profiles, so everyone can access anyone else's PA daemon? It works for me, but I'm just using different user accounts within one X session. Oops, you're exactly right. Even better, the auth-group parameter does exactly what I need: allows access to all users in the jbraun group, without manual copying of the cookie. :) Thanks for the quick answer! Jan P.S.: relevant lines for the benefit of others with the same problem: ~jani/.pulse/default.pa : | load-module module-native-protocol-unix socket=/home/jani/.pulse-native auth-group=jbraun .bashrc (of all my users): | export PULSE_SERVER='unix:/home/jani/.pulse-native' -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] My computer thinks I'm schizophrenic, is PA for me?
Tanu Kaskinen schrob: On Fri, 2010-04-16 at 21:02 +0200, Jan Braun wrote: *** Now is your chance to say that's insane, and we don't support it I can't say it's insane, otherwise I'd be admitting that I've been insane in the past :) Well, you could say you've seen the error of your ways. ;) But we still don't support it. (Well, that depends on what support means, but since you've successfully been using the system mode, and you think we don't support it, I guess your definition of support means something like the use case is important to us.) Exactly. 3) per-user-pulseaudio, one with access to the hw, other users send to that one via network/localhost. Also mixes twice, and (almost) every sound data is pushed through lo. Unless PA recognzes lo and optimizes for that case? Also needs that one user to be logged in always (that's easily done, however).[2] My suggestion is basically the same as your option 3, without the double mixing and tcp overhead (I'm not sure whether using the loopback interface has much more overhead than unix domain sockets, though - you still won't be able to use shared memory for audio transport). Hmm, why not? I've set up PA as you describe (except for the additional auth-group parameter), and PA is creating entries in /dev/shm , even for other users than albert. Let's say your always-logged-in user, [...] That should be it. I didn't test any of this, so this probably doesn't work, at least at the first try. It did (well, almost.. I also had to disable PA auto-exiting, otherwise it stopped mysteriously working after a short time ;) Wasn't this supposed to be a single-person system? It currently is. But I'd like to be able to allow others access in the future. Sorry if that was unclear. My suggestion should be safer than the system wide mode, but my suggestion doesn't work perfectly with multiple real persons who don't all use albert's pulseaudio. It may work well enough, though. Yep, this is exactly what I was looking for. not perfecly because consolekit may be confused about whether albert should be considered logged in, I guess? Hmm, I'll see... So, do you think my scenario is valid? At least I don't see your scenario as an important case to support. If it works by copying around pulse-cookie (or even better, auth-group), that's good enough for me. I just didn't like the big warning signs on system mode. Yes, this is very similar to the system wide mode. The main difference is that when creating new users, they by default use their own pulseaudio instances. Yes, and just what I wanted. But the behaviour of new users can be easily adjusted by modifying /etc/pulse/client.conf . So how exactly is this better than system mode? Or isn't it? I'm confused. But thanks for your detailed how-to, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Standardising on the amount of software amplification is presented to the user
Tanu Kaskinen schrob: As long as there's no way to change the volume of the current application via the command line (so I can teach it to my window manager), I most certainly disagree. And yes, I do need per-application volume control (or think I do, see below). Your window manager doesn't need to know the current application, because you can teach it to control the device volume. So I still think you don't need per-application volume control, see below :) Sure, if I don't need per-application volume control, then amixer sset Master 2%+ is enough. If you don't have a hardware volume control like my volume dial available, and you're capable of configuring the window manager to do something with key combinations, I guess programming a key combination to turn the device volume up or down would be easier than mousing around. Yep, got that here. Still doesn't help with per-application volumes. :) If your model works for you, then that's great. If you do it right, you have to change the volume as often as with the device-volume-only model. So even if you're doing it right, I believe you don't actually win anything over those who use the device-volume-only model. An incoming email-notification not waking my neighbors because I was watching a youtube-video with extremely low sond levels is a pretty big win. The problem with your model is that it takes mental effort to do it right: [...] If a user has hardware volume dials or buttons and applications also have their own volume sliders, it's really easy to fail to obey your rules of volume adjustment: [...] Well, it's easy to fail any rules if you have both per-app and hw sliders, and don't think about what you're doing ;) At least if you actually want to change different applications' volume relative to each other. I believe most users haven't thought the concepts of device volume and stream volume to begin with, so they don't know the rules that you know, and therefore making wrong choices is very common if both the device and the stream volumes are easy to change. Aha. So you propose/defend making the per-app volume sliders difficult to change to prevent users shooting themselves in the foot? Compare that with the no-application-sliders case: the user uses always the hardware controls, or alternatively the volume applet. Both of those control the device volume. Now when the music player plays a good song, the user turns the device volume up. Again, this messes up the volumes of all other applications. But, this will be fixed the first time the user notices too loud volume - he will again adjust the device volume. After waking the neighbors, and then he'll not be able to understand the rest of that video. Doing this one adjustment fixes it for all applications. Note that even managing to do your model right doesn't win anything: as soon as the good song stops playing, you still need to lower the loud volume in the music player. Well, of course. Ideally, every per-app and the hw volume are set to good default values. You change them because that good song comes up (or whatever), and after it's done, you change them back. The only question is if you change the per-app volume or the hw volume. The notification sound issue may be solved in the future by making event sound level's relative to the actual current sound level. That is, if you play badly normalized stuff (too quiet), pulseaudio knows this and plays event sounds quietly too. That might help. Being in X is relevant because there you can have a convenient volume applet in case you don't have the even more convenient hardware controls I don't think an applet can be convenient. Might be just me, though. (can those be somehow used in the console, btw?). I don't see how an easily scriptable volume control interface would make changing volume in a console comparable to in-application volume control. Well, in a console not, in a screen(1) it's e.g. | bindkey -k F1 command -c audio | bind -c audio 8 exec ...| xmms2 volume +10 and then F118 raises my xmms2 volume. (But I do see that pulseaudio's command line tools could be improved.) Yep, see below. Anytime you present multimedia content with a beamer or the like. Dedicated hardware volume controls work in this case, right? Or in absence of those, using a basic keyboard with manually configured keybindings for controlling the volume? Yep. So the way forward should probably be: 1) Educate app authors about how to write _good_ embedded volume controls. 2) Get better external volume control programs. [time passses] 3) Convice app authors their embedded controls aren't necessary anymore. ...particularly as 3) should become a lot easier after 2) is achieved. I agree. If we get a consensus here, I don't see anything wrong with making the overall goal known already today, though. Ok. Do you have any specific visions for improved scriptability? I think there should
[pulseaudio-discuss] My computer thinks I'm schizophrenic, is PA for me?
Hi list, and sorry for bringing up this topic again, but I'm another user who has difficulties with PA's multi-user policy. You see, currently I'm the only person with access to my desktop pc, but I have several user accounts on it[1]. And I use them all. Simultaneously. As in: several consoles open, often more than 1 xserver running, xterms ssh'd to otheru...@localhost . *** Now is your chance to say that's insane, and we don't support it So, I want sound. For all of my accounts. Concurrently - I'm logged in concurrently, and e.g. email/IM notifications need to work especially when the email-account is not active. And my xmms2d needs to run as one (arbitrary, but fixed) user too, me switching between different windows/consoles/xservers mustn't prevent it from playing continuously. So, how does PA fit in here? 1) Currently, I run it in system mode. Only system mode has grown pretty scary warning signs. And you could reasonably break it altogether, say we told you so, and I'd get to keep the pieces. Not my favourite prospect. 2) per-user-pulseaudio on top of dmix. causes global warming, mixes sound twice, also not a nice solution. 3) per-user-pulseaudio, one with access to the hw, other users send to that one via network/localhost. Also mixes twice, and (almost) every sound data is pushed through lo. Unless PA recognzes lo and optimizes for that case? Also needs that one user to be logged in always (that's easily done, however).[2] 4) Your suggestion? 5) Ok, you get another chance to say Jan, that usage scenario is insane I'm seriously trying to find the proper way to use PA, and would love to be able to add accounts for other persons and have security against them eavesdropping etc.. But my impression is PA is designed for multiple seats per computer and for multiple persions per seat (i.e. fast user switching). And it's not designed for multiple accounts per person. So, do you think my scenario is valid? Do you (plan to) support it? Do you recommend one of the above solutions over the others? thanks and regards, Jan [1] One for email, IM etc. One for hobby programming/sysadmin stuff. One for work. One for games. [2] Plus I feel I'm recreating system mode here.. name the user with access to the hw pulse and optimize the local pa deamons away, and we're there. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Standardising on the amount of software amplification is presented to the user
Tanu Kaskinen schrob: On Wed, 2010-04-14 at 10:18 +0100, Colin Guthrie wrote: 'Twas brillig, and Tanu Kaskinen at 13/04/10 20:42 did gyre and gimble: Solution: throw away volume sliders in applications, and promote centralized volume management with volume applets and hardware controls. About b): if you're talking about the development effort of removing the sliders, I don't think it's really that much work. But I think volume applets and hardware volume control handler software aren't as good as they could be, and they really should be good if they're to be the only way of changing volume in most cases (in addition to pavucontrol and other such applications that really are too clumsy for everyday use). But do even we, the pulseaudio community, agree on this? As long as there's no way to change the volume of the current application via the command line (so I can teach it to my window manager), I most certainly disagree. And yes, I do need per-application volume control (or think I do, see below). You can toggle fullscreen by pressing F, right? I don't personally think that switching temporarily to windowed mode and using the volume applet is too awkward. It assuredly is for me. Volume control (or any important functionality) needs to be within easy reach, i.e. 2 keypresses max. The 5+ you suggest (includes switching back) is much too cumbersome. Besides, changing the stream volume is still the wrong thing to do (except in the rare occurrence when you actually do want to change the volume relative to other apps). How's that rare? Most of my touching volume sliders is caused by playing media that's not properly normalized/replaygained, or me wanting to listen to it at above/below normal level. If I did that with the master volume, I'd move my email/IM notification sounds as well. Or am I somehow mistaken in using the master volume as the adjust-for-ambient-noise-slider, and adjusting everything else per-stream to comfortable levels? Is mplayer any different from e.g. Totem in this regard, btw? The lack of a gui doesn't seem relevant, except when listening to music in the console while trying to fix X, in which case volume control in mplayer makes a lot of sense. But even then I think controlling the device volume would be more appropriate. How's being in X or not relevant? ;) If you want to stop applications from bringing their own volume controls, you MUST provide an easily scriptable volume control interface. Which has no reason to require X. Can you give some examples of the other use cases? I'm sure there are such cases, but none comes to my mind right now. Anytime you present multimedia content with a beamer or the like. You don't want to present the volume control applet you happen to use. You want your presentation going on and a minimal user interface for adjusting the sound, ideally unnoticed by everyone else. So the way forward should probably be: 1) Educate app authors about how to write _good_ embedded volume controls. 2) Get better external volume control programs. [time passses] 3) Convice app authors their embedded controls aren't necessary anymore. ...particularly as 3) should become a lot easier after 2) is achieved. regards, Jan -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments signature.asc Description: Digital signature ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
