Bart Smaalders wrote:
> Garrett D'Amore wrote:
>
>> 6) This seems to be leading us toward the road that we should, once OSS
>> APIs become available everywhere, deprecate the use of Sun audio for
>> mixer and control applications.
>
>
> Your proposal seems to be a very reasonable approach for
Garrett:
> Note that if we only have to support GStreamer, and if GStreamer is
> willing to identify the Sun Ray session ID for us (e.g. with a new
> ioctl, or by opening a different file), then we could make those APPs
> work fairly easily. I was trying to find a solution which didn't rely
Garrett:
> I think that as part of our implementation, we will
> convert the main control applications to the full featured OSS API, and
> just punt on this problem -- control applications using Sun audio(7i)
> won't be able to adjust surround levels, etc.
>
> 6) This seems to be leading us to
Artem Kachitchkine wrote:
>
>> to be able to identify the Sun Ray session a process should be
>> running under, which means some new API and probably a new field or
>> two in the uarea.
>
> And subsystems other than audio could benefit as well.
Indeed. And if we design it right, it could have ap
> to be able to identify the Sun Ray session a process should be running
> under, which means some new API and probably a new field or two in the
> uarea.
And subsystems other than audio could benefit as well.
-Artem
Brian Cameron wrote:
>
> Garrett:
>
>> I think that as part of our implementation, we will convert the main
>> control applications to the full featured OSS API, and just punt on
>> this problem -- control applications using Sun audio(7i) won't be
>> able to adjust surround levels, etc.
>>
>> 6)
Bart Smaalders wrote:
> Garrett D'Amore wrote:
>
>> 6) This seems to be leading us toward the road that we should, once
>> OSS APIs become available everywhere, deprecate the use of Sun audio
>> for mixer and control applications.
>
>
> Your proposal seems to be a very reasonable approach for the
Garrett D'Amore wrote:
> 6) This seems to be leading us toward the road that we should, once OSS
> APIs become available everywhere, deprecate the use of Sun audio for
> mixer and control applications.
Your proposal seems to be a very reasonable approach for the
next Solaris release: continue
Neal Pollack wrote:
> On 11/03/08 07:41, Garrett D'Amore wrote:
>>
>>
>> 7) Potential power(9e) regression for legacy device drivers. Right
>> now, for some legacy SPARC devices (e.g. audiocs, audiots), our work
>> to convert these devices to "Boomer native" devices has been done,
>> but we hav
On 11/03/08 07:41, Garrett D'Amore wrote:
>
>
> 7) Potential power(9e) regression for legacy device drivers. Right
> now, for some legacy SPARC devices (e.g. audiocs, audiots), our work
> to convert these devices to "Boomer native" devices has been done, but
> we have not done the work to make
I wanted to record some potential issues we've found. This stuff needs
to be in our case materials before final commitment review, but at some
level, we've not decided how to handle all of them, so I'd appreciate it
if anyone has any special insight.
1) Port definitions and Sun audio(7I). Sun
11 matches
Mail list logo
