It's been some time I've been annoyed by a problem that google reveals is not so uncommon, but for which a solution seems to be quite hard to find: letting the user currently active on a seat to use the sound card, as long as no other really uses it. I also vaguely recall that this used not to be a problem - in the old pre-alsa days, maybe ?
The basic problem seems to be that any program playing sound directly though alsa wants to open /dev/snd/pcmC0D0p, but that only one is allowed at any time. If only those apps released the device when they don't need it any more, that would be all fine, but it appears not. Those sound daemons around (had a quick look at jack and pulseaudio, which seemed to me good choices) suffer from the same problem, since (at least in their default setup) they run as the user wanting to play sound, and open the alsa device for their exclusive use. Pulseaudio apparently has an option to run as a system daemon: that looks like a way to solve the problem... except that mode is not the recommended one, and that (as a result ?) no obvious doc in the package explain how to use it at all. So the question is: is there any current method for solving this problem with the software we have ? I suppose the problem is that the client apps don't ask the alsa lib to release the device - if they do, then that would simply be a but in the alsa lib not to free the hw resource, and thus probably a simple fix. Then it would be quite painful to fix all those apps to behave properly - although we could want to set this as a release goal for squeeze+1. An easier solution, since daemons like jackd see to be in widespread use, to just make them behave properly and release the alsa device when they have no use for it (maybe after some timeout). As long as all clients first try to connect to jackd before trying to open the alsa device directly, it looks like that would work as expected. How does that sound ? Best regards, -- Yann -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
