Re: Sound on multi-user system
Harald Gutmann wrote:
> If it's just sound you want to have try mpd aka music player daemon.
The problem is not just with music. Viewing a video in firefox is
enough to have the full stack locked by the browser, preventing any
other user to get sound (and in the case of badly-written apps, to
even use that app).
> Your problem sounds for me to be very specific, because most of the people
> won't use one soundcard for several users
Well, it's true that google does not show that many occurences of
complaints, but that may be because it is hard to find a proper set of
keywords for a search.
OTOH, the desktop situation in the last 10+ years has evolved from the
point where you could not launch a second X display (at least on my
old Cirrus card at that time), to the point where all desktop
environments prominently allow another user to open an X session while
the display is locked. So it would be rather strange that I have the
only one Linux-using family which complains about the sound being
stolen by any user :).
Adrian Knoth wrote:
> I'm not sure I completely understand the problem in question. Normally,
> if a user logs in, a lot of magic with console-kit (or policy-kit?) is
> triggered to grant access to the soundcard. From there on, the user more
> or less "owns" the card.
Possibly *kit would do "something" - like setting permissions, and/or
udev rules for this, I guess from a couple of pages I found (not
looked at the actual conf).
OTOH, this can only work for devices that were not opened beforehand.
For those, Linux still lacks a revoke() system call (although every
now and then during the last 10y some brave soul tried to deal with
what seems to be a ungrateful job), so *kit cannot steal any device
which the former seat-user has left open.
> Do you now say that other users could also login and should get access
> to the soundcard without the first user logging off? Something like the
> "switch user" stuff modern desktop environments support?
Right, I'm saying that a user who locked the screen and went for a
walk has less rights to control the sound output than the one actively
using the console. Doing otherwise can be seen as a DoS.
The case of an app in a locked session still really using the sound
card is as much of a problem as those vast majority of existing apps
which did not close the device just in case they would need it again.
Although the latter case is the largest part of the problem, the
former seems to hint that any solution has to use a sound daemon with
control of the hardware, and which *kit can instruct that a user has
lost the usage of the console, and that his streams should stop being
relayed to the hw (that may of course be slightly more complicated
since in some case one may want to continue listening the sound
started by others, but I don't think this is the 1st thing to look at).
> I don't know if they somehow share access to audio, but I guess they
> should. We really need to talk to the pulseaudio guys to get this right,
> and I'm pretty confident that it's doable. (I'm not familiar with
> consumer desktops)
The very fact that pulseaudio has a system mode makes me confident as
well. Maybe there would just need some more integration to be done on
Debian side - if any app does not see how to access the pulseaudio
server, it seems it will currently happily try to access alsa directly.
> With regard to jackd: leave it out of the equation. jackd is for
> producing audio, it runs in very specific environments, let's think of a
> recording studio for a while. Switching users normally doesn't happen.
Well, AFAICT, jackd looks equally supported as a sound output as alsa,
arts and pulse - if not better than the latter two. Nothing in the
player's config dialogs, or in the package description, let me suppose
that it's dedicated to very specific environments.
| JACK is a low-latency sound server, allowing multiple applications to
| connect to one audio device, and to share audio between themselves.
... that speaks for itself :)
So is it really out of the equation ?
Maybe someone with the knowledge could write something in the wiki
(linked from the multimedia page, of course), about the various sound
solutions, and their advantages and inconvenients for various
situations. Currently no page matches "pulseaudio" or "jackd",
"sound" finds some pages but not much useful info. Especially
http://wiki.debian.org/SoundConfiguration seem to be really
incomplete.
> The sad thing is: everything mentioned above works on OSX, multiple
> users can access the soundcard, pro-users can start their pro-apps which
> go nicely side by side with the consumer tools and the lot.
The sad thing is, for me, that we probably lost this feature when the
default kernel stack switched from OSS-Lite to ALSA :}
Reply to: