[pulseaudio-discuss] possible policies for recording and for playback (was: Re: using pulseaudio with simultaneous playback from mutiple X sessions)

[Martin Steigerwald]

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