Re: NSSound Commit

[David Chisnall]

On 23 Aug 2009, at 20:57, Stef Bidi wrote:

> On Sun, Aug 23, 2009 at 12:20 PM, David Chisnall <address@hidden>  
> wrote:
> I've committed an OSS sound sink, but not connected it to the build.
>
> Wow, that was pretty fast!  I notice you used AudioOutputSink as  
> your class name, which I'm guessing is because I used that for the  
> libao sink.  The reason I used AudioOutputSink is because the "ao"  
> in libao means audio output.  Since these sinks and sources will be  
> able to co-exist in the same system I think it would be best to keep  
> them unique (ie: OpenSoundSink?).

Ooops - the class name was meant to match the file name.  I fixed that  
in r28524.  My brain was in neutral.  It's more or less copied from  
the equivalent class I wrote for MediaKit, just modified a bit to  
support your interfaces.  I tweaked it a little bit because I know  
that someone is going to try using it on Linux with OSS3 and a  
SoundBlaster 16 or SoundBlaster Pro, which required the ioctl()s to be  
in a fixed order, so it closes and reopens the device every time you  
change the format.  Given that your typical use case doesn't do this  
in the middle of playback, I didn't think that would add much overhead.

> PS: That OSS backend looks pretty cool, and does more than the libao  
> one, so it should definitely be used as the default for platforms  
> that support it.  We'll absolutely need someone supporting the  
> configure script, cause I plan on adding more sources and sinks in  
> the future and can only do basic things.

Unfortunately, the 'does more' bit is a bit system dependent.  On  
platforms with 4Front OSS4, like Linux/OSS (but not Linux/ALSA with  
OSS emulation or Linux with the in-tree OSS3) or [Open]Solaris you get  
per-application volume controls.  With FreeBSD 7, the volume ioctl()s  
set the global volume (there are some patches that fix this, but I'm  
not sure they made it into FreeBSD 8).  With OSS3, the volume control  
does nothing.  In MediaKit we delegate to the (étoilé) SystemConfig  
framework for this case, so maybe we can steal some code from there  
for this case (or just not care about it).

David