On 23 Aug 2009, at 20:57, Stef Bidi wrote:
On Sun, Aug 23, 2009 at 12:20 PM, David Chisnall <[email protected]>
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
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
