Hi Colin!
Thanks again for your detailed answers.
Am Mittwoch, 9. November 2011 schrieb Colin Guthrie:
> 'Twas brillig, and Martin Steigerwald at 09/11/11 10:43 did gyre and
gimble:
> > I would even do not have any problem when there would still be two
> > session based pulseaudio daemons just using dmixing for audio output
> > and grabbing input for recording explicitely. Only then there would
> > need to be some mechanism to decide which user gets recording. It
> > could by on a case base, so that Pulseaudio grabs input sinks only
> > on demand. And it should not be possible to record the dmixed audio
> > output by any user. Each user may only record his own audio output.
> >
> > Maybe thats a workable idea?
>
> It's possible. Just configure the default.pa to use dmix for it's alsa
> sink, and then ensure that you set the profile for the udev-detected
> card for each user to an input only profile such that it doesn't create
> a sink too.
>
> Of course dmix adds overhead, messes about with timing, and screws up
> sample rate conversion (and uses the shitty quality resamplers too),
> but other than that it would work OK.
>
> Unless the card supports hardware mixing, the recording would only work
> for the first user to get it as the other tasks would fail. This is of
> course a hideous setup with horrible connotations for handling
> gracefully in UIs etc the cases when the audio doesn't work... It's
> certainly not something I'd be able to recommend with a straight face.
As I wrote already I use the system wide approach for now. Partly due
cause the above didn?t sound too encouraging.
But about a sensible policy on how to decide who can do recording and
system wide playback I had some dieas:
1) recording:
- its with the user whose session is active exclusively
- except one other user whose session was active before and who started
recording at that time is still recording something, cause it could even
make a recording unusable when it is interrupted abruptly
So for me hard per session switching on how may record does not make any
sense at all. I do not know whether Pulseaudio actually does it that way,
but if it does, this could cause serious data loss due to unexpected
interruption of recording. Consider that family computer. The father
records something from radio or another source that does not repeat and
locks his sessions while the recording goes on. The daughter switches to
her session => the recording stops and is cropped.
2) playback:
I see two uses cases with - for me - not yet determined frequency of usage
among computer users / or even just Linux users - I know this is to far of
a definition for usability aspects:
a) per session playback for web videos, flash, voice chat and stuff like
that and possibly also regular music playback
- for example the family computer
- or a computer for a couple where everyone wants to hear different music
b) system wide playback for music
- for example a geek laptop with mpd
- a someone using two users to separate data and settings of applications
I even bet the highest frequency of usage might just be: Thats my computer
and I use it for me alone - or thats a dedicated machine for just playing
audio and everyone who comes by puts the stuff in the playlist he/she wants
to hear. For this usecase it doesn?t even matter whether Pulseaudio runs
user or system wide. (Except for the current limitations.)
My idea about this is to have different sinks:
- a user wide
- the current rules for per session setup remain
- a user cannot record the user sink of another user
- a system wide
- any user can output to the system wide output
- maybe the first one how does locks it as long as he/she uses it?
- any user can record from the system wide output
- any user who wants can subscribe to the system wide or unsubscribe
from it
- when subscribed he hears it, it is mixed into his personal audio
output
- when not subscribed he doesn?t hear it
Another approach would be to define who may share audio with whom.
Now on how to implement such a thing with simplicity in mind... if
Pulseaudio relied on the underlying sound system for mixing, this could be
done nicely within the session based approach. Then the dmix plugin for
ALSA would need enhancements for better quality and timing as far as I
gathered. If Pulseaudio insists on doing the mixing on its own, I do not
see any easy approach except for using some kind of a system wide daemon -
probably additionally to the session based ones which would then talk to
the system wide one.
For me it looks like the current incarnation of the per session setup also
has some limitations in the usecases it supports. This is more severe as
this covers use cases which tended to work out of the box before. And for
the record case a hard per session switching may even cause serious data
loss - lost recordings - a thing which IMHO should be solvable also with
the per user session approach
Ciao,
--
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
