Slashdot Mirror

Others would possibly have OSSv4 implementations if the company didn't have a nutjob take on what the GPL means. At least one of their developers thinks that if you run a closed source app that needs sound like say Doom3 then you have to buy one of their commercial licenses. Even RMS doesn't have such an expansive idea of what the GPL does and does not do:

http://4front-tech.com/hannublog/?p=8

The really good part is in one of the comments posted by one of the devs:

The point is that we (4Front) are the owners of the copyrights of OSS. We have the power to define the terms for usage of OSS. The terms are that you can use OSS "for free" if you use it from GPLed applications. Otherwise it will be "for a fee".

And this is for a sound stack that is supposedly distributed under GPL terms. Last time I heard, writing to /dev/dsp is not linking. Since what they publicly say is in direct contradiction to the GPL, I take it to mean that ONLY their commercial licenses have validity.

Yes, they DO have the power to "define the terms of usage of OSS" but they DO NOT have the power to rewrite the GPL. Since what they want is a trialware license then they should remove the GPL boilerplate from their downloads and substitute such a license.

A more complete quote from your link:

Q: Is everything in OSS open sourced?

A: No. There are three drivers that have mosty been written by the hardware manufacturers. We are not permitted to release their sources unless their authors as us to do so.

Also some parts of the envy24 and envy24ht drivers contain some code written under NDA. We have not yet received the approval to open source the code from all manufacturers. So these drivers cannot be open sourced just now. If we don't get the approval in reasonable time we will distribute these drivers with the offending code stripped from the sources.

Finally there are some effects in the old softoss driver that are not included in the source packages. We will make the decision about their future later. At this moment it looks like we will remove the softoss driver from the OSS package so these effects will not be used in OSS anyway.

We reserve the right to include some "closed source" drivers only in our binary distribution if the hardware manufacturers refuse to give the programming specs without NDA. Our policy is to promote open source but not to enforce it. We will let hardware manufacturers to decide if they like to select the commercial distribution mode instead of the open source one with much wider customer base.

http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2411
OSS now released under BSD license

Postby dev Fri Jan 04, 2008 8:36 am
We are releasing the FreeBSD version of Open Sound under a BSD license and we hope that the BSD community steps up with ports for NetBSD and OpenBSD and enhancement to FreeBSD ports.

http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2139
Open Sound System is now open sourced!

Postby dev Thu Jun 14, 2007 4:16 am
We're releasing the source code for Linux/Solaris/FreeBSD/Unixware under CDDL/GPL licenses - get the source at http://developer.opensound.com/

We thank our paying customers for keeping us in business all these years - and we now hope that no one has a reason to not use OSS because it isn't open sourced.

Best regards
Dev Mazumdar

http://www.opensound.com/wiki/index.php/Building_OSSv4_from_source

Contents
[hide]

* 1 Building the OSS sound system from source
o 1.1 Requirements to build the source code
o 1.2 Building the source
+ 1.2.1 Obtain the OSS source
+ 1.2.2 Change to the source directory
+ 1.2.3 Extract the source tarball
+ 1.2.4 Create a build directory, and make it current
+ 1.2.5 Run the configure script
# 1.2.5.1 Notable configure switches
+ 1.2.6 Run make build
+ 1.2.7 Packing Open Sound System (

A more complete quote from your link:

Q: Is everything in OSS open sourced?

A: No. There are three drivers that have mosty been written by the hardware manufacturers. We are not permitted to release their sources unless their authors as us to do so.

Also some parts of the envy24 and envy24ht drivers contain some code written under NDA. We have not yet received the approval to open source the code from all manufacturers. So these drivers cannot be open sourced just now. If we don't get the approval in reasonable time we will distribute these drivers with the offending code stripped from the sources.

Finally there are some effects in the old softoss driver that are not included in the source packages. We will make the decision about their future later. At this moment it looks like we will remove the softoss driver from the OSS package so these effects will not be used in OSS anyway.

We reserve the right to include some "closed source" drivers only in our binary distribution if the hardware manufacturers refuse to give the programming specs without NDA. Our policy is to promote open source but not to enforce it. We will let hardware manufacturers to decide if they like to select the commercial distribution mode instead of the open source one with much wider customer base.

http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2411
OSS now released under BSD license

Postby dev Fri Jan 04, 2008 8:36 am
We are releasing the FreeBSD version of Open Sound under a BSD license and we hope that the BSD community steps up with ports for NetBSD and OpenBSD and enhancement to FreeBSD ports.

http://www.4front-tech.com/forum/viewtopic.php?f=19&t=2139
Open Sound System is now open sourced!

Postby dev Thu Jun 14, 2007 4:16 am
We're releasing the source code for Linux/Solaris/FreeBSD/Unixware under CDDL/GPL licenses - get the source at http://developer.opensound.com/

We thank our paying customers for keeping us in business all these years - and we now hope that no one has a reason to not use OSS because it isn't open sourced.

Best regards
Dev Mazumdar

http://www.opensound.com/wiki/index.php/Building_OSSv4_from_source

Contents
[hide]

* 1 Building the OSS sound system from source
o 1.1 Requirements to build the source code
o 1.2 Building the source
+ 1.2.1 Obtain the OSS source
+ 1.2.2 Change to the source directory
+ 1.2.3 Extract the source tarball
+ 1.2.4 Create a build directory, and make it current
+ 1.2.5 Run the configure script
# 1.2.5.1 Notable configure switches
+ 1.2.6 Run make build
+ 1.2.7 Packing Open Sound System (

I'm not qualified to answer all of your questions and concerns. I DO KNOW that OSS4 handles USB speakers. I have no speakers plugged in to my sound card, all I use is the USB headset.

I also know that OSSMix can mix your multiple streams.

Since I don't switch between multiple input/output devices, I can't say.

As for analog/digital speakers, I'm lost. I THINK that you can plug in both, and even switch between them, but hell, I'm not an audio buff, so don't start me lying. ;^)

My best advice is, visit the 4Front forums, and search or post your concerns: http://www.4front-tech.com/forum/index.php?sid=dadb22fbf3e8e7037a272e7e241fa1c5

OSS was deprecated because 4front pulled the rug out from under users and started demanding money for binary-only versions, and it was easier to write an entire API from scratch instead of trying to fix the crap they'd left in the kernel.

OSS4 is never going in because 4front has a dangerously wrong idea of how the GPL2 works and think they they have the right to infect applications using this API with their licence.

Do not want!

Sorry, I still don't get it. They've been building OSS4 for years, it seems a good tool for the job, and yet it cannot be included in the kernel or distributed by various distros ? If they add trouble understanding GPL 5 years ago, ok, but isn't there any communication between 4front and the rest of the community on the subject. Weird.

OSS was deprecated because 4front pulled the rug out from under users and started demanding money for binary-only versions, and it was easier to write an entire API from scratch instead of trying to fix the crap they'd left in the kernel.

OSS4 is never going in because 4front has a dangerously wrong idea of how the GPL2 works and think they they have the right to infect applications using this API with their licence.

Do not want!

The OSS developer appears to be schizophrenic.

Either that or they just don't care.

http://www.4front-tech.com/forum/viewtopic.php?p=12200#12200

It fixed all my problems with sound, anyway.

http://4front-tech.com/hannublog/?p=9

OSS on Linux often did NOT work. Try playing sound with the original Quake 3 on Linux with a driver that didn't support mmap. Free drivers for hardware often didn't seem to exist or were very fiddly to get going.

For some reason which I have yet to understand, they picked option 2 and ALSA was born.

And that is why your comment was poor criticism and comes off as a rant. Good criticism looks up the reasons WHY people did stuff and then gives feedback on those rather than just guessing. You could have answered back against each of the points mentioned in Cleaning up the Linux Desktop Audio Mess Linux Symposium paper rather than just saying "don't know".

Starting with FreeBSD 4, the kernel did mixing in software if the sound card didn't support it.

Doing audio software mixing in the kernel has been frowned upon in the Linux land for years (to do it really well you want to use floating point). I could be wrong but I believe that Microsoft have moved most of audio mixing out of the kernel with Vista so I do not think this view is as extreme as it used to be.

It may be the old OSS 3 version, that stayed in the kernel for a long time but wasn't really maintained after ALSA became new and exciting.

When you have two implementations people can choose which to maintain. I hear that support for devfs was lower after udev went in...

a lot of systems started shipping with userspace sound daemons

Userspace mixing daemons were happening long before ALSA was shipped by default. esound was definitely shipped back in 1999. Userspace daemons also add support for things like network audio...

There is real, detailed critism of ALSA's flaws on an OSS developer's blog. This is far more useful than what you've posted here.

Now don't get me wrong - there are definite issues with Linux audio and these issues have driven some people away from Linux entirely. However those issues are not the ones you are talking about (my hope is that things are slowly improving too). Most users don't care about program portability (OSX and Windows have different audio APIs after all) - they just want working sound on their system. I don't see OSS being the solution to that...

Comparing Gnome 2.24 to Win2000 is a joke. Heck, comparing it to WinXP is a joke. Gnome 2.24 is a modern desktop just like Windows Vista is, only faster. Same bling available. Better consistency. Better features than WinXP (though probably not Vista). In fact, using Windows XP makes my ears bleed after only a few minutes.

Stop. You are switching back and forth on your comparison environment. Pick one. Since 2.24 came out today, stick to Vista since that is the most recent. Comparing to XP would necessitate choosing a Gnome from that year. Something I rather imagine you would prefer to avoid.

Gnome has strict accessibility and localization requirements and has since 2.2. Windows wasn't even localized in Thai until Gnome adoption there forced it to be, and even then they just half-assed the "start menu" and nothing else. A generation of Thais learned to do computing in a language they didn't understand.

This is irrelevant to the comparison of desktop features, bugs, and usability.

ESD never had a problem with mixing stuff if you used it instead of OSS or ALSA. It even mixes stuff locally and outputs it to another computer if you want it to. Maybe your problem is that you didn't know what you were doing ....

It could be that, or it could be the well recognized and horrifying mess that is the linux soundsystem.
Here is some reading for you:
http://insanecoding.blogspot.com/2007/05/sorry-state-of-sound-in-linux.html
http://4front-tech.com/hannublog/?p=5
http://jeffreystedfast.blogspot.com/2008/07/pulseaudio-my-last-post-on-topic.html

I used Gnome for years, and the inability to maintain consistent audio levels across multiple applications was always frustrating and painful (literally in some cases, thanks totem!)

Don't resort to ad homimem attacks. It cheapens your argument and hides the potential value of any possible truth.

Gnome configures everything for Gnome and always has. Since Gnome runs on a large number of operating systems, it doesn't deal withthe underlying system, and you'll have to be specific about which one isn't configurable and take that up with the OS vendor. That's not the job of a cross-platform desktop.

This is entirely true, but it is still not an excuse for the poor consistency within Gnome and the inability for small things like keeping my taskbar arranged like it was before I logged out. Seriously. That is internal to Gnome and there is no scapegoat here.

Since we're playing this game, these are the places Windows doesn't live up to Gnome:

1. UI consistency
2. Context menus
3. Window management
4. Virtual desktops
5. Select and middle-click to paste
6. Deskbar applet (pre-Vista)
7. User filesystem layout
8. Menu layout
9. System messages
10. Mime handling
11. Panel layout
12. See them all

Gnome vs. Win95 or Win2000? Pshaw!

UI consistency works better in Windows Vista. Actually, it worked better in Windows 98 than Gnome does. When I arrange something in one of those, it stays that way. When I add something to the menu it stays where I left it. When I change my quick launch icons, they remain in the order I put them in. Amazingly, Mac OS X also got this right despite being newer to the market than Gnome as well.

Contextual menus work just fine in Windows. They have for quite a while. They work pretty darn well in Mac OS X. In other news the sun rose in the east this morning. I don't know what you mean or where you were going with this, but righ

It's not entirely clear what you are trying to do, but one of the sweetest ways to 'visualize' wave data is to output it directly to /dev/audio and LISTEN to it as a sound waveform (actually /dev/dsp would work better for this, because it expects uncompressed data). All you have to do is open /dev/dsp, convert your data to a series of 8 bit integers, scaled to where 255 is the maximum and 0 is the minimum, do a write() on your data to /dev/dsp and viola! You have music! If you want to change things like the bitrate, look at the open sound system page.

>With the atitude that the frees/wan project maintains, we will never see freeswan merged with mainstream kernel... hell... they still refuse to take patches from us citiziens and residents (that includes linus)

Not to mention they refuse to include support for the faster (but less secure) type of IPSec, thereby causing me to run Win2k on my router for a short while. I believe they even say it's fully valid to use IPSec in this manner (in fact it's part of the spec, so without it they shouldn't be calling it IPSec, IMHO), but they just don't want to support it in the faq, 100% due to attitude.

Developers may have a right to any attitude they desire, but they should understand their software is just going to be replaced (in the mainstream) by software from someone with less attitude. Let's hope that's what happens with freeswan. I think we don't need another OSS-style crippled set of kernel software. (Did they move to ALSA yet? I hope so!)

Just my 2 cents.

If anyone, ANYONE can show me a OSS compliant document format that even approaches the usefull ness of the .doc format...

Try TeX.

(Yeah, I know it has nothing to do with OSS, but .doc is a text document format.)

You forgot these drivers.

now, if i remember correctly, there's an exception in the linux license to allow binary-only loadable modules, but i'm not too clear on that part.

This is a very important point, Linus has made it clear that he intends for people to be able to make binary-only LKM's. See 4Front, makers of the OSS sound drivers, for an example. I also believe that some hardware vendors have done this, but I don't have examples handy.

In any event, worst case you have to GPL the code that you put in the kernel, but you only have to provide it to people that you have sold units to. Of course they can distribute it to anyone they want. More likely you talk to the copyright holder of the code you have changed and hammer out an a different license between the two parties.

Oh, and the GPL is good for business. One should open up their code to their customers, but there is no reason to allow your competitors to take your code without giving back. It's a standoff, you have your code, your competitor has your code. Any change they distribute they have to share with you, and as the owner you can do anything you please with the code.

HTML should have a ramble tag . . .

SLab is an excellent multitrack recorder/mixer. It is not up to snuff with ProTools yet (though no program is on any platform).

Other Linux audio related links include (sorry if some links are bad, I haven't updated this list in awhile):

Multitrack audio recording/mixing:
Ardour
Slab
Snd

Midi Sequencing:
Jazz++
Rosegarden
Brahms (I THINK this is a sequencer)

Sound editing / effects processing:
MixViews
ecasound

Audio creation (synth emulators):
Ultramaster RS-101 and Juno6 CSound
Cecilia (requires Csound)

Notation:
Lilypond
Rosegarden
Mup

Awesome pages with links to everything you wanted to know about Linux audio:
Applications for Open Sound System
Sound and MIDI software for Linux

I know of Open Sound System's, "a set of device drivers that provide a uniform API across all the major UNIX architectures," answer to ReBirth: Gsyn. It's a good start but more needs to be done before we get to the professional level.

Arrgh, I hate Cakewalk, too. I've never heard of anyone actually using it professionally, just hobbyist stuff.

Here's a nice list of sound apps for Linux:

http://www.4front-tech.com/ossapps.html.

There's some really nice stuff there.

> If you use an MP3 player, which is it?

mpg123 -s foo.mp3 | aplay -m &

ac
--
OSS != OSS.

Monkey see acronym. Monkey repeat acronym.
---------------------------------
"The Internet interprets censorship as damage,

I *REALLY* hope CL decides to support ALSA, rather than the OSS/Free drivers shipped with the standard Linux kernel... I am hoping perhaps this will convince Linus/Alan to dump the pathetic OSS/Free drivers they currently use, and replace them with ALSA... For all the good things I could say about the drivers that come with the standard Linux kernel, like the (generally) outstanding SCSI/IDE/Parallel port drivers it has, I think OSS/Free is probably the only exception I can find... In my case at least, I found ALSA to be vastly more stable and feature-rich than OSS/Free... I tried and tried and tried to get OSS/Free to work with my GUS PnP, but the most I got in the end was sound that kept skipping, and the driver spewing out tons of DMA/IRQ error messages to my terminal, even though I had them setup CORRECTLY. When you consider this, plus the fact that OSS/Free requires RAM just to do DA on the AMD Interwave-based PnP card (which is absolutely pathetic, IMHO, since ALSA does DA without the need for RAM), I think this says that all around, OSS/Free *STINKS*. Needless to say, the last straw with me came when I was told by one of the OSS/Free developers that they "might consider" PnP support, but that I should pay for OSS/Professional if I really wanted to get this feature (since 4Front-Tech, Inc. sponsers the development of OSS/Free)... That was the last straw as far as I was concerned... They can say that OSS/Free is GPL'd if they wish, but IMHO, it is meaningless if all they can tell me is that I must pay for a proprietary binary-only version just to get something half-decent. That is NOT my idea of open-source... That is what I call CRIPPLEWARE, masquerading as open source. Bah. Let's hope CL makes the right decision.