Pulseaudio-discuss

Popular Threads From Pulseaudio-discuss:

{PATCH] AC3 passthrough support

Changing default soundcard on attach/detach of soundcards

Does pulseaudio require alsa/oss

Multiple users (kde) on Debian

Disabling ALSA period interrupts

List Statistics

Total Threads: 273
Total Posts: 1068

Phrases Used to Find This Thread

nothing provides libpulseaudio0

Page 1 of 1

26-07-2010 04:54 AM

Pulseaudio-discuss member admin is online now

User

26-07-2010 08:24 AM

Pulseaudio-discuss member admin is online now

User

26-07-2010 03:23 PM

Pulseaudio-discuss member admin is online now

User

26-07-2010 03:39 PM

Pulseaudio-discuss member admin is online now

User

26-07-2010 05:33 PM

Pulseaudio-discuss member admin is online now

User

26-07-2010 06:05 PM

Pulseaudio-discuss member admin is online now

User

26-07-2010 07:36 PM

Pulseaudio-discuss member admin is online now

User

26-07-2010 10:57 PM

Pulseaudio-discuss member admin is online now

User

27-07-2010 01:34 AM

Pulseaudio-discuss member admin is online now

User

In a situation where there is a single physical seat (i.e. one keyboard
and monitor) but there are multiple logical seats, the PA logic is to cork
(mute) the first user, and enable sound for the next logged-in user.

However, with CTRL-ALT-F7 CTRL-ALT-F8, etc it is possible to switch user's
X screens without "logging in".

Furthermore, if one user starts a console session to a different user with
"sudo -i -u user2 bash", there is no log-in process, and the second user
(user2) does not get to activate sound.

Assuming no user is in the "audio" group.

Is there a way to allow concurrent (local) sounds for both users?

--
Mark Cross

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Mark Cross at 26/07/10 04:54 did gyre and gimble:
> In a situation where there is a single physical seat (i.e. one keyboard
> and monitor) but there are multiple logical seats, the PA logic is to cork
> (mute) the first user, and enable sound for the next logged-in user.
>
> However, with CTRL-ALT-F7 CTRL-ALT-F8, etc it is possible to switch user's
> X screens without "logging in".
>
> Furthermore, if one user starts a console session to a different user with
> "sudo -i -u user2 bash", there is no log-in process, and the second user
> (user2) does not get to activate sound.
>
> Assuming no user is in the "audio" group.
>
> Is there a way to allow concurrent (local) sounds for both users?

There is always a way :D

The problem is that this is not the normal setup (imaging User A setting
up their Brittany Spears Discog on a loop and locking the screen! How
evil can a human be?!?)

But ultimately you can run PA in system mode. Lots of things don't work
as nicely (such as module loading and such like) and efficiency
mechanisms (i.e. using SHM for data passing which is much faster) will
be lost.

But the short answer is:
1. Create a "pulse" user and add it to the "audio" group.
2. Run pulseaudio in system mode (pulseaudio --system)
3. Put your users in the "pulse-access" groups.

Col

--

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. Colin Guthrie wrote:

> 'Twas brillig, and Mark Cross at 26/07/10 04:54 did gyre and gimble:
>> In a situation where there is a single physical seat (i.e. one keyboard
>> and monitor) but there are multiple logical seats, the PA logic is to
>> cork (mute) the first user, and enable sound for the next logged-in
>> user.
>>
>> However, with CTRL-ALT-F7 CTRL-ALT-F8, etc it is possible to switch
>> user's X screens without "logging in".
>>
>> Furthermore, if one user starts a console session to a different user
>> with "sudo -i -u user2 bash", there is no log-in process, and the second
>> user (user2) does not get to activate sound.
>>
>> Assuming no user is in the "audio" group.
>>
>> Is there a way to allow concurrent (local) sounds for both users?
>
> There is always a way :D

:-)

> The problem is that this is not the normal setup (imaging User A setting
> up their Brittany Spears Discog on a loop and locking the screen! How
> evil can a human be?!?)

A very evil scenario, Indeed. :-)

> But ultimately you can run PA in system mode. Lots of things don't work
> as nicely (such as module loading and such like) and efficiency
> mechanisms (i.e. using SHM for data passing which is much faster) will
> be lost.

Yes, I am aware of that option. However, on reading this:
http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode

One gets very discouraged to do so. For example:
" Security: all users that have access to the server can sniff
into each others audio streams, listen to their mikes, and so on. "

And, in particular:
" You are using PA against the explicit recommendations of the
maintainers, so don't expect particularly enthusiastic support
from them in doing so. "

Which essentially says: "You are on your own". Having to cope (even more)
with each change on the sound system, or HAL, or Policy-kit, because this
is a not "supported option" is not an interesting future.

So, there must be a way "supported by maintainers" to have two PA instances
form two users that share access to the sound system.

The problem Pulseaudio was supposed to solve was to have mixing of several
streams, but in doing so, PA took total ownership of the sound hardware,
not allowing any other service to access the hardware, not even a second
instance of PA. That have just shift the mixing issue from ALSA to PA, with
seemingly equivalent basic problems. Yes, it has several interesting and
useful features, but I wonder: what is the "supported" way to have several
services access the sound system?

As the developers decided to completely take ownership of the sound
hardware:

Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for PA?

--
Mark Cross

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe. 'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble:
> Colin Guthrie wrote:
>> But ultimately you can run PA in system mode. Lots of things don't work
>> as nicely (such as module loading and such like) and efficiency
>> mechanisms (i.e. using SHM for data passing which is much faster) will
>> be lost.
>
> Yes, I am aware of that option. However, on reading this:
> http://pulseaudio.org/wiki/WhatIsWrongWithSystemMode
>
> One gets very discouraged to do so. For example:
> " Security: all users that have access to the server can sniff
> into each others audio streams, listen to their mikes, and so on. "
>
> And, in particular:
> " You are using PA against the explicit recommendations of the
> maintainers, so don't expect particularly enthusiastic support
> from them in doing so. "
>
> Which essentially says: "You are on your own". Having to cope (even more)
> with each change on the sound system, or HAL, or Policy-kit, because this
> is a not "supported option" is not an interesting future.

Indeed, for the reasons listed it's not exactly ideal.

> So, there must be a way "supported by maintainers" to have two PA instances
> form two users that share access to the sound system.

Sadly there is no officially recommended way to do this. This is
actually enforced at a lower level than PA with ConsoleKit ultimately
being responsible for writing the ACLs on the device nodes (via udev)
used for the sound h/w.

****-list-sessions will tell you which user is "active" and typically this
user will get access to various different resources on the machine by
virtue of them being active.

PA simply listens to messages from **** 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.

> The problem Pulseaudio was supposed to solve was to have mixing of several
> streams, but in doing so, PA took total ownership of the sound hardware,
> not allowing any other service to access the hardware, not even a second
> instance of PA. That have just shift the mixing issue from ALSA to PA, with
> seemingly equivalent basic problems. Yes, it has several interesting and
> useful features, but I wonder: what is the "supported" way to have several
> services access the sound system?
>
> As the developers decided to completely take ownership of the sound
> hardware:
>
> Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for PA?

In theory this would be possible. There are however two basic problems.
The first is that a physical socket file patch is currently used. This
could be changed perhaps to be a more abstract socket, but as things
stand, user2 would need to have physical write permission to that socket
(there are various ownership checks and such in the code).

But if user2 could access user1's PA socket, and he had access to the
"cookie" used (~/user1/.pulse-cookie), then user2 could output sound to
user1's PA daemon.

If user1 were a member of the audio group, then even if user1's session
was not active (according to console-kit), he would be allowed to access
the sound devices by virtual of them being group writeable.

A perhaps simpler (and slightly less efficient) mechanism to enable this
is to simply enable networking support for the primary user (either
without authentication or with a copied cookie file). Then set
"default-server=localhost" in the client.conf of other users.

Of course the same problems regarding the ability of user2 to know what
output user1 was making and generally sniff or otherwise interfere with
them still exist (and user2 would also not be able to use SHM etc. too).

I think a pahost +.... syntax would be nice, but it's not something that
is currently possible OOTB due to the way in which PA follows the
'active' user around.

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) and that is
therefore the case we really want to get right, even if other, more
exotic, scenarios are not easy to achieve.

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/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.
Colin Guthrie schrob:
> 'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble:
> > So, there must be a way "supported by maintainers" to have two PA instances
> > form two users that share access to the sound system.
>
> Sadly there is no officially recommended way to do this. This is
> actually enforced at a lower level than PA with ConsoleKit ultimately
> being responsible for writing the ACLs on the device nodes (via udev)
> used for the sound h/w.
>
> ****-list-sessions will tell you which user is "active" and typically this
> user will get access to various different resources on the machine by
> virtue of them being active.

That sounds like resources can never be shared. Which is what Mark and I
are looking for.

> PA simply listens to messages from **** 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 **** isn't such a good police^Hy.

> > The problem Pulseaudio was supposed to solve was to have mixing of several
> > streams, but in doing so, PA took total ownership of the sound hardware,
> > not allowing any other service to access the hardware, not even a second
> > instance of PA. That have just shift the mixing issue from ALSA to PA, with
> > seemingly equivalent basic problems. Yes, it has several interesting and
> > useful features, but I wonder: what is the "supported" way to have several
> > services access the sound system?

None.
Alsa supports[1] one application playing audio at a time.
PA supports applications of one user playing at a time.
There's an obvious next step, and PA is not taking it.

(Not blaming the PA folks. PA certainly already is a hard task as-is.
And in the worse-is-better spirit, getting PA work for "desktop" usage
and worry about the rest later probably indeed is the best way forward.
But I still feel it's a pity.)

> > Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for PA?
>
> In theory this would be possible. There are however two basic problems.
> The first is that a physical socket file patch is currently used. This
> could be changed perhaps to be a more abstract socket, but as things
> stand, user2 would need to have physical write permission to that socket
> (there are various ownership checks and such in the code).
>
> But if user2 could access user1's PA socket, and he had access to the
> "cookie" used (~/user1/.pulse-cookie), then user2 could output sound to
> user1's PA daemon.
>
> If user1 were a member of the audio group, then even if user1's session
> was not active (according to console-kit), he would be allowed to access
> the sound devices by virtual of them being group writeable.

This is exactly what I'm running here. Works well enough.
@Mark: See the "My computer thinks I'm schizophrenic.." thread from
mid-April, I posted the config there (but it's basically what Colin just
said).

> Of course the same problems regarding the ability of user2 to know what
> output user1 was making and generally sniff or otherwise interfere with
> them still exist (and user2 would also not be able to use SHM etc. too).

...which I don't care about, because all the users are me, but otherwise
it's still something PA can't cope with at all.

> 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) and that is
> therefore the case we really want to get right, even if other, more
> exotic, scenarios are not easy to achieve.

Urgh, I hate that reasoning. Personally I don't care what Windows or Mac
OS do. I expect Unix to do the Right Thing. Which, in this case, would
be "(allow to) manage the permissions of different users and make sure
they play nice with each other", not "allow only one user to access the
compu^Waudio system at a time".

PA might be the way there. At least, if PA succeeds, it'll purge HW
dependency, which is a giant step forward. But currently, I feel PA is
severely lacking in Unix spirit.

regards,
Jan

[1] for demanding interpretations of "support"
--
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Colin Guthrie wrote:

> 'Twas brillig, and Mark Cross at 26/07/10 15:23 did gyre and gimble:
>> Colin Guthrie wrote:

>> So, there must be a way "supported by maintainers" to have two PA
>> instances form two users that share access to the sound system.
>
> Sadly there is no officially recommended way to do this. This is
> actually enforced at a lower level than PA with ConsoleKit ultimately
> being responsible for writing the ACLs on the device nodes (via udev)
> used for the sound h/w.

We are talking of two instances of PA here, saying that the responsibility
is somewhere else (in ****), looks like a way to squirrel away the
responsibility to do the "right thing". If user1 "validates" access to
user2 (pahost + concept), what's the fuss?

> ****-list-sessions will tell you which user is "active" and typically this
> user will get access to various different resources on the machine by
> virtue of them being active.

Hmmm, yes that is working. On user2 logging-in and getting it's "Session"
as active, is able to play sounds. On switching with CTRL-ALT-F7 and CTRL-
ALT-F8 (or using switch-user) the corresponding "Session" changes state to
active and is allowed to play sounds.

However, this concept of "active" deals with the logged-in user, there is
no "concurrency" in it. Each user is switched "on" or "off" as needed.

> PA simply listens to messages from **** and gracefully releases it's
> control of the devices when it's not supposed to have access. In reality
> we're just being a good citizen in this regard.

Yes, PA should a****nowledge **** messages and act accordingly. I don't know if
"demanding" "exclusive, unchallenged" "ownership" of the sound hardware is
being a "good citizen".

>> The problem Pulseaudio was supposed to solve was to have mixing of
>> several streams, but in doing so, PA took total ownership of the sound
>> hardware, not allowing any other service to access the hardware, not
>> even a second instance of PA. That have just shift the mixing issue from
>> ALSA to PA, with seemingly equivalent basic problems. Yes, it has
>> several interesting and useful features, but I wonder: what is the
>> "supported" way to have several services access the sound system?
>>
>> As the developers decided to completely take ownership of the sound
>> hardware:
>>
>> Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for
>> PA?

> In theory this would be possible. There are however two basic problems.
> The first is that a physical socket file patch is currently used. This
> could be changed perhaps to be a more abstract socket, but as things
> stand, user2 would need to have physical write permission to that socket
> (there are various ownership checks and such in the code).
>
> But if user2 could access user1's PA socket, and he had access to the
> "cookie" used (~/user1/.pulse-cookie), then user2 could output sound to
> user1's PA daemon.

Linking the "cookie" (~/user1/.pulse-cookie) is easy enough, what else is
needed to "access user1's PA socket"?

> If user1 were a member of the audio group, then even if user1's session
> was not active (according to console-kit), he would be allowed to access
> the sound devices by virtual of them being group writeable.

Not having any user as part of the "audio" group is a PA recommendation:
http://pulseaudio.org/wiki/FAQ

Section 3 - Troubleshooting,
Item 10 Sound doesn't work when switching users
" By removing all users from the "audio" group (the PulseAudio server
still runs in the "audio" group), PulseAudio is able manage access
to sound devices (/dev/snd/*) amongst multiple users with the help
of ConsoleKit. "

That enforces the concept of PA being the owner of (/dev/snd/*), so, it
should be PA who should deal with this "concurrent" situation IMO.

Also, "audio" group ownership creates this kind of problems:
http://swiss.ubuntuforums.org/showthread.php?t=1417647&page=2

> A perhaps simpler (and slightly less efficient) mechanism to enable this
> is to simply enable networking support for the primary user (either
> without authentication or with a copied cookie file). Then set
> "default-server=localhost" in the client.conf of other users.

No, that will create this "rather confusing situation occurs":
http://www.mail-archive.com/pulseaudio-/msg06635.html

So, using such option breaks normal "user switching".

> Of course the same problems regarding the ability of user2 to know what
> output user1 was making and generally sniff or otherwise interfere with
> them still exist (and user2 would also not be able to use SHM etc. too).

I rather see this "sniffing" issue rather "inconsequential" IF user1
specifically has to validate user2 access. After that, user1 will know,
as he has enabled such access.

Besides, what is the issue with the output? Having the sound of a
"Brittany Spears song" playing in the speakers is so annoying?
Doesn't PA have the ability to mute individual streams?
Just present user1 the running streams of user2 in pavucontrol and allow
him to mute as needed.

The only (remote) issue is with grabbing the "mic", which user1 has to enable.
But, there isn't the ability to control individual recording streams in
pavucontrol as well?

Just do the opposite, mute by default, and allow user1 to unmute as needed/desired.

> I think a pahost +.... syntax would be nice, but it's not something that
> is currently possible OOTB due to the way in which PA follows the
> 'active' user around.

Yes, it would be a good thing to implement.

> 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) and that is
> therefore the case we really want to get right, even if other, more
> exotic, scenarios are not easy to achieve.

Gee, following the "lead" of Windows, which wants only one user to use
the computer to make sure each user pays for the software, doesn't seem
the right "recipe" to apply to a multiuser Linux system.

--
Mark Cross

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.
'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble:
>>> So, there must be a way "supported by maintainers" to have two PA
>>> instances form two users that share access to the sound system.
>>
>> Sadly there is no officially recommended way to do this. This is
>> actually enforced at a lower level than PA with ConsoleKit ultimately
>> being responsible for writing the ACLs on the device nodes (via udev)
>> used for the sound h/w.
>
> We are talking of two instances of PA here, saying that the responsibility
> is somewhere else (in ****), looks like a way to squirrel away the
> responsibility to do the "right thing". If user1 "validates" access to
> user2 (pahost + concept), what's the fuss?

If it's squrreling out then I apologise, but really different components
of a system should work together right? Different layers should
generally be interoperable right? Or should every layer just do it's own
thing and screw the decisions and designs of lower layers?

That said, I'm certainly not against the principle of a validation, but
that is fundamentally different to the whole design of PA as it stands.
The concept may sound simple, but it'll basically require a full rewrite
of large parts of PA, not to mention changing several parts of
consolekit and udev with regards to the ACLs.

>> ****-list-sessions will tell you which user is "active" and typically this
>> user will get access to various different resources on the machine by
>> virtue of them being active.
>
> Hmmm, yes that is working. On user2 logging-in and getting it's "Session"
> as active, is able to play sounds. On switching with CTRL-ALT-F7 and CTRL-
> ALT-F8 (or using switch-user) the corresponding "Session" changes state to
> active and is allowed to play sounds.
>
> However, this concept of "active" deals with the logged-in user, there is
> no "concurrency" in it. Each user is switched "on" or "off" as needed.

That's the way it works yes. If you don't like this approach it's really
something to bring up with the Console Kit folks and make your case there.

>> PA simply listens to messages from **** and gracefully releases it's
>> control of the devices when it's not supposed to have access. In reality
>> we're just being a good citizen in this regard.
>
> Yes, PA should a****nowledge **** messages and act accordingly. I don't know if
> "demanding" "exclusive, unchallenged" "ownership" of the sound hardware is
> being a "good citizen".

Well all we're doing is acting on the messages given from a lower layer
in the system. I'm not really sure how we can do more than that.

>>> Shouldn't exist an option like: [ xhost +local:user2 (X-server) ] for
>>> PA?
>
>> In theory this would be possible. There are however two basic problems.
>> The first is that a physical socket file patch is currently used. This
>> could be changed perhaps to be a more abstract socket, but as things
>> stand, user2 would need to have physical write permission to that socket
>> (there are various ownership checks and such in the code).
>>
>> But if user2 could access user1's PA socket, and he had access to the
>> "cookie" used (~/user1/.pulse-cookie), then user2 could output sound to
>> user1's PA daemon.
>
> Linking the "cookie" (~/user1/.pulse-cookie) is easy enough, what else is
> needed to "access user1's PA socket"?

Well it's just a matter of getting the path correct. On a typical X11
login, have a look at the output of "xprop -root | grep PULSE" this will
show you the format of the PULSE_SERVER variable. This can be put into
the env var PULSE_SERVER or the client.conf file as the default-server
option.

>> If user1 were a member of the audio group, then even if user1's session
>> was not active (according to console-kit), he would be allowed to access
>> the sound devices by virtual of them being group writeable.
>
> Not having any user as part of the "audio" group is a PA recommendation:
> http://pulseaudio.org/wiki/FAQ
>
> Section 3 - Troubleshooting,
> Item 10 Sound doesn't work when switching users
> " By removing all users from the "audio" group (the PulseAudio server
> still runs in the "audio" group), PulseAudio is able manage access
> to sound devices (/dev/snd/*) amongst multiple users with the help
> of ConsoleKit. "
>
> That enforces the concept of PA being the owner of (/dev/snd/*), so, it
> should be PA who should deal with this "concurrent" situation IMO.
>
> Also, "audio" group ownership creates this kind of problems:
> http://swiss.ubuntuforums.org/showthread.php?t=1417647&page=2

Yes it is indeed the part of the recommended set up, but then so is the
method of operating where only the active user has access to the sound
system and you've already stated that you don't accept that
recommendation so it follows that you may also have to deviate in other
ways too.

Also I don't think, that "PA being the owner of /dev/snd/* is correct. I
will try and update that FAQ to clarify, but the PA server does *not*
run in the "audio" group as quoted. It runs as the user, and consolekit
gives the active user write permission on /dev/snd/* by virtual of an
ACL. The audio group does not come into it.

Only when PA is run as a system service would the "pulse" user have to
be in the "audio" group. On a typical setup, this would not be the case.

So PA really is not the owner of /dev/snd/*. It merely listens to what
consolekit and udev say and adheres to it.

>> A perhaps simpler (and slightly less efficient) mechanism to enable this
>> is to simply enable networking support for the primary user (either
>> without authentication or with a copied cookie file). Then set
>> "default-server=localhost" in the client.conf of other users.
>
> No, that will create this "rather confusing situation occurs":
> http://www.mail-archive.com/pulseaudio-/msg06635.html
>
> So, using such option breaks normal "user switching".

But you don't *want* normal user switching.... Have I completely missed
the point? I'm confused why you bring up this "disadvantage" when in
actual fact you really want to exploit this behaviour to get concurrent
access.

>> Of course the same problems regarding the ability of user2 to know what
>> output user1 was making and generally sniff or otherwise interfere with
>> them still exist (and user2 would also not be able to use SHM etc. too).
>
> I rather see this "sniffing" issue rather "inconsequential" IF user1
> specifically has to validate user2 access. After that, user1 will know,
> as he has enabled such access.

Yeah, that's a valid argument. If the the user has allowed access then
they've allowed access and anything that happens, happens with their
tacit agreement (tho' me agreeing with the principle, doesn't change the
fact that creating such a system would require a significant amount of
reworking of design and code of various Linux subsystem all for the 10
users who have ever moaned about this!).

> Besides, what is the issue with the output? Having the sound of a
> "Brittany Spears song" playing in the speakers is so annoying?
> Doesn't PA have the ability to mute individual streams?
> Just present user1 the running streams of user2 in pavucontrol and allow
> him to mute as needed.
>
> The only (remote) issue is with grabbing the "mic", which user1 has to enable.
> But, there isn't the ability to control individual recording streams in
> pavucontrol as well?
>
> Just do the opposite, mute by default, and allow user1 to unmute as needed/desired.

Such suggestions mean that a large chunk of PA would need to be
rewritten to include a concept of "users" with different policy on
modules/clients/sources/sinks/sink-inputs/source-outputs etc. depending
on the active user as indicated by console kit.

Such a design could work (there are numerous problems and caveats and
reasons not to do this but I wont go into the detail here), but it's a
massive project, and I very much doubt anyone here will be working on
something like that any time soon.

>> I think a pahost +.... syntax would be nice, but it's not something that
>> is currently possible OOTB due to the way in which PA follows the
>> 'active' user around.
>
> Yes, it would be a good thing to implement.

As I said above, as much as this is a nice thing to implement, it would
require a significant rewrite of a large chunk of PA.

>> 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) and that is
>> therefore the case we really want to get right, even if other, more
>> exotic, scenarios are not easy to achieve.
>
> Gee, following the "lead" of Windows, which wants only one user to use
> the computer to make sure each user pays for the software, doesn't seem
> the right "recipe" to apply to a multiuser Linux system.

I find it highly bizarre that people automatically assume that just
because windows does something, that it's wrong. So many linuxy people
do this and to do so automatically is arrogant in the extreme (not
suggesting this is the case here tho'). I'm as happy as the next linux
geek to bash windows, but I'm no so crazy as to assume that everything
on windows is automatically "wrong" regardless of how much I may
disagree with certain other aspects.

The fact of the matter remains that user switching is something that
Linux has done for a long time, but so has Windows and OSX and more or
less they've all behaved in the same kinda way: by making the crazy and
outlandish assumption that the user sitting at the keyboard and looking
at the monitor is the one that should have full access to the machine's
resources. Is that really such a crazy concept? Sure there *can* be
multiple users who want to use the devices at the same time, but this
use case is a tiny fraction of the percentage of the overall audience.
Things *can* currently be made to work the way you want it, but we very
much focus on the common case. Is that really such a bad idea?

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/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.
Colin Guthrie wrote:

> 'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble:

> That said, I'm certainly not against the principle of a validation, but
> that is fundamentally different to the whole design of PA as it stands.
> The concept may sound simple, but it'll basically require a full rewrite
> of large parts of PA, not to mention changing several parts of
> consolekit and udev with regards to the ACLs.

Then, perhaps, the design is flawed from the beginning?

> That's the way it works yes. If you don't like this approach it's really
> something to bring up with the Console Kit folks and make your case
> there.

I really don't know the details, but:

Is **** controlling the (xhost +...) made by the X-server?
Or is it a service/task that the server covers by itself?

> Well it's just a matter of getting the path correct. On a typical X11
> login, have a look at the output of "xprop -root | grep PULSE" this will
> show you the format of the PULSE_SERVER variable. This can be put into
> the env var PULSE_SERVER or the client.conf file as the default-server
> option.

No result from that command here:
$ xprop -root PULSE
PULSE: no such atom on any window.
$ xprop -root | grep PULSE
$
$ _

> Yes it is indeed the part of the recommended set up, but then so is the
> method of operating where only the active user has access to the sound
> system and you've already stated that you don't accept that
> recommendation so it follows that you may also have to deviate in other
> ways too.

Why, oh my, why, such answer?

It isn't anything to do with what I accept or not. I am trying (very hard)
to comply with all the pulseaudio recommendations and "special" conditions
and, at the same time, cover a simple, specific need. One that seems
impossible to get you to agree exists, much less provide a solution to.

> Also I don't think, that "PA being the owner of /dev/snd/* is correct. I
> will try and update that FAQ to clarify, but the PA server does *not*
> run in the "audio" group as quoted. It runs as the user, and consolekit
> gives the active user write permission on /dev/snd/* by virtual of an
> ACL. The audio group does not come into it.

That's what the pulseaudio.org FAQ says, no my fault in any way.

> Only when PA is run as a system service would the "pulse" user have to
> be in the "audio" group. On a typical setup, this would not be the case.

The system service is something you "strongly discourage".

> So PA really is not the owner of /dev/snd/*. It merely listens to what
> consolekit and udev say and adheres to it.

So does the X-server, I presume, and yet they have the (xhost +...) option.

>> So, using such option breaks normal "user switching".

> But you don't *want* normal user switching.... Have I completely missed
> the point? I'm confused why you bring up this "disadvantage" when in
> actual fact you really want to exploit this behaviour to get concurrent
> access.

Why I don't *want* normal user switching? Perhaps I am not in your set of
"pre-analyzed groups"?

I feel exactly as the time when I was discussing disk usage with a Windows
representative:
-- No, sorry, the copy of the backup of unused data is the way the
system was designed to work, accept it. Besides, disk space is very
cheap this days, what is the problem with using 120 Gigabytes of
additional disk space?
-- Maybe because I paid for the disk and I believe I have the right
to decide what should be stored in it?

And I decided, not using Windows now.

So you understand, I'll explain in length what is the reason.

Let's accept the concept that this is a computer in which several users
work, not much, but they have accounts and use when needed. Being that the
case, switching accounts and having sound work on each account is welcomed,
and accepted as how "things should be". Having all users share the same
pool of resources is not "a wise thing to do", as, even if I trust most of
the users (to a certain extent), there is no guarantee that they will not
do something foolish. Not that they will be "evil", just dumb sometimes.

Then, this "small" issue of a flash bug appeared. Flash "upgraded" to
version 10, but in the process, left out 64 bit support. This system,
sadly?, is a 64 bit system. So the options were: live with the security
flash bug, use nsplugin, or create a 32 bit chroot. Leaving the system for
all users with a "open hole" is out of the question. The nsplugin is a
sorry mess now, changes all the ia32libs to get "almost" working. So, the
only viable solution was to use a chroot setup.

Having the undesired task of setting a chroot 32 bit for flash, I decided,
well, then, let's get the browser out of any access to the local user files
and rights, let's use a different "user account" for the browser.

Here is where I am getting to this brick wall of "not possible" to share
sound between users with PA.

Well, really, to several possible solutions, none of which seems to be the
"right one".

Perhaps I have to re-think all this over *again* .

>> I rather see this "sniffing" issue rather "inconsequential" IF user1
>> specifically has to validate user2 access. After that, user1 will know,
>> as he has enabled such access.

> Yeah, that's a valid argument. If the the user has allowed access then
> they've allowed access and anything that happens, happens with their
> tacit agreement (tho' me agreeing with the principle, doesn't change the
> fact that creating such a system would require a significant amount of
> reworking of design and code of various Linux subsystem all for the 10
> users who have ever moaned about this!).

There goes again: I am one of 10 users who ever "moaned", thanks!!.

Perhaps the rest of users just haven't realize they have such need, yet.

Or you are just: "not prepared" to deal with this reality?

>> Yes, it would be a good thing to implement.

> As I said above, as much as this is a nice thing to implement, it would
> require a significant rewrite of a large chunk of PA.

Yes, you have made that very clear: "just a 10 users need".

>>> 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) and that is
>>> therefore the case we really want to get right, even if other, more
>>> exotic, scenarios are not easy to achieve.

>> Gee, following the "lead" of Windows, which wants only one user to use
>> the computer to make sure each user pays for the software, doesn't seem
>> the right "recipe" to apply to a multiuser Linux system.

> I find it highly bizarre that people automatically assume that just
> because windows does something, that it's wrong. So many linuxy people
> do this and to do so automatically is arrogant in the extreme (not
> suggesting this is the case here tho'). I'm as happy as the next linux
> geek to bash windows, but I'm no so crazy as to assume that everything
> on windows is automatically "wrong" regardless of how much I may
> disagree with certain other aspects.

Were did I "Automatically assumed"?

Not having the capability for several users to access the graphical screen
(X-server) is a Windows limitation, much alike as not having access to the
sound system for several users.

I am very sorry you fail to realize that.

Nothing to do with it being windows, it could be called Unix or Mac, it is
just a real limitation. Important or not?: that is a "value judgment",
which you have done some time ago, it seems, as I am one of "10 people who
'moaned' about this", thanks again.

> The fact of the matter remains that user switching is something that
> Linux has done for a long time, but so has Windows and OSX and more or
> less they've all behaved in the same kinda way: by making the crazy and
> outlandish assumption that the user sitting at the keyboard and looking
> at the monitor is the one that should have full access to the machine's
> resources. Is that really such a crazy concept? Sure there *can* be
> multiple users who want to use the devices at the same time, but this
> use case is a tiny fraction of the percentage of the overall audience.
> Things *can* currently be made to work the way you want it, but we very
> much focus on the common case. Is that really such a bad idea?

Where have I said anything about "crazy and outlandish"?
Could you leave you pre-judgments out of this?

A "tiny fraction", huh? That is exactly the mentality which drove me away
from windows. Exactly the bully of not wanting to hear user problems or
just pushing it aside by "not being in the use case we cover", thanks.

It seems broken mentalities sprout everywhere.

--
Mark Cross

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.
'Twas brillig, and Mark Cross at 26/07/10 22:57 did gyre and gimble:
> Colin Guthrie wrote:
>
>> 'Twas brillig, and Mark Cross at 26/07/10 18:05 did gyre and gimble:
>
>> That said, I'm certainly not against the principle of a validation, but
>> that is fundamentally different to the whole design of PA as it stands.
>> The concept may sound simple, but it'll basically require a full rewrite
>> of large parts of PA, not to mention changing several parts of
>> consolekit and udev with regards to the ACLs.
>
> Then, perhaps, the design is flawed from the beginning?

I don't think so. To do something as you suggest essentially means that
a whole user-based permissions model has to be built into PA and PA
itself has to be turned into a system service. This in itself means that
lots of nice things like the zero copy core will have to be sacrificed
because the overhead of secure SHM access across users is likely to not
be worth the benefit.

In other words the whole user-based principles of a unix based system
are essentially thrown away and a whole new user-based system is built
into the sound server subsystem. This isn't the right place for a user
management system in the first place and it doesn't make sense really to
implement it there.

Just because the system does not do what you want it to do, does not
mean that:
a) There are not good reasons against doing what you want.
b) That the design is flawed.

You're perfectly within your rights to ask the question, but I happen to
think that the design is not flawed, and it's simply a use case that,
while attractive to some niche use cases, has implementation
repercussions that are a long way from desirable.

>> That's the way it works yes. If you don't like this approach it's really
>> something to bring up with the Console Kit folks and make your case
>> there.
>
> I really don't know the details, but:
>
> Is **** controlling the (xhost +...) made by the X-server?
> Or is it a service/task that the server covers by itself?

No but **** will control access to e.g. /dev/dri which is used by the
xserver. It has nothing to do with the permission to access the X server
socket and the right to use the Xserver. In actual fact the X server
case is a pretty good example of what we do. We are very similar to the
X server. I'll describe it below.

>> Well it's just a matter of getting the path correct. On a typical X11
>> login, have a look at the output of "xprop -root | grep PULSE" this will
>> show you the format of the PULSE_SERVER variable. This can be put into
>> the env var PULSE_SERVER or the client.conf file as the default-server
>> option.
>
> No result from that command here:
> $ xprop -root PULSE
> PULSE: no such atom on any window.
> $ xprop -root | grep PULSE
> $
> $ _

I guess you've either a) restarted PA since logging in to X11, or b) do
not have an XDG compliant login manager that processes XDG autostart
.desktop files.

The file start-pulseaudio-x11 should be run via XDG autostart at X11
init. This script will make these properties available. These properties
allow you e.g. to ssh to a remote machine and have the display *and* the
sound locally.

>> Yes it is indeed the part of the recommended set up, but then so is the
>> method of operating where only the active user has access to the sound
>> system and you've already stated that you don't accept that
>> recommendation so it follows that you may also have to deviate in other
>> ways too.
>
> Why, oh my, why, such answer?

I thought it was a perfectly reasonable answer? I'm not suggesting there
is anything particularly wrong with your approach. It's not the typical
use case but the software can do it and I'm trying my best to tell you
how to use it that way.

> It isn't anything to do with what I accept or not. I am trying (very hard)
> to comply with all the pulseaudio recommendations and "special" conditions
> and, at the same time, cover a simple, specific need. One that seems
> impossible to get you to agree exists, much less provide a solution to.

Sorry you feel that way. I've tried my best to describe what you need to
do to get it working. If those instructions are not clear then please
let me know which bits you are having trouble understanding.

You are correct that I don't agree that your use case is one which has
any real life, practical uses, but I've certainly given you a two or
three different ways in which you can achieve the end result you want.

The fact is that your "simple, specific need" is orthogonal to the
"special" conditions. You can't have both at the same time. If you can't
sacrifice the special conditions, then you have to give up on achieving
your solution.

>> Also I don't think, that "PA being the owner of /dev/snd/* is correct. I
>> will try and update that FAQ to clarify, but the PA server does *not*
>> run in the "audio" group as quoted. It runs as the user, and consolekit
>> gives the active user write permission on /dev/snd/* by virtual of an
>> ACL. The audio group does not come into it.
>
> That's what the pulseaudio.org FAQ says, no my fault in any way.

I never implied that it was. I even said I'd try and find time to update
the FAQ, so quite clearly implied that it was wrong, not you.

>> Only when PA is run as a system service would the "pulse" user have to
>> be in the "audio" group. On a typical setup, this would not be the case.
>
> The system service is something you "strongly discourage".

Yes I do, but if you want to get the result you asked for it's one of
the possible solutions. Would you prefer that I'd simply replied to your
thread and said, "sorry you can't do that" and ended it there, or is it
actually OK for me to try and suggest approaches and configurations that
will get you the setup you want? I kinda presumed the latter was the
right approach.

>> So PA really is not the owner of /dev/snd/*. It merely listens to what
>> consolekit and udev say and adheres to it.
>
> So does the X-server, I presume, and yet they have the (xhost +...) option.

OK, so here is my Xserver analogy.

The user who is active has the display in front of them and can see
their applications right?

If another user is permitted access to the xserver, that user (even if
they are not the "active" user in consolekit, can run their app and have
it appear on User A's display right?

But if User A becomes inactive and, say, user C logs in. What happens to
users A and B? Their applications can still run, and they can still
produce their GUI, but you can't see it because the physical display is
busy dealing with user C's desktop and applications.

Everything in user A and B's world proceeds as normal (tho' maybe not GL
applications which need DRI access), but they are essentially invisible.

Well this is *exactly* the same as pulse and the sound card. If user B
were able to access User A's pulseaudio server, it would still only be
consumale (generic term meaning visible for X and audible for pulse)
when user A is "active".

So really the whole xhost + command does not solve your problem. It
merely deals with an authentication of one user to another's PA daemon.
It doesn't handle whether that PA daemon itself has the rights to use
the audio device. Just like with /dev/dri, access to /dev/snd/* is
controlled via the ACLs set by consolekit and udev. It's actually no
different.

>>> So, using such option breaks normal "user switching".
>
>> But you don't *want* normal user switching.... Have I completely missed
>> the point? I'm confused why you bring up this "disadvantage" when in
>> actual fact you really want to exploit this behaviour to get concurrent
>> access.
>
> Why I don't *want* normal user switching? Perhaps I am not in your set of
> "pre-analyzed groups"?

Normal user switching means that the active user has access to the
machines resources. If you don't want that approach then good on you,
I'm not trying to stop you, but please appreciate that this is deviating
from the normal case. I'm trying my damnedest to tell you how to do it
but you keep trying to shoot down my suggestions saying that because
it's not part of the recommended setup then I shouldn't recommend it.
Not quite sure what else I can do other than to just lie to you tell you
"it can't be done"...

> Let's accept the concept that this is a computer in which several users
> work, not much, but they have accounts and use when needed. Being that the
> case, switching accounts and having sound work on each account is welcomed,
> and accepted as how "things should be". Having all users share the same
> pool of resources is not "a wise thing to do", as, even if I trust most of
> the users (to a certain extent), there is no guarantee that they will not
> do something foolish. Not that they will be "evil", just dumb sometimes.
>
> Then, this "small" issue of a flash bug appeared. Flash "upgraded" to
> version 10, but in the process, left out 64 bit support. This system,
> sadly?, is a 64 bit system. So the options were: live with the security
> flash bug, use nsplugin, or create a 32 bit chroot. Leaving the system for
> all users with a "open hole" is out of the question. The nsplugin is a
> sorry mess now, changes all the ia32libs to get "almost" working. So, the
> only viable solution was to use a chroot setup.
>
> Having the undesired task of setting a chroot 32 bit for flash, I decided,
> well, then, let's get the browser out of any access to the local user files
> and rights, let's use a different "user account" for the browser.
>
> Here is where I am getting to this brick wall of "not possible" to share
> sound between users with PA.
>
> Well, really, to several possible solutions, none of which seems to be the
> "right one".
>
> Perhaps I have to re-think all this over *again* .

You should perhaps have explained this initially. This is a very simple
setup and one that the start-pulseaudio-x11 script I mentioned above
makes more or less automatic.

Pulseaudio can store various configuration variables as properties of
the root X11 window. Clearly the browser (running as another user) will
have access to the X11 root window. In that case the browser will have
access to the properties that pulse has set.

If start-pulseaudio-x11 has been run then:
xprop -root | grep PULSE
will return some results.

e.g. here is says:
PULSE_COOKIE(STRING) = "LOTS OF TEXT HERE"
PULSE_SERVER(STRING) =
"{6cb2a4b2bd6df042e57dablah}unix:/home/colin/.pulse/6cb2a4b2bd6df042e57dablah-runtime/native
tcp:jimmy:4713 tcp6:jimmy:4713"
PULSE_SESSION_ID(STRING) =
"6cb2a4b2bd6df042e57dablah-1280059215.515847-2115367457"
PULSE_ID(STRING) = "603@6cb2a4b2bd6df042e57dablah/31539"

These are all the details needed for a given user to connect to my
Pulse. Provided that user can access my socket path
(/home/colin/.pulse/6cb2a4b2bd6df042e57dablah-runtime/native) at a
filesystem level, then all will be well. The cookie string will be used
to authenticate that user and sound will "just work".

I've used this approach several times and you should be able to get it
to work without much trouble too.

>>> I rather see this "sniffing" issue rather "inconsequential" IF user1
>>> specifically has to validate user2 access. After that, user1 will know,
>>> as he has enabled such access.
>
>> Yeah, that's a valid argument. If the the user has allowed access then
>> they've allowed access and anything that happens, happens with their
>> tacit agreement (tho' me agreeing with the principle, doesn't change the
>> fact that creating such a system would require a significant amount of
>> reworking of design and code of various Linux subsystem all for the 10
>> users who have ever moaned about this!).
>
> There goes again: I am one of 10 users who ever "moaned", thanks!!.

What's wrong with moaning? I do it all the time about things I don't
like and want to change.

> Perhaps the rest of users just haven't realize they have such need, yet.
>
> Or you are just: "not prepared" to deal with this reality?

There is simply not the need to do what you want. There are often other
solutions to the problems you present and the fact is I've detailed
three that would work fine. Suggestion number 2 is likely the right one
for your scenario, but utilising the X11 properties for user B's access
rather than manual configuration.

Personally, I don't think running the browser as a separate user is
necessary and think it would save a lot of hassle to simply not bother.
I run a 64 bit system and have a several 32 bit programs installed,
including web browsers without the need for any chroots. I thought all
modern distros managed to split out 32 and 64 bit libraries into a)
different file paths (i.e. /usr/lib vs. /usr/lib64) and different
packages (e.g. lib64pulseaudio0-0.9.21-27mdv2011.0.x86_64.rpm vs.
libpulseaudio0-0.9.21-27mdv2011.0.i586.rpm) to allow for simple
concurrent and non-conflicting installs? If not, then complain to your
distro as this seems like a lot of work to put into something that
should just work fine (and does for me in my distro).

>>>> 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) and that is
>>>> therefore the case we really want to get right, even if other, more
>>>> exotic, scenarios are not easy to achieve.
>
>>> Gee, following the "lead" of Windows, which wants only one user to use
>>> the computer to make sure each user pays for the software, doesn't seem
>>> the right "recipe" to apply to a multiuser Linux system.
>
>> I find it highly bizarre that people automatically assume that just
>> because windows does something, that it's wrong. So many linuxy people
>> do this and to do so automatically is arrogant in the extreme (not
>> suggesting this is the case here tho'). I'm as happy as the next linux
>> geek to bash windows, but I'm no so crazy as to assume that everything
>> on windows is automatically "wrong" regardless of how much I may
>> disagree with certain other aspects.
>
> Were did I "Automatically assumed"?

You didn't. I said very clearly above that I was not suggesting that
this was the case here. Consider it a general purpose rant.

> Not having the capability for several users to access the graphical screen
> (X-server) is a Windows limitation, much alike as not having access to the
> sound system for several users.
>
> I am very sorry you fail to realize that.

But only one user can *see* the screen at once. So why is it so
unreasonable that only one user can *hear* the sound at once. Having
multiple users display their apps on the screen at the same time is one,
thing. It's totally possible (as outlined three different ways and
clarified above) to do the same with audio, but it doesn't change the
principle of user *switching*. You've now made it clear that you are not
talking about user switching at all and thus a good chunk of this
discussion is moot.

What you are suggesting in the context of user swithing would be like
having multiple users with *separate* X11 desktops, but being able to
"zoom" out and see them both at once (like mutli-player games do on
consoles). That is not something that X can do (at least not easily that
I know of - it would require a system wide composition system) and it's
not something pulse does.

> Nothing to do with it being windows, it could be called Unix or Mac, it is
> just a real limitation. Important or not?: that is a "value judgment",
> which you have done some time ago, it seems, as I am one of "10 people who
> 'moaned' about this", thanks again.

I really don't think that we are talking about the same thing now. I
hope my X11 examples have shown that.

I really don't think that in the context of user switching (which is
what you originally stated) that the need for multiple users all
outputting sound at the same time exists as a main-stream problem.

When both users will be sharing an X11 display anyway, the fact that
PA's configuration can piggy back on to X11 root window properties
solves a *lot* of the problems in achieving what you want. The only
problem you need to solve yourself is to ensure that filesystem
permissions allow user B to talk to User A, native PA socket and
everything will work fine (as stated above).

So I don't think you are even in the group of now 9 people who really
did moan about wanting concurrent sounds when user *switching* (and yes
the numbers are made up to emphasise my point!)

>> The fact of the matter remains that user switching is something that
>> Linux has done for a long time, but so has Windows and OSX and more or
>> less they've all behaved in the same kinda way: by making the crazy and
>> outlandish assumption that the user sitting at the keyboard and looking
>> at the monitor is the one that should have full access to the machine's
>> resources. Is that really such a crazy concept? Sure there *can* be
>> multiple users who want to use the devices at the same time, but this
>> use case is a tiny fraction of the percentage of the overall audience.
>> Things *can* currently be made to work the way you want it, but we very
>> much focus on the common case. Is that really such a bad idea?
>
> Where have I said anything about "crazy and outlandish"?

You didn't, I did :p Sarcasm may be the lowest form of wit, but it's all
I've got.

> Could you leave you pre-judgments out of this?

I will if you will :p You presume that your use case is the most
important thing in the world. That's a fair enough position to come from
as you're currently fighting with it and it's the highest priority thing
on your agenda right now. I've got the benefit of having heard this
argument before. If you had brought a new use case up, then I would have
tried to understand it and then address it rationally, but, sadly you've
not brought a new use case, so I will fall back on all the reasons for
why it's not done this way. Sorry, but that's the way it goes.

> A "tiny fraction", huh? That is exactly the mentality which drove me away
> from windows. Exactly the bully of not wanting to hear user problems or
> just pushing it aside by "not being in the use case we cover", thanks.

This is open source. I am motivated to do the stuff I do because I think
it's right solution and it works for me. I've listened to the arguments
many times and you've not brought anything new to the table. Perhaps I
could have explained the arguments better and for that I would
apologise, but it's certainly not about not wanting to hear the user
problems.

And besides, what is wrong with the "not being the user case we cover"?
What's wrong with a tool for a purpose that fits that purpose? If all
cars had to have wings so they could fly too, then a lot of pedestrians
would have their legs broken as they walk down the pavement and get hit
by wayward wings...

If I wonder into an ice cream shop and ask to by petrol for my car, I
wouldn't seriously expect them to sell me it because that's not what
they do.

(two car analogies in as many paragraphs... I think I get a prize for that).

> It seems broken mentalities sprout everywhere.

Thanks very much. I hope one of the three solutions I've given you will
ultimately work for you, but if they don't then you can attribute it to
my broken mentality.

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/]

_______________________________________________
___________________________________________________

Posted on the Pulseaudio-discuss mailing list. Go to https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss to subscribe.

#10

10-08-2010 11:51 PM

Pulseaudio-discuss member admin is online now

User

#11

10-08-2010 11:55 PM

Pulseaudio-discuss member admin is online now

User

#12

11-08-2010 06:04 AM

Pulseaudio-discuss member admin is online now

User

#13

21-08-2010 04:09 AM

Pulseaudio-discuss member admin is online now

User

#14

23-08-2010 10:10 AM

Pulseaudio-discuss member admin is online now

User

#15

23-08-2010 03:40 PM

Pulseaudio-discuss member admin is online now

User

#16

24-08-2010 09:39 AM

Pulseaudio-discuss member admin is online now

User

#17

24-08-2010 07:38 PM

Pulseaudio-discuss member admin is online now

User

#18

25-08-2010 09:49 AM

Pulseaudio-discuss member admin is online now

User

#19

25-08-2010 12:08 PM

Pulseaudio-discuss member admin is online now

User