On Mon, Dec 15, 2008 at 11:02:30AM -0800, Bart Smaalders wrote: > Garrett D'Amore wrote: > >Sebastien Roy wrote: > >>It sounds to me more like the SunRay audio architecture is inadequate to > >>support 3rd party tools. Perhaps that should be fixed rather than > >>require audio software developers to have to add Sun-specific code to > >>support SunRay.
Still, the proposed 3-line application fix is sustainable for now and should not be rejected unless there's a desire to force virtualization: > >That's a much, much bigger task. And it is indeed one we are looking at > >doing for Boomer, because the current architecture doesn't work with the > >OSS apps. > > > >Basically, this is a problem of applications "assuming" that /dev/audio > >is always sufficient. For a situation like Sun Ray, this simply isn't > >the case. > > Pushing device virtuallization onto the applications seems broken; the > SunRay team should pursue device virtualization in Solaris more > aggressively. +1 And not only for SunRay, but also for Virtual Consoles, as well as any form of multiple seats that might be supported besides SunRay. I.e., /dev/audio should be a pseudo-device in the mold of /dev/tty, and there should be an "acquired default audio device" equivalent of "acquired tty." And in the case of Virtual Consoles the audio device should mute sound I/O (not just output, but inputs too!) for applications not in the currently active console (interactions with console locking need some thought too). Yes, I know: "not this case." Nico --
