Garrett D'Amore wrote:
> Sebastien Roy wrote:
>> On Mon, 2008-12-15 at 10:30 -0800, Garrett D'Amore wrote:
>>
>>> Chris Liu wrote:
>>>
>>>> Let me explain respectively.
>>>>
>>>> OSS - libsndfile has not much to do with OSS. It mainly focused on
>>>> processing data from one format to others. It does not like to deal
>>>> much with hardware or operating systems. The only exception may be
>>>> sndfile-play. Sndfile-play is one of three tiny utilities it
>>>> provides, which only writes audio data directly to /dev/audio (on
>>>> Solaris), which is standard audio device on Solaris. On SunRay
>>>> sndfile-play wont work properly because SunRay client uses another
>>>> audio device specified by $AUDIODEV. However, it is not a main
>>>> purpose of libsndfile.
>>>>
>>> If this is the case, can we skip integrating sndfile-play, at least
>>> until it honors Sun Ray?
>>>
>>
>> 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.
>>
>
> 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.
By the way, use of $AUDIODEV has been a standard technique since at
least Sun Ray first shipped. Its not new on Solaris.
In situations where there is more than one audio device, /dev/audio
won't necessarily point to the right device anyway. The fact that the
3rd party app can't use a different audio device is a severe shortcoming
in the app.
-- Garrett
