Actually, when audio is a concern, I'm quite happy with the audio(4)
framework of sio_open(3) and friends.
I've just finished a remote PMR control app where real-time audio is
needed, and all the bells and whistles are up to the task: multiple
devices support -I'm working with four Behringer USB audio cards-,
full-duplex, mixer control et al.
Sure and additional framework should make easy porting other projects to
OpenBSD, but as far as audio programming is related, native audio
support is nicely implemented and rock solid.
Just missing some samplerate convert not relying in aucat! So I can use
it on several devices at once, but that's a patch -filtering is the hard
trick- I'll work into :)
Regards!
Dani
Jacob Meuser escribis:
On Sun, May 24, 2009 at 07:48:27PM -0400, Predrag Punosevac wrote:
A friend of mine who is an avid NetBSD user kept complaining about how
bad is audio on NetBSD. After getting sick of hearing complains,
I asked on OSS mailing lists about OSSv4 support for NetBSD and OpenBSD.
I actually got a very interesting answer
http://www.4front-tech.com/forum/viewtopic.php?t=3133
I recall OSS being discussed on this mailing list after OSS went
open source and changed the license. Can Jake or any other developers
in charge of audio on OpenBSD explain the issues involved in porting
OSSv4 to OpenBSD?
I personally have fantastic experience with our audio but I would
think that OpenBSD could benefit at least from extra audio drivers.
Am I very wrong? Sorry for the noise.
audio(4) and all the current audio drivers would need to be
modularized to not conflict with OSSv4. OpenBSD doesn't use
modules by default, so users who would want to use OSSv4 would
be running an unsupported system.
I have tried taking small bits from 4Front drivers (for cmpci(4)
and azalia(4)), but it has not been very helpful, for various
reasons. I've learned more by looking at FreeBSD and ALSA drivers.
some of the 4Front drivers were developed under NDAs, so the only
"documentation" available to us is the driver source.
having 2 vastly different audio APIs is not helpful, at all.
arguably, OSSv4 would be a third (or fourth even) audio API that
we would be supporting, as OSSv4 is different than OSSv3, which
we already support with ossaudio(3).
even though OpenBSD and NetBSD share the same basic audio code,
there are numerous differences, starting with aucat(1) and
sio_open(3) and going all the way down to the low level drivers.
it appears this diversion is going to continue. I've tried
sending patches for simple bugs azalia(4) to NetBSD devs that
never got acted on, and they have a GSoC project to add support
for stream mixing in the kernel.
