Francois ‘mmu_man’ Revol has released a preliminary port of the Open Sound System to Haiku/BeOS. “I have the pleasure to announce I have ported OSSv4.1test to BeOS. It’s not finished yet, but it runs and plays some sound. The goal is to use its drivers to get wider audio support for Haiku, the Free software rewrite (under BSD/MIT) of BeOS.”
Last name should be Revol…
In any case, the only major drawback I see here is that it’s GPL/CCDL and therefore will conflict with Haiku’s chosen MIT license decision.
Fortunately, it appears Francois intends to get the changes ported back into the OSS repo trunk so that anyone wishing to compile this for BeOS/Haiku should be able to do so with minimal efforts.
It still remains to be seen how well it can be adapted to the backend of the media kit…
(Edit: corrected license statement above)
Edited 2007-06-27 23:09
Yes, but the CDDL is very friendly license wise. It doesn’t force all software linked to it to be distributed under the same license (unlike the GPL).
Just like the MPL (Mozilla Public License) the CDDL is based on, you can link it to anything without worrying about the license (assuming the license of what you’re linking it to permits it).
Edited 2007-06-27 23:45 UTC
CDDL is incompatible with the GPLv2, which existed well before the CDDL!
So saying that the CDDL is linking friendly license wise is false..
Incorrect, the CDDL is not incompatible with the GPL.
The GPL is incompatible with the CDDL.
The CDDL does not forbid linking with GPL code, the GPL does.
The GPL states that anything linked to it must be distributed under the same terms, the CDDL does not.
It does not matter which license came first.
Edited 2007-06-28 13:14
Semantics. The fact is that the GPL came out 1st, and the CDDL was released in a form that knowingly was not compatible with it. In fact there was quite a bit of reporting at the time that it’s incompatibility was one of the major features in Sun’s eyes.
If I were to write a license today that said you can link code licensed under this to anything else as long as you don’t give it the same rights that CDDL gives to code, would you really blame the CDDL license? Or would you just blame me?
If I were to write a license today that said you can link code licensed under this to anything else as long as you don’t give it the same rights that CDDL gives to code, would you really blame the CDDL license? Or would you just blame me?
You, because by doing that, the license would be saying “you can’t have these restrictions” which is essentially why the GPL is incompatible with many licenses that are considered “free software” but yet remain incompatible.
Remember, the CDDL doesn’t specify what restrictions you place on *other* works. It only specifies what the restrictions are on files distributed under it.
The key thing here is that the CDDL does not restrict what you can do with other files that are part of the same work. The GPL, and your hypothetical license, does.
Edited 2007-06-28 14:40
With all of this porting from other operating systems (the FreeBSD network compatibility layer comes to mind), Haiku R1 should be a decently compatible little bugger when it comes to hardware.
This is a very good thing. I always thought Haiku was going to be extremely picky when it came to hardware until after R1 was released and it attracted more devs.
I am amazed at how quickly someone ported Open Sound to BeOS. Looks like the port took a little under 2 weeks since the release and that gives shows you how portable the code is. We would love to see someone port OSS to MacOSX
We don’t expect the licensing to be an issue. BSD licensing will be resolved as soon as our lawyers can draft the contributor agreement. Since code is coming in under a variety of different licenses, this is the reason why BSD was initially left out.
We’re also working with a few hardware vendors to get us an NDA release so that we can open source drivers like Maudio’s Delta and Revolution drivers.
Edited 2007-06-28 00:31
Get me a mac
Really, it’s quite portable indeed, once you figure out the build system, but that’s because it has to work around Linux not having a clean driver interface.
Here is a screenshot under Haiku:
http://revolf.free.fr/beos/shots/shot_haiku_oss_001.png
Doesn’t load the drivers yet, shows a bug in the kernel.
Support for my Delta 2496 would be awesome! Does anyone think they can convince Steinberg to finish their BeOS port of Nuendo???
By the way, iZ have said themselves that they use BeOS in their RADAR products. Does anyone know anything about this?
http://www.izcorp.com/
haiku:
great news. I too had worried about hardware support in Haiku, but that seems to be getting better by the month.
@ 4front:
I rather wish you’d opened OSS sooner, before Linux invested countless hours in Alsa: so many that they aren’t likely to throw them out to move back to OSS. A shame really, it would be nice to have the same sound system across platforms, and OSS works quite well (tried it last week). I went back to Alsa though, as OSS just doesn’t integrate too well.
The .deb installs sourcecode, from which kernel modules are then compiled and added to your system. The debian way would be to have something like OSS-base.deb for all the kernel independent stuff and OSS-kernel*-module.deb for each of the kernels debian ships, and for custom kernels an OSS-kernel-source.deb that installs the sources, from which OSS-yourKernel-module.deb is compiled, after which OSS-kernel-source can be removed.
If someone in debian picks it up something like that will probably be created, but it’s still a pain compared to something that comes in the kernel already. That would be far preferable to me (it’s why I go to the trouble of using an intel 2200bg mini-PCI wireless card in my PCI using desktop computer: the driver is in the kernel instead of needing to be added in like madwifi or realtek etc).
I’m afraid the ship has sailed as far as recapturing the majority of Linux users is concerned, and that’s a shame.
Nonetheless, glad you’ve opened up, as it is a boon to other OSs as we see with Haiku here. So thanks, even if I wish it had happened sooner!
I have to agree that it is a better system
for linux but doesn’t integratre well. You can get virtual sound
in a guest os in vmware that mixes with host
sounds with Opensound . Alsa
fails here and in so many ways on a simple AC’97 integrated chip. No I am not going to buy a sound card as in thisday those should be for professionals only. How about
an OSS only java applet? Again alsa wont mix the sound with other apps.. <alsa-rant-off>
But as you said it doesn’t integrate well and several
things, like system sounds, failed on Fedora core 7
when i installed it.
They say they plan kernel integration. If this pans
out then all the problems may be solved.
You’re kidding me right? This is a bit off topic, but really onboard sound hardware stinks. You’ll actually see huge improvements in game performance with a dedicated sound card.
A bit more on topic, I haven’t used OSS for a very long time, I think since probably the 2.2 kernels. It did work pretty well from what I remembered, but I always bought Creative Labs cards, because they were well supported (up until the X-Fi). But around the time of the 2.4 kernels, I always tried to get the Alsa drivers installed, and was very thankful when they were integrated into the 2.6 kernels.
But now that OSS is open sourced, it is very nice to see other open source operating systems getting good hardware support.
Yes it may stink but I think it doesn’t have to stink
THIS much. On-board ac’97 has been improved
upon in newwer on-board cards by the way.
I am not a heavy gamer so I don’t think
buying a sound card is justified. I just
want to listen to music and get sounds from my
virtual nexenta box at the same time. And maybe
from a light chess applet too.
This should be easy but isn’t. If you shop for a computer in Korea where I live, they dont come with sound
cards by default. Even gamers find newer on-board to be adequate now(under XP)
But this is off-topic
On board sound cards “used to” stink. I know this is redundant, but for example, I have a several years old nForce 3 based motherboard. I can do 5.1 in games very well, even better than my previous PCI cards.
And on board cards (sound, IDE, USB, etc) are not there only for price reasons, but actually PCI performance (or lack of it) is the main driving force.
[ PCI is a 66MHz 64-bit shared bus. More than 5 devices on it causes severe transmission collisions and bandwidth bottleneck. So motherboards incorporate special pathways for on-board components to ease the load ]
PCI on standard desktop motherboards is 32-bit 33 MHz. PCI-X expands the bus beyond that, all the way up to 64-bit 133 MHz.
The problem is not alsa itself, but applications using alsa, that is alsa can do software mixing (which is what you are looking for):
http://alsa.opensrc.org/index.php/Dmix
There are basically two problems: some apps are only OSS aware (you have to use aoss), and some alsa apps are badly programmed which prevent them from using dmix by default (lack of good ALSA docs for a long time didn’t help, though).
The problem with ALSA is the applications
as you said but it’s a deeper problem than many realize.
I use aoss all the time but it’s impossible
to use that on a java applet as these are not
command-line launched. Java
is oss only to maintain cross platform compatibility.
It’s a ridiculous situation and made me try alternatives
like FreeBSD. Unfortuntely, though their sound system gives less problems they are just not there yet
for java and other essential things in a desktop.
Edited 2007-06-28 06:04
I understand the “problem” of alsa being Linux specific, but I really don’t see any technical reasons not to add ALSA support for Java. I mean, java on mac OS X does not use OSS either, but CoreAudio, and nobody complains that you have to use Mac OS X specific sound subsystem ? You could argue that the real problem is that Linux has two subsystems, and should only have one (eg forbids completely oss). If you use only one, no problem.
This is the eternal debate – OSS does mixing in kernel space – ALSA does it in user space. But ALSA doesn’t really help its case when you start presenting asoundrc files like this one for the Audiophile 2496.
——————————-
pcm.!default {
type plug
slave.pcm “dmixer”
}
pcm.dmixer {
type dmix
ipc_key 1024
slave {
pcm “hw:0,0”
format S32_LE
period_time 0
period_size 1024
buffer_size 8192
rate 96000
}
bindings {
0 0
1 1
}
}
ctl.dmixer {
type hw
card 0
device 0
}
pcm.dsp {
type plug
slave.pcm “dmixer” # use our new PCM here
}
ctl.mixer {
type hw
card 0
}
————————-
OSS does the mixing transparently – so you don’t have to worry whether you’re on a SBLive or Audiophile or an Intel Onboard device.
But that said, ALSA has high quality drivers and support more devices – its impossible to compete unless you’ve got vast resources and vast amounts of cash to buy all kinds of laptops and motherboards – this is why we have open sourced OSS – to get back into the game.
We are going to collaborate with ALSA folks because OSS is never going back into the Linux kernel – it’s cross platform and we want it to remain as a separate entity – much like X Windows. We are going to be a choice for developers – to program to OSS or to ALSA or GStreamer or Jack.
It’s never too late to open source and we will show our commitment to the community by fixing past mistakes. We will continue to to be business friendly – if some company wants their product to be supported and pay us – we’re not going to be foolish and turn down good money – after all Programmers have to also eat! (TM) 🙂
Edited 2007-06-28 06:28
> We are going to be a choice for developers – to program to OSS or to ALSA or GStreamer or Jack.
That’s a recurrent problem with *nix, and mostly Linux because it’s so (sometimes too) open… consistency.
The only consistent layer is the POSIX one, noone being able to enforce anything above this, which is good for choise, but bad for simplicity of use :^)
many audio APIs, many libs, many toolkits, many desktops…
BeOS/Haiku is different in that respect as it has a higher level coherent API, apps being forced to use the Media Kit to talk to the media server, which in turn uses addons to talk to hardware, like the MultiAudio addon to publish soundcards to apps, but also the Legacy addon that can use drivers that implement older ioctls, without having to throw apps away. I can also write an OSS addon and have it use OSS just right away without touching apps. And of course media_server does the mixing in userspace, without problem because it has exclusive access to the devices.
Sometimes having a proprietary OS vendor to impose APIs has good sides
Edited 2007-06-28 06:50
Funny how you don’t actually need an .asoundrc for dmix since ALSA 1.0.9rc2.
Released on 2005-03-24.
Is OpenSound System seen as a multi-audio device by Haiku? Or does it by-pass the media preferences?
Not yet, it has its own ioctl commands, so it’s not seen by the media kit. Also, because it publishes several devices for each card (mix0, pcm0…, midi0…) it might be much simpler to write an OSSMediaNode to adapt to it than adapting it to the multiaudio API. We’ll see.
As a side question, did you ever find a good set of docs on writing a multi-audio sound driver? Just looking at the present drivers are leaving too many questions unanswered for me to get one going.
Also thanks for pointing me to interrupt drivers instead of using Sleep(), by decoupling the feeding of sound data into a large ring buffer and having the interrupt driver read out when it is ready I can now support 100Khz with ease, even on my slow 233PII laptop. I still have some timing issues, but I am thinking adding a time stamps to every single sound sample to handle it, but that seem like overkill.
Not really, looked into some drivers but not much. Also there are 2 versions of multi-audio, the haiku one having a difference on some things that weren’t documented by Be.
Hi,
I remember how BeOS, with its real time design, was good at playing with sounds. I m interested in Haiku because I hope it will allow me to have a light and fast responding system to record and edit sound. For now, I have been using Linux distros like Ubuntu Studio with an Edirol UA25 USB sound card (24 bits@96Khz with Jack and ALSA). I could sometimes experience “plop” while playing in full duplex but it globally works.
My question is : will Haiku be able to perform better with OSS ?
OSS has support for some USB devices, but the port doesn’t yet, I’ll first concentrate on PCI cards. Besides Haiku usb isn’t finished yet (close to).
Hi François,
writing your own OSSMediaNode like you said would be the best soltution I would say. And it shouldn’t be that hard seeing you have the MultiAudio node to start from. In any case… awesome work!
Best regards,
-Stephan
Yes it’s much easier to do than convert drivers or oss itself to multiaudio API… and I already wrote an ESDSinkNode (was quickest way to get sound from the laptop, using a linux server and the amp
).
GPL trolls were an extinguished species