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.
Pushing device virtuallization onto the applications seems broken; the SunRay team should pursue device virtualization in Solaris more aggressively. - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
