After a while I have started to think about creating OSS v5.0. For the time being the audio market for Linux is dominated by ALSA. However there is still strong demand for OSS. So it might make sense to proceed with OSS.

What I have been thinking about is pushing OSS back to the Linux kernel. However there are few things that need to be done before this could be possible:

• Better integration with the Linux kernel. Currently OSS doesn’t follow the design practices used by the rest of the Linux kernel.
• Power management. For the time being power management is missing from OSS.
• The audio core framework requires some rewriting. The current core is 10 years old and the recent additions like vmix don’t fit properly in it.
• Some key drivers such as USB audio, HDaudio and SB X-Fi require rewriting.

In addition the following enhancements or features have been suggested:

• MIDI support. For the time being MIDI support is under construction. I have started to suspect that there is still too much “reinventing wheel” problems in the current approach. The best approach might actually be doing all timing in user space. This needs more discussion.

Getting all this done requires some funding. However this is really peanuts. All that is required is salary of a SR software developer for 2 to 3 years. In addition some kind of HW level debugging environment is required. This means roughly an invenstment of 100k to 200k euros.

The exact business model is to be defined. Funding can come from a single source. Alternatively we can create an OSS consortium with annual membership fees which was our original plan when we open sourced OSS.

I have decided to write all new blog entries as pages instead of posts. So you will find the most up to date information under the pages section in the right side bar. The earlier posts (below) are more or less outdated.

Sun has published more details about Boomer that is their implementation of OSS4. Boomer is a hybrid based on Sun’s older SADA (/dev/audio) code and selected parts of OSS4. It probides full SADA support in addition to the OSS4 API (OSS4 itself has more or less limited SADA support). In addition Boomer supports many Solaris specific features such as fault management (FMA) that are not supported by OSS (yet).

Boomer is based on Sun’s existing low level drivers. Also large parts of the framework comes from Sun. This is OK. However there is some risk that Boomer behaves in slightly different way than OSS. My understanding is that applications written for OSS4 should work under Boomer out of box. However I suspect that applications written for Boomer may not work with our OSS4 implementation in all cases.

There are few main differences that may cause problems:

1. Boomer doesn’t implement SNDCTL_DSP_SETFRAGMENT and application selectable fragment/buffer size that is preferred way for controlling latencies in OSS4. This should not be a problem in most cases since Boomer uses reasonably short fragment size. However there are special applications that would require very short fragments to work.
2. Boomer makes the /dev/mixer API available to “ordinary” applications. OSS4 in turn bans use of the MIXER API from “ordinary” applications that use /dev/dsp too.
3. The Boomer mixer API spec also tells that applications can use predefined control names (such as Mic, Line or whatever) for predefined purposes. OSS4 doesn’t have any predefined names and applications should handle the mixer API fully transparently. In OSS4 mixer control names are only meaningful to the user. The application should just show all the controls to the user and let him/her decide what they mean.
4. Boomer has “flat” mixer interface. All mixer controls are in the same level. OSS4 in turn has hierarchical mixer structure where controls are organized as a tree.
5. There may be places where Boomer differs from OSS unintentionally. Boomer has been tested with “legacy” OSS applications that have been written to be bug compatible with OSS/Free and ALSA’s OSS emulation. Unfortunately most of these applications use extremely complicated and brain dead non-blocking/timing strategies that make them very unreliable. OTOH Boomer should also have been tested with OSS4 applications such as osstest and ossplay/record so the situation should be under control.
6. Boomer doesn’t implement many of the optional ioctl calls of OSS. This should not be a problem because they are listed as optional in the OSS4 API spec.

After all I don’t expect any major compatibility problems between OSS4 and Boomer. The audio API’s are supposed to be identical. The mixer API (ioctl calls) itself are identical too. However the way how Boomer implements the actual mixer behind the API is different. Possible compatibility problems can be avoided very easily. Applications just should continue to avoid using the mixer API even Boomer’s documentation says they can use it.

This blog gets about 2000 spam comments each month. I found it impossible to screen all of them to approve few real comments. In particular this seems to take more and more time since recent spam messages look like real messages instead of just collections of hyperlinks to porn sites.

So I removed all 3700+ comments waiting for moderation. I will probably not be able to screen the comments any better in the future. My intention is not to censor your comments. I just have better ways to spend my spare time than by reading all kind of junk sent by bots.

To get your comments approved you should include something that gets my attention in less than a second. Something that shows that the comment has been written by some human being who knows what he/she is talking about. Comments that have no interesting keywords in them are likely to be ignored. Also comments that have hypertext links will probably get deleted unless there is something else that raises my attention. You need to say something that shows that you are talking about the subject of this blog, it’s scope or it’s competitors.

Note that I’m talking about “ordinary” users who don’t know how to compile, install and hack software packages downloaded from the net. Power users have the required skills to do whatever they want. However how many typical computer users have ever heard aboutany computer programming languages? Typical end users can only use the services that are already available in their computer. In the best case they can install some precompiled applications if the installation procedure is easy enough.

In the Linux bazaar you can visit any of the shops and pick the Linux distribution provided by that vendor. However this is the last moment you can make any choises. After you have installed the Linux distribution you have got your freedom is gone.
If all the devices in your system are not supported by the distribution then you will be more or less out of luck. If the Linux version doesn’t support your chipset, network adapter, IDE/SATA chip and other critical hardware components they you will be out of luck. There is no way to get the Linux distribution you have selected to work in your system. You cannot install any additional drivers from the driver CD that comes with the system because there are no Linux drivers. You can only hope that some other Linux distribution supports your hardware or that the support will be included in the next update.

Even if you manage to get Linux installed you will be limited to the applications supported by it. You cannot install any 3rd party applications because you would have to compile them yourself which is beyond your skills. If you go and buy the very latest scanner (or whatever) device then it will not work before your Linux vendor releases a kernel update that supports it. You can possibly download the source code for your hardware from it’s manufacturer’s web page but will you be able to compile it? It depends on your skills and also on the freshness of the driver code (Linux kernel may have been changed between the driver and the kernel version you have). In any case you will have to install the driver development environment and tools for your distro (which may mean 100’s of megabytes of disk space.

How does this work in Windows?

When you install Windows you have an opportunity to install vendor provided drivers. You can install the drivers from the install CD that comes with your motherboard. You can also do the same with the install CD’s of your network and SCSI cards. Then you proceed to install Windows itself and the result will be a fully functional system.

Can you do this with Linux? 

The answer is no. When you install Linux (any distribution) you are not given any chance to install 3rd party drivers when you install Linux or even after that. You can install 3rd party drivers to Linux if you are a real hacker with years of Linux kernel experience. However for any “ordinary” Linux users this option is out of reach.

Is the bazaar really a bazaar?

After you have installed a Linux distribution (if you have managed to do so) you will become dependent of the support provided by the vendor of the distribution. You can install important updates released by the vendor or to upgrade to the later versions of the distribution. However if the vendor doesn’t see it necessary to support hardware or software you would need then you will be out of luck.

Experienced Linux hackers can always download whatever software they need and try to compile it themselves. However often they will end in never ending battle with differences between various kernel and library versions. The device driver interface of Linux seems to change between versions. This means that 3rd party drivers may require modifications before they compile, install and work with different kernel version. Even user land applications often depend on newer/older versions of various libraries than the ones provided by the distribution. You will have to download and recompile different versions of different libraries and to recompile them. Sooner or later you will be in a situation where some other applications stop to work because of wrong libraries. So to stay on solid ground you have to stick with whatever software/versions your Linux distribution vendor sees necessary to support.

Do you think this is the Bazaar? Are you sure you have not visited a Mosque instead of a Bazaar?

Advocates of “free software” often talk about “free beer” and “freedom of speech”. Have you ever heard anybody talking about “freedom of choice”. In the current situation there is very limited freedom of choice in Linux. You can (if you can) do this and that with Linux and the software installed under it. However this appears to be very difficult when compared to so callec “closed” operating systems like Windows or MacOS.

What suxx?

Once upon a time Linux had a relatively good device driver module interface (that was in the 1.2.x days). A driver compiled for some kernel version worked perfectly OK with several kernel versions after that. However things changed after Linux 2.0.0. It become more and more difficult to ship just one binary driver for all 2.0.x kernels. It appeared to be necessary to provide a wrapper module that was compiled for each kernel version. Each distribution introduced slightly incompatible kernels and soon the only way was to compile the wrapper in the customer system. That time it was easy because the driver development environment was installed by default by every distribution. Today even this is practically impossible because the kernel headers and the required tools (gcc, binutils, make, etc) are not installed in most systems.

Earlier our mistake was having OSS as a closed source product. Now we have open sourced OSS but nothing has improved. We still cannot provide precompiled OSS binaries that the customer could install out of box. The customer will have to install the kernel development environment (which consumes gigabytes of disk space) before he/she can install OSS. This requires significant amount of knowledge that most ordinary users don’t have. So only more or less experienced hackers will be able to install OSS.

Sooner or later OSS4 will become part of most Linux distributions. This will solve the problem. However this will take years. Even after that ordinary users will not be able to download the latest version of OSS from our site and install it out of box.

Is this the Bazaar or the Mosque? You decide…

The Dream World (TM)

Today you cannot take the very latest motherboard, network adapter, sound card or whatever and just install Linux to your system. The chances that you will be able to do this are minimal. In the best case you may be able to install some of the Linux distributions by using the noapic and noacpi options. However you will probably have to try several different Linux distributions just to find out that none of them work yet.

In (my) dream world you could take any Linux distribution and boot from it’s install CD/DVD. It will then ask you to insert the install CD’s that came with your motherboard and the add-on devices. After installing the vendor drivers the Linux installer continues. Few moments later you will have a Linux system that supports all the hardware you have got.

However this is not reality at this moment. None of the Linux distributions let you to install any 3rd party drivers. In fact developing 3rd party drivers that work in this way is completely impossible. There is no concept of precompiled binary drivers in Linux. Everything that is not included in the distribution itself would have to be recompiled on-site which requires gigabytes of disk space that is not available during the installation.

The problem is that Linux lacks a sane device driver (binary) interface like DDI in Solaris. It is totally impossible to distribute any precompiled kernel code (drivers) because Linux drivers depend on the deepest details of the given kernel image. I have proposed this kind of interface several times on the linux-kernel mailing list over past 12 years. However these guys don’t seem to like the idea. The current vendor-centric business model of Linux is not compatible with this idea. The current model is perfect for the current Linux players because they can make money by doing paid support for the customers who like to use new hardware. However for 3rd party players like 4Front Technologies this is an unbearable situation. Also the customers will suffer because their Linux vendor has pure monopoly to give any support to them.

At the same time users of OSS are struggling with problems related with their (hdaudio) laptops. Fixing them will require hours or days of work for each system. In addition to do the work I would need to buy each laptop and pay it from my own pocket. Why should I do that when nobody is paying anything for OSS. Users of OSS seem to be just wanting free support from me without paying anything for that.

Recently I bought a decent iMac system because I decided to move from Windows to Mac (I’m a amateur photographer and use Photosshop a lot). I can use this machine to fix some OSS problems related with Mac machines but this is justified because I have other use for the machine. In addition I would like to use OSS under Solaris in this system myself.

However there are many OSS users with many different kind of laptops (Lenovo, Sony, Toshiba, etc). What should I do with them? Do I just go and buy all the laptops from my own pocket? No. I don’t need any more laptops for myself and in addition my salary is will not be enough to buy any more of them.

So what to do with users of such laptops. I don’t care. I don’t have any use for such laptops. Developing hacks for more hdaudio systems is even not fun (it’s lamest of all lame jobs). Should I just say fuck off to all these users? After all being nice to them will not improve my life in any way. I just have to waste my spare time in doing something I don’t want to do. By not doing that the competiveness of OSS will degrade. However does it really matter because I will have to find some other job anyway? Is this the only choice? I hope not.

What I have been thinking about is a new business model for OSS. If 100+ owners of some laptop (say Thinkpad T61) would like to donate something like $10 for the project then I can pay a T61 laptop and cover the required work by that money. In this way it will be profitable and I don’t need to cover the work from my just-for-fun time budget (which will never ever cover the price of a T61 laptop I don’t need). I just need to spend some additional time in developing an auction web site for this purpose (which is actually fun).

What do you think guys/galls? Comments are welcome.

1. Third party driver developers can contribute their changes to the common OSS source tree.
2. We wanted to give our customers a guarantee that they can keep using OSS even 4Front Technologies goes out of business.
3. By having the source code our customers can customize the code for their purposes.
4. When large number of developers can see the source code they may find bugs that might otherwise stay undetected for years.
5. We wanted to make OSS as an acceptable sound subsystem solution for all Unix/Linux/POSIX/whatever compatible operating systems.
6. We wanted to promote an open source software concept where everybody who uses open source software from other companies/developers also contribute their own development to the community.
7. We wanted to do all the above in a way that makes it possible to us to continue our work as professional software developers.
8. We wanted to continue to sell OSS as a commercial product to the customers who want to use OSS from their proprietary/inhouse software.

We decided to release the source code of OSS under two commonly used open source licenses that were GPLv2 and CDDL. We would have preferred just one license scheme but out of all ones these two provided widest coverage of the open source software market. These two licenses are compatible with all the different “open source” licenses so far. We didn’t release OSS under licenses like BSD because we feel they are “half closed source” licenses.

Did this licensing model work? The answer is yes and no. The success story is that we have already got several talented developers to contribute their work back to OSS. What was disappointing is that open sourcing actually decreased our sales significantly. We are in unfortunate position of providing only device drivers that are supposed to be free.

So for us open sourcing means kissing goodbye to any hope of revenue. The customers who previously bought OSS licenses don’t do it any more. They think that having the source code means that they have at least equal rights than we had.

So what can we do? Developing OSS is no longer profitable which means we should find some other way to feed our families. Who will then continue developing OSS for you?

You may thing we could start selling OSS T-shirts to fund the development. Do you have ever bought any T-shirts to sponsor some open source project? At least I have never done so.

I tried to add some Google ads to our open source WEB pages and to the OSS Programmer’s Guide (which have about 2000 hits/day). In two weeks I have got exactly $00.00 in that way.

So does anybody have better ideas?

The original idea was to release OSS under CDDL for Solaris/OpenSolaris and GPLv2 for the others. However as we expected the BSD communities didn’t like this so they will get OSS under CDDL too (how much I hate these silly open source license wars).

In addition we will announce our intention to move further development of Open Sound System to a community.

The license is really GPLv2 instead of LGPL or the Linux kernel license. This may look stupid but actually it’s not. The beauty of GPLv2 is that the license permits use of OSS only with operating systems and applications that are also released under GPL.
In this way the source code is available under GPL for everybody. Organizations and users using GPLed applications under GPLed operating systems (kernels) can use GPLed OSS for free. Just the companies and organizations using OSS in non-GPL compatible environments are required to buy the commercial license.

Some open source operating systems like OpenSolaris and the BSD variants are not compatible with GPL. We will make OSS available also under the CDDL license for these operating systems. CDDL makes things more complicated than with GPLv2 alone. However I think the benefits will be greater than the possible problems.

I think this licensing policy is good for everybody. The open source community will now have access to the source code after 10 years of closed source period. Users of closed source applications and operating systems can still use OSS and it’s source code if they purchase the commercial license. We as the initial developer of the software will still have some chances to continue development of OSS as professional developers. More details about the licensing will be published after the official announcement.

Why do we do this?

First of all we have recognized the benefits of open sourcing to the user and software developer communities. We also believe that with the help of the developer community we can make OSS better than it’s now.

Another reason is that our potential customers currently expect to have access to the source code.

But what do “open” and “closed” mean after all?

During the early years of computing all software was written in assembly. There was no concept of operating system. Instead all applications (such as accounting software) accessed the hardware directly. The hardware had to be fully documented since otherwise nobody would not have been able to use it. In fact most (if not all) computer manufacturers shipped some software (in assembly language) with their hardware. So the situation was “all open” and also “all open source”.

Soon after that some new computer manufacturers entered the market. Since existing customers had already invested truckloads of money to their assembly software the new competitors had no other choice but to clone the original instruction set and hardware interface. The concept of “IBM compatibility” was born. Without compatibility it would have been too expensive for the old big customers to change their hardware vendor.

Few decades later the situation was different. Proper operating systems and programming languages had been invented. So 100% hardware compatibility was no longer necessary. It was possible to recompile the applications in some new system and get it running with reasonable cost. So being “open” was not the only choice.

Some systems even hidden all the hardware (even CPU instruction set) from the user and the software was implemented on top of some interpreted language (much like Java works today). The HP250 computer by Hewlett-Packard (see http://www.decodesystems.com/hp250.html) comes to my mind. It’s probably not the only or even the first system of this kind (I just have seen it). However all applications written for it were written on HP BusinessBasic. Nobody knew what kind of hardware architecture it had. A friend of mine managed to break behind the Basic interpreter and got a feeling that it was actually a 32 bit system (HP’s “bigger” HP3000 machines were still 16 bit systems during that time). However this was an example of “closed”.

In 80’s many (if not most) computers were “proprietary” and “closed”. They were running some operating system or BIOS that was not available for any other hardware. This was true with the first IBM PC too. IBM PC was MS-DOS based and Microsoft licenced DOS to some other computer manufacturers such as HP. However IBM’s BIOS was “proprietary”. During mid 80’s I used HP150 microcomputer that was also MS-DOS based. However it had it’s own (again “proprietary”) firmware that was called AGIOS (or something like that). Both HP150 and IBM PC were running the same MS-DOS which was character oriented. For this reason all applications had to use some firmware functionality to be able to do anything usefull such as graphics. So “IBM compatibility” got a new meaning. IBM compatible applications could be used only in IBM PC because they required services of the “proprietary” BIOS that IBM refused to license to anybody else. Fortunately Phoenix managed to reverse engineer the IBM BIOS and companies like Compaq and HP were able to produce their IBM compatible clones. Since that the PC was “open” again.

Then Windows was invented by Microsoft (btw, Windows 1.0 was originally shipped as a co-product of Microsoft mouse). Also Apple released the original Macintosh. Both products were “closed” again. MacOS was only available for Macintosh computers made by Apple. Windows was only available for MS-DOS. And so on…
Soon after that Unix started to gain more and more attention. It was considered “open” because AT&T licensed it to every computer manufacturer who wanted to license it. However every Unix vendor started to make their own extensions to it and soon the situation was approaching “closed” and “proprietary” again. Each vendor had their own windowing system running on top of X11 so GUI software written for one Unix variant was unusable under the others.

So several Unix manufacturers joined together in Open Software Foundation (OSF) and their developed the Motif GUI toolkit based on HP’s design. They even started to develop a common Unix version called OSF1 but after all only Digital used it in their Aplha machines (now it’s called Tru64Unix). Also Sun left outside OSF because they had developed yet anothe GUI toolkit that was incompatible with Motif (and better IMHO). And the story is getting too boring and I have to stop…

The “open” in Open Sound System comes from the above context. It means that the software is fully documented and any company can license it (or create their own implementation based on the specification). In fact this has happened in Linux and FreeBSD that both have their own implementations of the OSS API. In addition some companies like Sun and SCO have already licensed OSS for their operating systems.

I was very enthusiastic about the Yamaha OPL(2) FM synthesizer chip found on my SB card when I started woring on the Sound Blaster driver for Minix and Linux. I soon realized that it was not possible to maintain precise timing in application level because both Minix and Linux (at that time) had rather bad scheduling latencies. An application that written the FM chip register directly (using some ioctl calls) couldn’t play any MIDI files with acceptable timing precision.

The solution was to move the timing stuff to the kernel space where the (100 Hz) timer interrupts worked much better. So the /dev/sequencer interface was born. In the beginning this interface was only used to drive the FM chip. Then few months ago the Gravis Ultrasound card was released which was even more exciting. I quickly hacked the /dev/sequencer API to support the hardware wave table engine of Ultrasound and added yet another set of ioctl calls for patch management. In addition the API was expanded to support MIDI (serial) interface ports too. Also support for the better OPL3 FM chip (4 operators instead of just two) was added.
From the very beginning the sequencer API had an event queue where the application could write 4 byte event records such as instrument change, note on and note off. The event queue was read by a timer callback that forwarded the events to the actual device and removed them from the queue. Timing was “great” and the result sounded good. I even did a “gmod” program (or whatever it was called) that played module files (.MOD) using Ultrasound’s wave table engine. That was a great improvement because my mighty 386/25 PC was able to play nice music without hiccup while compiling the kernel in another VT. Similar player was soon implemented for MIDI by Greg Lee.
The problem was that now there were 3-4 slightly different variations of the sequencer API (OPL2, OPL3, Gravis and MIDI ports) that all required slightly different handling in the applications. The solution was to create another version of the sequencer API that was called /dev/sequencer2 and later /dev/music). The idea was to expand the event records to 8 bytes which was enough to distribute MIDI messages to several synthesizer devices and MIDI ports at the same time. The MIDI port driver the converted the events back to MIDI while the hardware synth drivers played them directly. I also got added stpport for the Music Quest MQX-32M MIDI adapter that supported “MPU-401 intelligent mode” with features such as SMPTE timing.
The result looked and sounded great and I was very proud about it. Applications still had to support two different “patch loading” methods for different cards but that was solved by adding an interface for external patch management daemons. Finally it was possible that one program can play MIDI files to any device(s) without any device dependent code.

The real problems started few months after that when I tried to document the sequencer/music interface. The concept itself was easy to document. However there were tens of different event types. Each MIDI message (note on, note off, MTC/SMTPE, etc) had one of them. The MIDI message system itself was documented in the official MIDI 1.0 specification published by MMA. However I should have to duplicate all that to explain how to translate MIDI messages to the sequencer events and vice versa. Due to lack of time I gave up but promised to write the documentation later.

Then few years later I was writing another version of the OSS API documentation for OSS 3.8 and again the job stalled at the same point. I got something written down but then I had to give up. Once again I just promised to complete the documentation later. Unfortunately developers coudn’t do anything usefull with the interface without documentation so it didn’t get widely supported.
Finally couple of years ago I was working on the OSS 4.0 version and noticed that no applications were actually using the sequencer API any more. All Linux MIDI applications were already using ALSA so the OSS sequencer API was no longer active. There was no point in keeping the current sequencer stuff in OSS and we decided remove it and rewrite it from scratch. At the same time we could fix the known problems in it.

But what should be actually be done with that stuff? The main problem was apparently the documentation and we were thinking about hiring a technical writer to do that part. But there was something else that should have been redesigned before that. But what should be changed and how?

There were some major problems that were pointed to us by some MIDI developers before they jumped to the ALSA boat:

• Only one application was able to use the sequencer at the same time. That made it impossible to implement applications like software synthesizers.
• The API was said to be “playback only”. It was not suitable for interactive performances because echoing live keyboard events to the output devices caused hanging notes. Btw, the reason for this was actually not the API design but a bug in the parser that translates incoming MIDI messages to OSS sequencer events. It didn’t handle running status correctly. We noticed this problem later when the same code was used somewhere else in OSS.
• Because there is only one timing queue it’s possible that flood of events going to one device may delay events sent to the other (non-flooded) ones.
• Some software based synthesizer engines (such as the SoftOSS virtual wave table engine of OSS) have greater latencies than many hardware based implementations (such as FM and wave table chips). It is necessary to compensate this by sending events to such devices few microseconds before the scheduled time. In this way the notes will play simultaneously on all devices.

These problems should have been easy to fix while rewriting the code. In addition all the supported synthesizer chips were out of production (they were ISA based) so the amount of code to rewrite was not that big. However something looked to be seriously wrong and I couldn’t realize what it was.

Finally on one stormy night I realized it: The problem was not just the documentation. The whole /dev/sequencer concept was seriously bogus. It looked good some ten years earlier when it was designed. However the problems the previous scheme tried to solve were all gone with the old ISA cards. Fist of all the MIDI streams were first converted to the sequecer events which were then converted back to MIDI before sending them to the output device. And there was even a bigger issue.
When somebody is writing a new MIDI application he/she is (at least supposed to be) familiar with the MIDI 1.0 specification. In addition to the official spec MIDI is also documented in many books and on many internet sites. The sequencer concept requires that the developer knows how to map the MIDI messages to the sequencer events and vice versa. This makes the development process rather difficult if the application should support some advanced MIDI concepts such as MMC. In particular the sequencer scheme makes it difficult to port MIDI applications from the other environments that use APIs derived from the plain MIDI. So it didn’t make any sense to rewrite the sequencer API hoping that somebody will manage to document it in the future.

Instead what we are working on now is a different MIDI subsystem based on plain MIDI message streams with some timing headers. The application simply packs all MIDI messages to be sent at given timing tick to a packet. The packet has a header record that contains the transmission time and some other control information. The MIDI core then appends the records to the output queue of the target device and finally sends them to the device at the right moment. Input is handled in the same way.

There is no central /dev/sequencer device file that would be common to all MIDI/synth devices. Instead each target/source devices have their own /dev/midi# device. An application can open as many MIDI device files as it wants and to slave them to the same timer device (it’s also possible that each MIDI devices use different timers with independent tempo/etc settings if that makes any sense).

It is possible to handle playback of live keyboard input by inserting received MIDI bytes to the head of the queues of the output devices. Such live packets will be played as soon as the target device has played all the MIDI bytes from the currently active (incompletely played) packet. In most situations there are no packets currently playing (the device is waiting for it’s scheduled time) so the delays will be minimal. In the future it’s also possible to implement automatic kernel level echo and rerouting capability on top of this simple API.

Running status is handled so that the application “loses” or flushes the status at packet boundaries. Each packet will be started with full status byte even if the previous message had the same status byte. This doesn’t cause any performance problems. Running status is only needed when large number of MIDI events (say pitch bend changes) need to be sent rapidly to the device. A packet boundary normally means that there is a pause in the output until next bytes need to be sent so retiring the running status doesn’t cause any timing problems. Handling running status in this way makes it possible to insert live packets to the head of the queue. The application just needs to make sure that the MIDI channel used for echo messages is not used by the sequence that is currently playing.

Support for software based synthesizers (wave table, modelling, etc) is handled by a special MIDI loopback driver. Each loopback device pair has two ends. The “server” device is used by the synthesizer application. It can change the device name seen by the “client” side to something descriptive such as “ACME super hyper modelling synth”. The user of the client application (say a MIDI player/sequencer) can pick the modelling synth from the device list and then start playing the MIDI sequence using it (input is also possible if that makes any sense). The server side can report it’s delay level (in microsecods) to the MIDI core so that timed events can be sent to it slightly ahead of time. In this way any latencies caused by the audio side can be compensated.

This is the good news. The bad news is that there is no MIDI support in OSS 4.0. There are few bugs in the MIDI code and we decided to ship OSS 4.0 without it (instead of delaying release of the other parts that were ready). MIDI support will be included in OSS 4.1 (hopefully within this year).

What about ALSA which has superior MIDI/sequencer API?

ALSA’s sequencer API is a ‘clone’ of the OSS’ one with steroids. While they have fixed the rest of the flaws of OSS the design is fundamentally the same. Even with the fundamental problem I mentioned above. It will be interesting to see if they ever manage to get it fully documented (or if anybody will ever care to document anything of it).

In addition ALSA has some “advanced” bells and whistles that make me suspicious. However this is just my understanding and I cannot check the details because there is no documentation available.

• Their timing model is rather odd. I have to confess but I have not managed to understand how it works. However they seem to use something else than the traditional tempo/timebase style MIDI timing.
• ALSA has sophisticated MIDI rerouting (alsaconnect) capability that is supposed to be able to route MIDI input from any device/application to the input of any MIDI output device or application. However the practice seems to be that applications bind themselves to some hardcoded devices that prevents this scheme from working.