Nicolas Williams wrote:
> 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."
>
And we're looking at this kind of virtualization for Boomer phase 2. I
need to start working on case materials, because we're going to need
some underpinnings in the kernel to track Sun Ray sessions... (Another
ID that is inherited across fork(), sort of like a process group...)
More on that later. In a new case. :-)
-- Garrett
> Nico
>
