4Front Technologies is in the business of supplying UNIX sound card drivers for AIX, BSD, Solaris, SCO, HP-UX, Linux and other systems. The company has maintained a particularly amenable relationship with Linux for several years: 4Front's Hannu Savolainen has provided the kernel sound driver and the system sound applications programming interface. The company also sells an enhanced supported version of the kernel driver.
With warm greetings to Dev Mazumdar and Hannu Savolainen, we begin:
David: When, where, why and how did 4Front go into business?
Hannu: Actually, our story began in August 1992 after I got Linux working for the first time. I had started writing a Sound Blaster driver for Minix, but dropped the project for various reasons. I ported it to Linux and released the first hack after a couple of weeks. What happened after that is a long story.
Then in September or October 1994, Dev contacted me. He was selling an MCA-based sound card and asked if he could port my driver to AIX. After a few e-mail messages, we decided to join forces and port the driver to everything that moves.
Initially, our idea was to sell commercial Open Sound System (OSS) only for operating systems other than Linux, since there didn't seem to be any market for OSS/Linux. However, we decided to release OSS/Linux because the software was ready. We just had to check that there were no copyright issues.
Dev: I began writing the sound drivers for the Creative Labs Sound Blaster MCA on IBM's new RS/6000s that had MCA slots in 1992/3. Back then, the Internet was small and only about three or four of us were doing sound drivers for UNIX.
David: Who currently does what at 4Front?
Hannu: By definition, my responsibility is design and programming while Dev does support, marketing and also maintenance of our web site. However, these days Dev does almost as much programming as I do.
Dev: I also run the copier and take out the trash! ;-) In all seriousness, my main functions are mainly to run the day-to-day business operations of 4Front. I make customer calls and visit various companies that we partner with. I always defer to Hannu's technical expertise whenever I'm bug hunting.
David: How many sound systems are supported, i.e., sound cards, on-board and external?
Hannu: Actually, we implement support for sound chipsets rather than sound cards. The same chips are usually used by many sound card vendors, especially in the Far East. I haven't the faintest idea how many different sound cards we support.
Our configuration program currently knows 250 different “sound card” names. I think about 150 of them are unique in one way or another and have required at least minor modifications to OSS. The remaining 100 names in the list are some kind of alias names for some chipsets. We had to add them because so many customers keep asking why this or that sound card is not in our supported card list.
We support or are currently working on about 40 to 50 “major” sound card architectures or chipsets.
Dev: A better picture is to multiply the number of sound chips by the number of UNIX versions by the features for each sound device (audio, MIDI, mixing, synth, etc.) to get the size and complexity of OSS!
David: How do you decide to support a card or system?
Hannu: Mainly, decisions are based on customer feedback, but sometimes just because some cards look particularly interesting in some way. It's actually easy to figure out which chipsets need to be supported by looking at how many potential customers are asking if they are supported.
At this time, our focus is on the popular PCI-based chipsets made by big vendors such as Creative, ESS, Aureal and Yamaha.
Dev: As far as operating systems are concerned, system vendors are coming to us and requesting OSS, since they've seen it in action on Linux. Additionally, with the booming number of applications with OSS, we're finding many UNIX and real-time vendors are taking notice of the fact and are approaching us. A recent example is HP (Hewlett-Packard). We approached HP a while back about porting OSS to HP-UX and only now have we entered into a development agreement because of the attention Linux has been receiving.
David: What sort of work goes into creating, testing and eventually marketing a sound driver?
Hannu: The first thing is to get the programming specifications for the sound card or chipset. This usually takes a very long time, since hardware manufacturers simply don't have suitable documentation available immediately.
The programming can start after getting the specs. The tough part is getting the first sound from the device. With complex 3D PCI audio accelerators, this takes months, since the complexity of these chips is at least in the i286 class. Usually everything has to be done in complete darkness, since there is no way to see what the chip is doing internally. After the first sound, everything is much easier since we can at least hear what the chip is doing.
After the card seems to work, we test the driver for about a month in two or three different machines. After that time, it's released as a beta version so that everyone willing to try it can do so. Finally, the beta status is removed after several months, if no significant problems have been reported.
Actually implementing low-level drivers for different sound cards is just one part of the picture. Another big task is trying to figure out why certain applications are constantly causing problems. If something in OSS should be improved, we do it. However, we will not try to fix buggy applications by changing our code.
Another big task is making the installation easier. After all, a large number of our customers are those who don't want to spend their time getting things working. If they don't get sound working quickly, they just leave it alone. So we have to make it possible to download and install OSS in two minutes without reading any manuals. This is actually an endless battle, since Linux and the PC architecture is a rapidly moving target. All Linux distributions are slightly different, as are the different kernel versions. We currently support all 2.0.x and 2.2.x releases.
Finally, users have an infinite number of different CPU, chipset, SMP/UP, sound card and other hardware combinations (I almost forgot to mention overclocking). In addition, many users compile the kernel themselves and install all kinds of UFPs (unidentified flying patches) to their machines. It's a big challenge to identify the problems caused by these differences and find a workaround. We generally release a new OSS revision every two to four weeks (usually after a new kernel version is released) just to address these kinds of issues.
David: Please describe how your relationship with Linux has evolved over the years.
Dev: I have a UNIX background and worked on the IBM RT 4.2 BSD-based kernel, as well as the AIX 3x kernel for IBM (in a joint project with USC). One of my first drivers was the console driver for the IBM Megapel 5081 graphics card, and following that was the first color X Window System X11R1 server for the card.
I began to run Linux for the first time in 1994 when 1.2.13 came out (until then, I had a monstrous AIX/RS6000 530 at my desk). From my point of view, Linux has the best device driver programming environment, and it's developer-friendly compared to other UNIX environments. Of course, supporting customers on Linux is much more difficult than on RISC-based UNIX systems, due to the PC architecture's ISA bus.
Hannu: I have a minicomputer background. I started programming with an HP3000 Series III at Lappeenranta University of Technology (http://www.lut.fi/) in 1981. For this reason, I never liked DOS or anything else that ran on a PC. I had my first contact with UNIX (HP-UX) in December 1984, and it was the only OS I was interested in. So it was natural that I bought Minix in May/June 1991 soon after my first 386/25 PC. I installed the i386 extensions and GCC and had just finished porting a myriad of applications to it when I made my first contact with Linux. I was one of the lucky guys who saw the historic message posted to comp.os.minix by Linus (August 25, 1991).
At that time, I was already disappointed with Minix and I had started to plan my own OS called SKUNKX (for Smells liKe UNiX) but had not actually started writing it. My immediate first reaction about that no-name UNIX clone was slightly negative, because it was a competing project. I forgot the whole thing (both Linus and my project) for some time until I saw some information about the release of the first Linux version. I decided to skip the first ones, mainly because my machine had nonstandard disks (SCSI) not supported by Linux. After the first AHA1542 driver, it took a few months before I figured out how to get the card to work with Linux, which used a different IRQ than was available in my system. I don't remember what the solution was, but eventually I got Linux installed in summer 1992. After that, I formatted my disk for Linux and have used it as my main operating system ever since. It was amazing how reliably it worked even in those days.
As I mentioned earlier, I soon started working on the Sound Blaster driver in my spare time. After the first release, it quickly got the attention of a few users who made suggestions and sent some fixes. Together with Craig Metz, we expanded the Sound Blaster driver to support the Pro Audio Spectrum PAS16. A few months later, I started adding support for the Gravis Ultrasound and received significant help from Greg Lee. Within a year, support for some other cards was added and finally the driver was included in the kernel.
In addition to developing OSS, I also use Linux for almost everything I do with computers, mainly all kinds of programming, e-mail, news, Net surfing, web server, Samba and reading documentation with Acrobat. All these features have worked very well since I started using Linux, or actually after I upgraded my machine to run X. Now, after getting StarOffice, there really aren't many reasons to use any other OS. I'm sure this will get even better in the near future.
As Dev said, Linux is a very good (if not the best) environment for device driver development work. Hardware interfacing is very easy, since Linux doesn't try to hide the iron behind a stack of abstraction layers. Also, Linux doesn't try to enforce any particular programming model, so you can do what you want in the way you deem most suitable.
David: How does 4Front regard the evolution of Linux itself?
Dev: As a commercial company, we would love to see Linux go to the desktop because that's where sound support makes a great deal of sense compared to the server arena that Linux has now begun to dominate.
Make no mistake—commercial applications will continue, and a lot of bright minds are tied up writing “non-open-source” applications. We expect the Open Source movement maturing and becoming all-inclusive of proprietary and GPL applications. We also expect to see a number of companies to use our hybrid open-source/proprietary model. Many companies will release part of their application under open source and still sell a proprietary version that has additional functionality, yet maintains API compatibility with the free version.
This allows for clean healthy competition between the open-source and proprietary development teams. We are in some ways competing with the OSS/Free kernel drivers that are now maintained by really talented folk like Alan Cox. Some cards are supported only in OSS/Free, such as support for the Apple PowerMac audio and the Sun SPARC SS20 audio.
Hannu: I think our first and biggest mistake with OSS was the stupid idea that we could control all sound driver development for Linux. Actually, it's best for all (even for us) that independent groups continue developing the freeware drivers. This gives us some peace to concentrate on the features and sound cards most important to our current and future customers. Of course, this means there will be competing drivers for many sound cards, but I actually see this competition as a challenge rather than a problem.
The fact that we are making commercial, binary-only software doesn't mean we are against open-source ideology. We are here only because Linux and the original “VoxWare” sound driver was Open Source. Our original idea was to maintain one common source base for both OSS and OSS/Free. In this way, it would have been possible to easily incorporate most additions made to OSS to OSS/Free. This model was brain-dead, because it made it very difficult to adopt contributions to OSS/Free. The current model for how OSS/Free is maintained is much better. The internal architecture of OSS/Free is now significantly different than OSS, so our code is not very useful for the OSS/Free team. However, I'm sure we can find a way to make contributions to OSS/Free in the future.
Dev: You will see our concept used by many open-source developers—Sendmail, Ghostscript and others are examples of how developers have come up with a “proprietary/open-source” model to generate revenue. It takes complete commitment from the authors, and this means giving up day jobs and concentrating on the software. We have received kudos from many customers about OSS and this is what keeps us going.
4Front has been profitable, and we are not funded by venture capital or by sound-card or OS vendors. We may be in a position to hire some people next year if the pace of Linux's growth continues—it's all about being able to grow from a garage shop into a professional company by doing what you do best.
David: What can Linux users expect from future releases of 4Front drivers?
4Front: We are currently working on support for all those popular PCI sound cards. Support for some high-end audio cards should be released during the second half of this year. Features of the base OSS will remain almost unchanged this year, but we are implementing some features which will make OSS useful in simulators (3D sound effects) and radio (on-air) systems. Next year, the focus will most likely be on adding new features to the API, at least on the MIDI programming side, like support for DLS samples in the SoftOSS virtual synth and support for MIDI patchbays.
Of course, we will continue our work in making OSS even easier to install and use than it is today.
We're also looking at more OS support. For example, we'll be working on BeOS support later this year. We may look into Mac OSX when it comes out later this year, as it's rumored to have a UNIX-like core.
David: Is there anything you would like to add beyond these questions?
4Front: We would like to thank all the developers who have been writing audio applications for Linux. OSS couldn't have done it without your support. We hope your foundation work will bring more talented people from other operating systems into the Linux and OSS platform.
David: Please tell LJ readers something about what you guys do outside of your involvement with the company.
Hannu: My family takes up most of my time outside work. My hobbies are reading, listening to music, movies, bicycling, swimming, cooking and digital photography. I collect all kinds of electronic gadgets. I'm also trying to get some experience in the electronic engineering side, but don't seem to have enough time.
Dev: My hobbies include playing volleyball on the beach all year (one of the luxuries of living in Los Angeles). I also like skiing and golf (I'm a horrible hack at that!). I used to build electronic gadgets as a kid. I'm currently engaged to a wonderful woman and will be getting married in September.
4Front Technologies4035 Lafayette Place, Unit FCulver City, CA 90232Phone: 310-202-8530Fax: 310-202-0496Email: email@example.comURL: http://www.opensound.com/
David Phillips (firstname.lastname@example.org) is a composer/performer living in Ohio. Recent computer-music activities include an ambient composition for the artist Phil Sugden, lecturing on computer-music programming languages at Bowling Green State University, and maintaining the “official” version of Csound for Linux. Dave also enjoys reading Latin poetry, practicing t'ai-chi-ch'uan, and any time spent with his lovely partner Ivy Maria.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Interview with Patrick Volkerding
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide