OSS is dead. Long live OSS!
The question often asked from me is: “OSS is deprecated so why are you still developing and maintaining it?”.
This is a short and simple question. However the answer is not short or simple. First of all we need to return some 10 years back in time.
Once upon a time in Linux there was a tiny sound subsystem called VoxWare (formerly known as the Linux Sound Diver). It was maintained by me and released under GPL for Linux (and under the BSD license for FreeBSD and some other Unix variants). That piece of code was included in the Linux kernel source tree. I was working on the code “just for fun”. However it become too difficult to work on the sound stuff in my spare time at the same time when working on some Windows projects for my living. I was contacted by 4Front Technologies and we desided to make our living with a commercial version of OSS.
Unfortunately it took too long time to find the proper procedure to support the GPL/BSD version and the commercial one from the same source tree. So a well known Linux distribution vendor got irritated and hired another person to create another version of OSS for them (without even asking me to do that). The result was rather different than my plans for the future so I had to quit as the maintainer of sound for Linux.
Since that moment the kernel (OSS/Free) and the commercial OSS versions have been maintained by different teams. Unfortunately the Linux kernel version of the API got frozen to the OSS 3.8 version while we continued the development of the official API. In addition the OSS/Free version was (unfortunately) restructured so that most of the common (device independent) code was duplicated in the individual low level drivers. This made it impossible to keep the kernel drivers up to date with the development made to the official OSS version. The result was that the kernel drivers got frozen to the 3.8 version forever, unfortunately.
Then couple of years later a group of fearless programmers had created an entirely different, incompatible and Linux-only sound API called ALSA. They pushed it to the Linux kernel tree and the old OSS/Free version was declared as “deprecated”. It was supposed to become more advanced that OSS/Free 3.8. It was released under GPL (only) so it seemed to be the right thing. However application programmers didn’t like the ASA API and continued to use OSS instead. It was necessary to declare OSS as “deprecated” to push application developers to support ALSA instead of OSS.
However even that was not enough. Application developers still preferred OSS. This was bad for ALSA because they had to provide OSS emulation. In addition the kernel level OSS emulation bypassed some features (such as dmix) that ALSA has implemented in library level. So the OSS emulation was later implemented in library level. However providing OSS emulation in ALSA caused some side effects. Developers of audio applications still refused to convert to ALSA because the OSS API was still available. So some even more agressive policy was needed.
So far the pro-ALSA Borgs have managed to get Linux distributions to compile most audio enabled applications with just the ALSA plugins enabled (all OSS support is stripped). In some cases the distributions even try to prevent users from removing ALSA and installing OSS by keeping ALSA’s mixer interface busy (the Gnome/GTK mixer appled is immediately relaunched if it gets killed). Or the kernel may have been modified to keep parts of kernel’s sound core included even sound support is completely disabled in kernel’s configuration. “We are the ALSA project. Your system will be assimilated. Resistance is futile”. Has anybody ever heard about “freedom of choice”?
ALSA was officially included in the Linux 2.6.0 kernel that was released for more than 3 years ago (December 2003). If ALSA is as great as they claim then shoudn’t it have completely replaced OSS in all applications during that time? Apparently that has not happened so far. Will it happen during next three years? I don’t think so.
There is a relatively small community of ALSA believers who have written most of the currently available ALSA applications (usually called ALSA this or ALSA that). Older applications still support OSS in addtion to OSS. Some newer ones ALSA-only because their developers have been told that the OSS API will disapper tomorrow. However the ALSA API is still almost completely undocumented (after three years of it’s release) so how can anybody expect that programmers could develop good applications based on it.
A funny detail is that even some key developers of ALSA now suggest that developers use the Jack API instead of alsa-lib (btw, Jack has a fully functional OSS plugin). Somehow this is starting to smell like Emperor’s New Clothes.
Back to the subject. The latest Linux 2.6.20 kernel still has the old and obsolete 10+ years old OSS version included. It’s being killed (for a very good reason). However it looks like we are getting a very long funeral. ALSA too has OSS emulation. In fact there are two redundant versions of it: one in the kernel and another implemented in library level. Both of them emulate only the now obsolete 3.8 API version. This is the dead and deprecated OSS.
However this is not the only OSS. We at 4Front have continued working on Open Sound System for all the past years. It has become the real Common Unix and Linux Sound Solution (CULSS). In addtion to Linux it’s now the official sound subsystem for all the Unix variants (other than MacOS). However for many Linux diehards it’s not an alternative because:
- It’s not GPLed (yet). Instead it’s a commercial product by some evil capitalist pigs.
- It’s not in the Linux kernel source tree so it doesn’t exist.
- It’s being used also by the public enemies of Linux.
- It’s “binary only”.
For the above reasons the benefits of OSS are widely ignored:
- It’s based on the widely known Unix/POSIX/Linux device model.
- It’s fully documented (OTOH some parts of the documentation are still under construction).
- The API is simple and compact which makes it very easy to use for programmers.
- It has been there for 15 years so practically all applications already support it.
- It’s kernel only.
- It’s designed to work under general purpose operating systems such as Linux and Unix. There is no need to use any special real time enabled kernels (they can be used but it’s not a requirement).
- The limitations and “idiosyncrasies” referred by ALSA’s marketing propaganda have been fixed years ago.
- Fully dynamic minor/major device number allocation which permits unlimited number of audio/MIDI/mixer devices.
- New device naming that makes applications immune to changes in the device configuration (installing and removing devices).
- Transparent virtual mixing that makes it possible for any number of applications to share the same physical audio device(s). This also works for recording and full duplex.
- Powerful device enumeration support.
Then we have ALSA which is:
- Not documented. Use the Source, Luke!
- The API is not compatible/similar with anything else (past, present or future).
- Very thin device abstraction.
- The API is designed for low/zero latency which makes it very challenging to use in normal applications that don’t have any latency requirements.
- Requires redundant layers libraries in addition to the kernel space code (alsa-lib, Jack). This causes increased memory requirements in embedded systems.
- Has enormous number of functions (1500+ couple of years ago). Majority of the calls have not been used by any applications (even many applications use different functions than any others). Massive number of unnecessary library functions increases the memory footprint even further. And what about the CPU consumption? And will anybody be ever possible to document (or even test) all of them?
- There are multiple (redundant) transfer methods for audio. How does the programmer know which one should be used with given hardware?
- Some devices use interleaved channels (for stereo and multich) while some others use non-interleaved.
- Static minor number assignment that causes waste of the available device/card space. Number of cards, devices and subdevices possible in the system is limited.
- Strange configuration file mechanism that requires degree in LISP programing to understand it.
- Sharing of devices is based on the dmix feature that nobody but experts can configure properly.
- The API is based on callbacks which requires deep programming knowledge from the developers. Gotos have been considered harmful for decades. Callbacks are even worse (in fact they are a re-incarnation of the famous come-from statement).
So which one should be declared as deprecated? As we are talking about APIs the right authority to make the decision are the application developers. They have their “freedom of choice”.
Actually it’s not nice to compare OSS against ALSA in this way so I don’t continue any further. However they have done the same for years (see ALSA’s web page (before they remove that stuff)). So I coudn’t resist. At least we have given them three years of time to discover and fix the above problems but nothing seem to have happened. And I didn’t even mention MIDI yet. Maybe I should do it next…
Regards,
Hannu
April 8th, 2007 at 5:22 pm
I have to agree with most of what you’ve written. I’ve never liked ALSA, and I think it’s rather hypocritical that the Linux community has chosen to adopt a Linux-only non-portable API for their applications.
Most developers I know like ALSA, but only because of the support for hardware it has and because there is no other option. They don’t usually care for its API or documentation.
OSS continues to be great because of its simple and consistent API.
April 14th, 2007 at 2:09 pm
Wonderful writeup! I have been wondering about some of these things for quite some time now =)
You can bet in the future the applications i write will be using OSS.
Finally when someone says “You should be using ALSA” and i ask why and they can’t answer, i’ll just send them here =)
Thanks!
April 14th, 2007 at 2:48 pm
I fully agree with your arguments and I have one more which is horrible:
If you use locales other then en_US (like de_DE, which use ‘,’ as decimal separator) you run into a horrible inconsistency. The driver use the locale settings and awaiting a ‘,’ in floating point values but the parser above reject the ‘,’ as illegal character.
I mean, how brain dead a developer has to be to implement a localized config file!?
So please continue holding OSS usable. (Even for 2.4 kernel)
April 29th, 2007 at 7:53 am
I beg to differ on many points you have mentioned in this blog entry. You begin by saying that, due to paucity of time, you had not been able to work on both GPLed and proprietary OSS implementations concurrently, which caused a well-known Linux vendor to make its own version WITHOUT ASKING YOU(!). I do not know if you are aware of the fact that is the very thing GPL (and I daresay BSD nowadays) is about: doing whatever you want with the code, as long as it remains free (as in freedom). I am not a programmer myself, but I think I can understand the sentiments many developers express: envy when their code is taken, altered and marketed as ‘improved’… however, it is the very thing you not only agreed to when licencing your code under the terms of GPL, but to promote as being desirable behaviour…
“End users” and “developers” see free (as in freedom) licenses in slightly different way. For users of some software “freedom” means that they don’t have to pay for the software if they don’t like. For the original developers “freedom” means that they have to give equal rights to every single user who uses the the software. So if there are 1 millions of users you will only have 1/1M of the original rights. If nobody pays anything then it means that your future income will be ~0.0/1M. This may be acceptable for students who do programming just for their fun. However for professional developers it’s a question of live or death. However what I’m critizising is that few companies are permitted to pick 1000’s of software packeges released under some “freedom” license and then make millions by selling that software for the few customers who are willing to pay. They can keep all the income in their ow pocket without no need to throw more than random peanuts to the original developers. So in reality “freedom” means freedom to print money for few companies and freedom to starve for the others. I will make a post about licensing in the future. (by Hannu).
You then proceed to mention many architectural shortcomings of ALSA, which I will not comment since I cannot say whether they are true or not, however I will say there are definitely some remarks I know are not true (e.g. small group of enthusiast writing all ALSA/ALSA-based applications). Then, you are bold enough to conclude this sort of comparison is not really nice, but hey, those mean ALSA blokes have been doing it for years (please, compare http://alsa.opensrc.org/Oss - outrageous, isn’t it?) Instead of writing this entry, you may have considered that, even though OSS is considered ‘deprecated’ in Linux community, ALSA brought much-needed competition and stimulated you and your company to produce even better product which, if proved as advanced as claim, will eventually prevail. Finally, I would recommend opening up OSS 4.0 and making it available under the GPL if you really want to make an impact in FLOSS/Linux community, since that’s one of the things that matters the most. By the way, thank you for great product, I am using it and am very pleased with its overall capabilities… Greetings, Petar
This is not entirely correct. I have been developing OSS for about 15 years now. The development has not been accelerated or altered by the introducion of ALSA. The original OSS 3.8 release about 10 years ago lacked many important features. I realized that long time ago and the missing features would have been implemented regardless of ALSA. Right, being non-GPLed is the main/only argument against OSS. That will be addressed in the future. Stay tuned, regards, Hannu.
April 29th, 2007 at 12:11 pm
I agree with all of your arguments about why ALSA is bad, and have plenty more of my own. It’s the classic case of the Windows mentality of “everything is a DLL” attacking and infecting Linux. No, everything is not a DLL, everything is a file! Whenever pro-ALSA topics come up in MPlayer discussion, I always try to point out how fundamentally wrong ALSA is. Now I have this article to direct link to.
With that said, I’m also quite angry that you allowed OSS to become “deprecated” by keeping the only maintained version proprietary. Proprietary software is absolutely not acceptable under any circumstances. This is non-negotiable. You say that it’s not GPL “yet”, so I still have hope that you’ll do the right thing in the future, and maybe still have a chance to get rid of this ALSA abomination with a truely viable alternative.
Long live OSS!
(the API, not the non-free implementation)
~Rich Felker, of the MPlayer team
June 10th, 2007 at 7:35 am
It seems the writer has intentionally mixed up commercial and proprietary. It would have been totally possibly for OSS to be commercial but open source.
June 10th, 2007 at 4:42 pm
I have mixed them more or less intentionally. Until very recently it just looked like open source licenses like GPL would make it impossible continue commercial work after open sourcing. When everybody has right to redistribute the sources for free then that kills any hope to sell the same software for even a minimal price. However after yet another review of GPL it appeared that this was misunderstanding. I will cover this issue in my next blog post. Hannu
June 15th, 2007 at 5:49 pm
but you finally get the point :)) of creating ALSA….
and the point is to force you to make OSS GPLed.
thanks
June 21st, 2007 at 1:58 pm
Hi.
I’m sorry to say this, but you’ve exaggerating some points.
First, the API to access sound hardware SHOULD be low level. That way if someone wants lowest possibly latency and control can have it. The rest of croud should use higher-level libraries which output to different interfaces (ALSA, OSS, JACK, ESD, ARTS, NAS, etc.) so that way I can have freedom and I can choose what I use. Now, so much different sound servers is truly a mistake since they mostly serve the same purpose, but sometimes I need something more specialised (JACK to interconnect audio apps or NAS so I can stream music to my laptop throught remote X11 session.) Audio API to access the soundcard is NOT for streaming the audio throught network, that is the job of a higher layer. That is why a high level API at the bottom is NOT needed, it should be LOW LEVEL, because there will be a higher layer anyway which will allow the flexibility that I’ve described. Now, not much developers really use ALSA directly. Why? I already described why - to let their users choose what they want; they use higher level ones, like for example GStreamer, which allows output do different backends.
Second, ALSA configuration files and dmix - the statement about requiring deegre in LISP to understand it and requiring an expert to configure dmix is obviously a lie. I don’t know LISP *at all*, and I’m no expert at all yet I’ve managed to succesfully configure dmix.
Third, limited embeeded systems (like portable music players, etc.) should access hardware directly or implement their own API tailored for their hardware; for other ones (DVD players, etc.) the memory requirements won’t make ANY difference. (Hundred kilobytes in this or that way is irrevelant when other things swallow up a LOT more)
Fourth, there is absolutely no need to use any realtime kernel with ALSA as you stated in OSS benefits. General kernel preemption applies as well to ALSA as to OSS.
Now then, I’m not by any means an advocate or fanatic of ALSA. I’m just pointing out mistakes in your post which are probably caused by your one sided reasoning.
Cheers.
June 24th, 2007 at 5:33 pm
>>> First, the API to access sound hardware SHOULD be low level.
OSS is in the lowest level which is kernel. You cannot get any lower without implementing the API (and the application) inside the hardware (firmware) itself.
>>>That way if someone wants lowest possibly latency and control can have it.
This is the most common misunderstanding. Level of latencies doesn’t depend on the abstraction level of the API but the buffer size. However the hardware environment and the operating system together define the ultimate limit for the buffer size. Below that the application will start to hiccup regardless of how low level or advanced the API is.
>>>Second, ALSA configuration files and dmix - the statement about requiring deegre in LISP to understand it and requiring an expert to configure dmix is obviously a lie. I don’t know LISP *at all*, and I’m no expert at all yet I’ve managed to succesfully configure dmix.
If you look at the ALSA/Linux related mailing lists and newsgroups this is the most common problem ALSA users have.
>>>Third, limited embeeded systems (like portable music players, etc.) should access hardware directly or implement their own API tailored for their hardware; for other ones (DVD players, etc.) the memory requirements won’t make ANY difference. (Hundred kilobytes in this or that way is irrevelant when other things swallow up a LOT more)
Sooner or later you will find that the kernel/drivers, libraries, applications and data no longer fit in the available memory. After this point it will become expensive. Of course this is not going to be a problem if the initial memory budget was oversized. Hundred kilobytes more may be pretty expensive if you need to double the memory size because of that.
>>>Fourth, there is absolutely no need to use any realtime kernel with ALSA as you stated in OSS benefits. General kernel preemption applies as well to ALSA as to OSS.
Once again using a preemptive kernel is the standard answer if somebody complains about hiccup in some ALSA applications. This is not necessarily an API issue (as you pointed out) but a cultural one. Applications written for ALSA often use programming techniques that require rapid response times while there are techniques that don’t require them.
June 26th, 2007 at 8:27 pm
A great article.
As a FreeBSD user, I’ve looked on in horror as the Linux people have started doing the very things they moan against windows for doing.
And, as with MS, they are using their relatively large distribution base to push things through instead of relying solely on technical merit.
Even with the ‘old’ OSS, we have a great system, that works well - especially on FreeBSD - it seems the justification for ALSA is related to flaws in the Linux free/OSS module, rather than the OSS spec itself - so, why didn’t they fix their module, rather that making what is basically a new “Linux only, effectively proprietry” API.
July 18th, 2007 at 2:00 pm
“so, why didn’t they fix their module, rather that making what is basically a new “Linux only, effectively proprietry†API.”
Cause this is the world of open source where nothing makes sense.
August 23rd, 2007 at 3:16 pm
Hello,
I had been using FreeBSD since ‘93 and the sound card support was OK for the casual user. However, I use Protools to produce music CDs and I had been looking for an open source replacement for Protools that would allow me to abandon Windows for my music work. In 2004 I found out about Ardour, and that was the closest thing to Protools that I could find. Therefore I scrapped FreeBSD in favor of Gentoo and started using Linux, while still struggling to find a replacement for my Protools. I did not know about alsa/oss issues and your blog is quite an interesting source of information about the related issues. However the end consumer does not care which technology is better, faster, has smaller memory footprint, better documented functions, etc. What we care about is to fulfill our music tasks with the least amount of headache.
So, in my opinion, you can make money by selling value services to end users. For instance I have recently bought EMU 1212 card to use with Ardour because it was listed as supported on alsa web site. I had been recompiling kernels and alsa-drivers since 5 days ago, and I am yet to hear a single sound out of my card. At this point I’d pay the same price I pad for the card ($150) for someone to hand me an installation file that will make my soundcard work with Ardour. I think I am a kind of user that is willing to pay for the software that works, and I think there many thousands of other users out there that would do the same thing, and hardly wait to switch to Linux sound production if it was not such a pain to do so.
Furthermore I think you have the responsibility to do the “dirty” political battles on the behalf on end users that are not in tune with what is going on. I think that your recent release of OSS4 under the dual license is what is necessary to promote this project, and bring it to the masses. I personally thought that the project was dead and obsolete.
In addition I would like to ask for your help in finding or offering some sensible solutions for sound professionals. We should be able to pick the best card on the market (that has released hardware specs), and we should be able to install the driver and use the sound applications right away. We should be able to record without our application stopping because of x-runs. We should be able to pick our operating system of choice and not be stuck with an operating system because that is what is needed to run my application.
I’d encourage you to partner up with people like those who created “Studio 2 go” which already sell a self bootable CD with well integrated Audio applications applications. Offer your “extended” driver package as an addition for that CD. For instance for extra $20-$50, you could offer drivers for many other sound cards, so that people can reuse the hardware they already have. People like myself, who do not want to recompile anything if they do not have to, would rather pay that money than spend much time tweaking compilation flags of the open source version of drivers.
Any comments, suggestions or directions would be highly appreciated.
October 5th, 2007 at 5:44 pm
I couldn’t understand some parts of this article OSS is dead. Long live OSS!, but I guess I just need to check some more resources regarding this, because it sounds interesting.
December 22nd, 2007 at 7:08 pm
Very Interesting article.
I did not know about any drama in the linux community so far!
But one thing is very clear for me.
After having spent countless hours sharing the sound card among programs, trying to understand .asoundrc, dmix, upmix (which you can get but not use), almost resolving to append aoss to every audio program I start..
just installing the oss .deb package on my gutsy ubuntu did the job!
Thanks a lot.
February 8th, 2008 at 10:02 am
“However for many Linux diehards it’s not an alternative because:
* It’s not GPLed (yet). Instead it’s a commercial product by some evil capitalist pigs.
* It’s not in the Linux kernel source tree so it doesn’t exist.
* It’s being used also by the public enemies of Linux.
* It’s “binary onlyâ€.”
Well, these were perfectly valid reasons to avoid OSS back then.
- Not being GPL’d is a liability for big Linux distributors such as Red Hat. Would you expect RH to pay royalties to 4Front per copy of RHEL shipped? They’re evil capitalist pigs after all, so they prefer open source. Maybe they could have bought 4Front and released the code, though. Probably it’s too late for that now, since they picked up ALSA…
Besides, home users don’t like to pay for drivers. They bought the sound card already, why should they pay extra? It’s not a sustainable business model, really. At least I don’t know of any company that sells sound drivers for Windows!
- Well, OSS was in the kernel, but 4Front took it propietary. What choice did the kernel devs really have but to develop their own sound system which does not depend on 4Front’s proprietary code? It’s not wise to depend on the goodwill of a single company, even if 4Front had the best intentions.
- I don’t think this was an issue, but who knows…
- Being binary made OSS maintainable only by 4Front. It’s the same reason why the Linux kernel developers ignore your problems if you use the binary NVidia graphics driver. Why tolerate binary blobs when pure open source development is just so much easier for everyone?
I think 4Front had understandable reasons to take OSS propietary (sound driver programmers have to eat, too), but other people had equally understandable reasons to develop ALSA.
February 10th, 2008 at 6:14 pm
I agree that ALSA is a very complicated system, and that the config file is the stuff of nightmares. BUT:
“However for many Linux diehards it’s not an alternative because:
* It’s not GPLed (yet). Instead it’s a commercial product by some evil capitalist pigs.”
There is ABSOLUTELY NO WAY that I would use a non-GPL sound system on any of my Linux boxes when a GPL alternative exists. It’s bad enough being held hostage to the whims of ATI or NVIDIA for video (although the resistance there is *finally* bearing fruit). I WILL NOT place myself in the same position for sound support.
February 23rd, 2008 at 2:13 am
So instead you choose to “be held hostage” to Linux/ALSA.
ALSA, it seems, it just a vendor lock-in technique, it’s supported on Linux and Linux *only*, other operating systems do not exists are far as ALSA is concerned (Searching for ‘bsd’, ‘macos’, osx’ etc. yield *no* results whatsoever on the ALSA webpage :/)
Ofcourse I also want a free sound system, but I also want a sound system that “just works”(tm).
As a FreeBSD user I have never even looked as the sound system, to be honest I don’t even know which system it uses, it has always just worked without any configuration.
Maybe Linux/ALSA is better than whatever FreeBSD uses? I don’t know, but I for one prefer a stable and working sound system over a “better” one.
March 3rd, 2008 at 3:32 pm
Currently I have 2 problems with OSS:
1. I do not want to see _ever_ that message: “Audio system is busy”. Wtf can be so hard to scale and sum some audio streams ? And why it took so long to get it done in 4.0 ?
2. If it is in the kernel, it _has_ to be open source. Until recently, for more than one year, I had to patch every single kernel I instaled because some “brilliant minds” at MSI had the “very lovely” ideea put their own, non-standard PCI adresses for the soundcard. Now, how would I do this on binary code ?
On the other side, I like it simple.
April 7th, 2008 at 8:34 pm
To clarify some recent comments:
1. OSS is now released under the GPL/CDDL/BSD licenses.
2. Multiple audio clients were available on OSS/4Front before v4.0, using the softoss module. (v4.0 uses vmix).
June 20th, 2008 at 5:57 am
Yes, I fully agree. ALSA sucks, I am not using it, hopes it dies,
But I also agree that your OSS:
* is not GPLed (yet). Instead it’s a commercial product by some evil capitalist pigs.
* is not in the Linux kernel source tree so it doesn’t exist.
* is being used also by the public enemies of Linux.
* is “binary only”.
I could not care less about Linux, it is only that its public enemies are also the public enemies of mankind.
June 22nd, 2008 at 5:50 pm
* OSS is GPL’ed. It has been it for more than an year now.
* OSS is also available under the CDDL and BSD licenses.
* It’s also available under the 4Front commercial license for customers who don’t want to be reastricted by the open source licenses.
* It’s not in the “official” Linux kernel source tree. However we will develop a version that can be dropped to the kernel source tree.
* OSS is not “binary only”.
July 23rd, 2008 at 6:21 am
[…] couple rants on Alsa vs OSS. Fuck. There’s a fucking awesome diagram that someone sent me of dependencies […]
October 5th, 2008 at 4:17 am
Umm, I’m just a lowly user, can’t code this stuff to save my life, but I just spliced OSS4.1 into Ubuntu Intrepid (now at Beta1) for one simple reason: under ALSA, plugging my headphones into my laptop caused sound to fade and then die over the course of about 10 seconds. Damnest thing ever, and there was just no way to get anybody’s attention at Canonical on this because we had no clue what module(s?) was/were involved.
At first we blamed PulseAudio because it’s generally weird and screwed up in Ubuntu, but that wasn’t it. Turns out doing “sudo alsa force-reload” got sound back on the laptop’s speakers once the headphones killed sound completely.
The sound hardware was the “snd_hda_intel” ALSA module and using the SigmaTel 9228 chipset. The issues were likely limited to that, but we don’t know for sure.
OSS4.1 completely fixed it, as installed per:
https://help.ubuntu.com/community/OpenSound
Kewl.
October 23rd, 2008 at 4:33 am
Hi Hannu,
As a FreeBSD user, I have been wondering for years what the whole ALSA deal is about. All it really meant to me was that it made it very difficult for developers to write portable audio software, so that basically translates to “you can’t use a new version of Rosegarden unless you use Linux”. Thankfully, most important audio/synthesis applications work with OSS, so I can run snd, pd, csound, and other applications on FreeBSD, just as NetBSD or maybe even Solaris users are.
I’ve never had any problems with multiple audio channels on FreeBSD, or used a sound server, or anything like that, and I don’t get the hype behind “low latency” when that means your buffers are so small that mp3’s hickup at the slightest problem… Now, I see the benefit of that for synthesis applications like Csound or Puredata, but some kind of clever method is needed to switch between these types of applications.
You seem to really know your stuff, and I hope that people see the light and start using OSS again. (Then maybe it wouldn’t be so hard to port applications like Rosegarden, Ardour, etc… to other operating systems)
I am grateful that you offered a BSD licensed version to the BSD community. Given that at least on FreeBSD, an implementation of OSS is used, it would seem a logical step to incorporate more of the 4.0 code and/or API in the audio sources. I also agree completely that a well documented API is more important than being open source. (especially considering that in many cases the BSD folks can’t even use the alsa code at a kernel level due to the GPL being incompatible with any other open source license, the BSD license in this case — given that, how are third party developers supposed to document something which makes them risk infringing on others’ copyrights?). So I don’t expect good ALSA emulation on other operating systems than Linux to happen very soon, if ever. (by all accounts from the perspective of a user of an operating system that is not distributed under the GPL, ALSA does seem to be quite proprietary)
Ah if FreeBSD supported MIDI keyboards, I would never need Windows again…
P.S. Not that I’ve dealt with any of ALSA’s mixer utilities, but as a Scheme and Lisp programmer, I will tell you that Lisp and Scheme are probably far easier to deal with than the ALSA mixer tools (and infinitely easier to learn than C/C++/etc..)
It’s amazing how the things you’ve said specifically in this blog entry still fall on deaf ears. People are still repeating the “binary only” nonsense, even after you have confirmed is no longer the case.
Regards
November 16th, 2008 at 7:27 pm
It is so funny to see some FLOSS fanboys ranting at hannu without knowing ANYTHING about realistic application programming. They usually have one of the following symptoms:
1. You have to be opensource, otherwise you are doomed. (even I never wrote one single piece of usable software.)
2. Abstraction can solve the underlying mess.
3. If you software is really good, you will get popular. So if that software is really so horrible, why is it popular now?
November 24th, 2008 at 7:49 pm
chef depot dutch process cocoa free typing tutorial eisley mp3 country homes for sale in beloit on line wills lousianna
benigh blue enterprise low cholesterol low sodium chicken and dumplings ritz-carlton and inner harbor iq test free
November 26th, 2008 at 4:34 am
crossover rate german restaurants ct wb and san antonio spurs and austin confederate war gallagher summary euchlid chemical
strawberry livejournal icon christian rosakis singles adoption at el faro criss angel made in japan jack johnson cd 2005
December 10th, 2008 at 5:36 am
lindsay lohan new music video [URL=http://fixpasxbu.ifrance.com/news-1867.html]lindsay lohan new music video[/URL] [url=http://fixpasxbu.ifrance.com/news-1867.html]lindsay lohan new music video[/url] [url]http://fixpasxbu.ifrance.com/news-1867.html[/url]
December 10th, 2008 at 5:37 am
eddie egan and associates [URL=http://kamada.strefa.pl/page1623.html]eddie egan and associates[/URL] [url=http://kamada.strefa.pl/page1623.html]eddie egan and associates[/url] [url]http://kamada.strefa.pl/page1623.html[/url]
December 10th, 2008 at 5:37 am
movie look whos talking movie look whos talking [link=http://ezpascal.strefa.pl/movie-look-whos.htm]movie look whos talking[/link]
December 13th, 2008 at 1:03 am
[…] couple rants on Alsa vs OSS. Fuck. There’s a fucking awesome diagram that someone sent me of dependencies […]