On 04/ 8/10 02:10 AM, Darren J Moffat wrote:
On 07/04/2010 18:39, Albert Lee wrote:
The PreSession script could check the ownership of /dev/audio and only
call "audioctl load-controls" if /dev/audio is already owned by the
user. It is a bit of a drag to follow all the /dev/audio symlinks,
but it would be smarter.
Something that may have to be addressed eventually is dynamic switching
between multiple X sessions ("fast user switching"). Maybe a note
should be
made that the design here will have to be revisited if this is ever
supported.
That would be more relevant to the currently running case PSARC
2010/119 "Console User" assignment, logindevperm and virtual console
update. Since that case actually ensures that with multiple X sessions
only the first (ie :0.0 display) has access to the audio device
anyway. If the intent is to allow "switching" of the audio devices
then both this case and PSARC/2010/119 need to coordinate and both
probably need updated specs. However I don't believe that is the
intent because taking away the audio (or other logindevperm assigned
devices) on "fast user switching" could actually cause applications
currently running to fail.
Oh wow.
I'm working on something that could be a fix for that. Basically, we
can switch the plumbing *underneath* the application pretty easily now,
and direct the other session to a "sink". We could also provide mixing
of all applications if that is more desirable.
I think we ought to have a conference call to discuss this in more
detail... there are multiple options here and I'd really like to try to
tackle this correctly.
One policy assumption you could make is that users will want the mixer
preferences for every device rather than just the primary to be
remembered
if AUDIODEV isn't set - in that case 'audioctl list-device' could be
used.
This would be the least surprising behaviour if it becomes possible to
dynamically change the primary audio device in the future.
I agree this is a very good point. This is particularly important
when there is "builtin" audio and USB attached audio as well,
especially since having the "wrong" volume on USB attached headset
could actually be damaging to ones ears.
Having said that, this case even if it only does $AUDIODEV is still
better than nothing since I suspect (but have no evidence) that most
systems (that don't have Sun Ray DTU's attached) only have one audio
device.
Most, yes. All, no. However, in the future, /dev/audio will always be
the most appropriate desktop audio device. We'll use hotplugging
underneath a virtual device. But, the save/restore of settings for
individual devices won't be appropriate for that.
Actually, as I sit here thinking about this, I think the save and
restore of audio settings for audio devices should apply to *all* audio
devices for the system -- or rather all audio devices that the user is
being granted access to (which is usually just all of them, but I think
other options exist under device allocation.)
We should have a chat to talk about this further.
- Garrett
_______________________________________________
opensolaris-arc mailing list
[email protected]
