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 :} -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
