gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSSound Commit


From: Stef Bidi
Subject: Re: NSSound Commit
Date: Sun, 23 Aug 2009 20:23:30 -0400

On Sun, Aug 23, 2009 at 5:45 PM, David Chisnall <address@hidden> wrote:
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.

I think OSS3 might pose a problem with the way I implemented NSSound.  I simply open a new device every time a new NSSound is sent -play.  As far as I understand, OSS4 handles this just fine, but OSS3 does not.  I was initially trying to stay away from having to do mixing (which I'm not too good at), but I might have to implement it after all (probably using what was in gsnd).

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).

Volume control is probably the easiest DSP operation (just multiply).  However, going from int to float to int is far too CPU intensive since the operation that does the conversion flushes the FPU's pipeline every time.  That's pretty much the only reason why I did not implement this in the AudioOutputSink class.

I also saw your comment on the 64-bit float.  I'm not really sure if there is such a thing when it comes to sound cards, but I know JACK uses it.  I had it there just to be complete but removing it won't be too hard.  I'm think simply having 8-, 16-, 24- and 32-bit int and 32-bit float is enough.

Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]