A white paper by Ots Labs founder and OtsAV creator Adam Ots
It's probably not overstating things too much to suggest that a playout system or DJ software application is nothing if not stable and reliable!
Unfortunately the Windows operating system is not known as being friendly to applications in this regard. As a general purpose operating system—as opposed to a realtime operating system—it was never designed with hard realtime limits as part of its architecture, yet this is the very thing a realtime media (particularly audio) application needs in order to guarantee absolute stability.
First, we should clarify what we mean by realtime audio application. This is a much more specific type of audio application—one where output delays and generous buffering are not acceptable. In the typical case this is because user interface controls need to be able to be operated with their effect or influence on the audio heard immediately—not in ten seconds, two seconds, or even half-a-second. A basic media player, waveform editor, web-based audio, or any number of other general purpose audio apps can tolerate substantial output buffering and hence do not face this dilemma—ie. they can be made to be very stable without any extra work or clever engineering.
A realtime audio application like a fully-functional DJ software suite, or any playout system that provides instantaneous and comprehensive media control and manipulation is not in the same class and must operate with minimal output buffering. If it doesn't, then it's shortchanging the user experience in some other way, such as not providing near-zero levels of latency, or not allowing the full manipulation of media items (eg. time-scaling and other transforms or effects). Quite simply, you can't have both!
The problem for the software architect is that—on Windows at least—as soon as you operate with minimal buffering throughout, your application becomes susceptible to delays and interruptions that are a normal part of life on a non-realtime and preemptive multitasking operating system such as Windows. Whenever such an interruption occurs, there's always a chance—and sometimes a certainty—that a buffer deadline will be missed which will result in an audible glitch, crackle, pop, skip or repeated section of audio. It won't happen all the time (which is how the majority of other DJ software applications kind of get away with it), but throw in some extra system activity such as the user minimizing or maximizing other windows on the desktop, loading/starting other applications, simultaneously using resource intensive applications, operating hardware that has "unfriendly" drivers, or a whole host of other things that normally won't cause a problem to non-realtime audio apps, and presto!—most DJ software applications will fail at least some of the time in the sense that they will no longer deliver glitch-free audio as any professional audio application obviously should (it may just be for a split second each time or if you're lucky even an almost-imperceptible crack or pop, but is that really acceptable at the wedding you are hosting, or the radio station you are programming, etc?)
The situation was particularly bad in the pre-Windows 2000/XP days (ie. the era of Windows 95/98), but it is still very much an issue today. Versions of Windows based on the NT kernel (like XP and all newer Microsoft desktop operating systems) do not exhibit some of the interruptions during certain user activities that were characteristic of the older versions, but they are still far from immune and still do not provide any kind of hard realtime guarantees. Therefore the problem remains, and most modern audio apps (even some non-realtime ones) are quite easy to "break". Even a jump or skip once per hour, or "only when you do that thing with the computer" is still too often and far from acceptable for any kind of professional use. If you turned on the radio to your local commercial music station and heard the song glitch, you wouldn't be impressed would you? Neither would be the guests at the 30th party they are attending, or the business people at that big corporate event at the conference center in town.
In short, media applications designed for professional use should be able to output media without stuff-ups—any stuff-ups. Accepting anything less than this—or even worse, rationalising it as not a big deal—is akin to accepting a paint dent or some rust on an external panel of the body of your brand new car just delivered by the dealership! Or, closer to home, of being completely satisfied with that CD you just purchased from the record store that was mastered with an unintentional dropout half-way through "track 2". Sure, you may accept these things in some situations (normally because you have no other choice or need the particular product or service despite it being below par), but you certainly won't—as the consumer—be happy about them. You won't be making glowing endorsements of that particular company, producer, or product. And you can be sure that heads would roll at the auto dealership or the CD audio mastering plant where the mistake was made.
It's really no different with the products and services you provide to your customers. You should be aspiring towards excellence in everything you do and this is one of the most sure ways you can grow and succeed as a business. You'll have happy customers, win a lot of repeat business and enjoy glowing endorsements and positive word-of-mouth.
OtsAV can help you in your overall business strategy by providing you with a reliable technology platform partner that you can bank on to always perform as it should, professionally, and without the stuff-ups that some others tolerate to their detriment.
OtsAV was designed from its very inception with both low-latency throughput and comprehensive transport control and manipulation of media as non-negotiable design goals. It was also a given that the application would have to operate stably at all times. There was no room for compromise on any of these fronts. This absolutely necessitated that our engineers find a solution to the system interruptions inherent within the Windows environment discussed above. Necessity is the mother of invention and Ots Labs invented StablePipe™ technology.
Without giving anything of significance away, in part, StablePipe™ involved a completely different technique of interfacing with the underlying system audio drivers, one which required a great deal of effort and some trickery in those Windows 95 days. However, just interfacing with audio drivers in a "special" way does not alone solve the issue. It was necessary to architect the whole application in a very deliberate manner in order to provide the entire environment necessary within which StablePipe™ may successfully operate. Further details will not be furnished here.
The result was that the very first version of OtsAV (known originally as OtsJuke DJ) contained Ots Labs StablePipe™ technology and—despite running on Windows 95—was able to deliver a performance combination (low latency and realtime control) that quite simply was not seen or heard from other audio applications within the same space. That was over ten years ago!
While there are far too many applications in the marketplace now for us to be able to make honest claims of any absolutes, it is still very much our observation even today that applications have shortcomings in this area. The major shift to the NT kernel with Windows 2000 and up did change the game somewhat—our engineers had to re-implement StablePipe™ within a completely different environment—but it did not in any way remove the necessity for it.
If anything, the emergence and almost blanket coverage of the NT kernel probably has caused less research to be performed and emphasis in general on this area from other companies, because these newer operating systems work better on average which has made it easier to completely ignore the issue. However, ignoring it means that an application will never attain truly stable performance across the full range of typical usage scenarios. Therefore Ots Labs' experience in this area is invaluable and remains so no matter the kernel or driver model being employed.
Some may wonder whether this is all a moot point when an alternative driver model, such as ASIO, is used. The answer is a very definite no. A driver model like ASIO allows an application to talk to the installed audio hardware via a low-latency pipeline, however this is a different concept to stability. In essence, ASIO provides what Ots Labs' StablePipe™ alternative audio driver interface provides, particularly the style that was used in the pre-NT kernel days. This is good, but only part of the battle! As discussed above, StablePipe™ also resulted in major application architecture decisions in order for all design goals to be met.
The fact that the ASIO driver model provides applications with a configurable setting for buffer size and the fact that different applications are able to perform successfully with varying minimum buffer sizes demonstrates the importance that application architecture (among other things) plays on this outcome. The demands or goals of some applications are lower than we are talking about with OtsAV and therefore they may be able to perform at low latency levels and maintain stability, however it should not be inferred from this that the stability would remain if they were attempting to do all that OtsAV is doing—the same design goals. Unfortunately this latter point complicates the whole assessment process and may lead some to incorrectly conclude that an alternative application contains the same or similar levels of stability to that provided by StablePipe™ technology.
A related area worthy of further explanation concerns the discussion of application transport control or media manipulation. When we say that the design goals of OtsAV dictate the working combination of the three key areas of a low latency output, a perfectly stable output, and full control and manipulation of the media throughput, some may be confused by the latter point. An explanation of the difference between kernel mode or driver-provided facilities and application-mode stream manipulations is in order. If an application performs a given manipulation, let's say starting or stopping an item, or even altering it's pitch, these kinds of stream manipulations can be performed using facilities provided by various layers, platforms or services within the operating system, eg. DirectSound. As the critical realtime routines of such services run in protected kernel mode (or some equivalently-shielded environment) as part of the core of the operating system, they are generally immune from the issues discussed above.
This is why simple playout systems—those not offering the full functionality of a comprehensive application like OtsAV—may run without the stability issues which are the subject of this paper. However as soon as an application needs to do something—in realtime—which can not be accomplished by simple calls to an operating system layer or some other driver-provided service, then it falls within the category of the class of realtime app discussed in this article. There are many manipulations or effects which fall into this latter category—and of course it also includes all custom things an application may wish to do—an obvious example that comes to mind is that of time-scaling (tempo manipulations). If an application wishes to offer the ability to time-scale played items, and do so with instant feedback through to the output—ie. changing the time-scale factor results in an instant change in the sound being heard—as does OtsAV, then it becomes subject to the limitations discussed in this paper. An understanding of this point is fundamental to the whole area otherwise one may be falsely led to claim that "application x is perfectly stable and it provides low latency and instant control", when in fact the application is not actually within the class of applications being discussed here at all.
It must be stated that even StablePipe™ does not guarantee anything with absolute certainty—nothing and nobody can on the Windows platform! What StablePipe™ does mean, is that you will obtain consistently stable results and forever, as long as certain basic conditions are met. The conditions are not onerous—most systems meet them without any special care or actions taken on the part of the user—and are things that are usually more relevant as a once-off during initial setup and configuration (eg. not having an installed driver that is buggy and causing the whole system to unconditionally halt for long periods—no app operating on Windows with minimal buffering and demanding absolute stability can omit such a condition).
However, the list of things potentially affecting other realtime audio apps which do not feature StablePipe™ technology, especially when occurring at particularly vulnerable times—things like starting up another application, minimizing/maximizing windows on the desktop, simultaneously running other intensive applications, etc—are not among the list of things which will normally affect the stability of OtsAV. Basically, if it's possible for an application to survive a given interruption or interrogation from something the user is running or doing, then OtsAV will do so! Absolutes above that can not be given because a user (even unwittingly) can run anything on their PC—it's far from a closed and controlled environment.
In summary, StablePipe™ will almost certainly provide you with the most consistently stable audio output for a Windows realtime audio application whose design goals mandate both very low latency and ability of full control over the outgoing stream. While it doesn't completely negate your responsibility as system-maintainer to provide a machine and operating environment that is capable of realtime audio, once you've used it, understand the difference and its full implications—and possibly have experience with other realtime audio applications—it's unlikely you'll ever want to settle for anything less, at least for this class of application where the design goals all make sense. It's certainly by no accident that OtsAV has attained the reputation as the most stable playout system of its type on the Windows platform!
While the main focus of this paper has been on stability, it's worth also looking at the issue of reliability since the concepts are somewhat related. In a sense, stability can be thought of as short-term reliability. Overall, reliability can perhaps best be explained as the application always performing correctly in the manner for which it was intended, or that of which the user expects. Reliability, therefore, is concerned with much more than just audio stability.
In addition to rock-solid stability, OtsAV is also known as an extremely reliable application and has earned this reputation over a decade of use—even the very first version had the same foundation and core design architecture as the latest. Some users have been known to run OtsAV for more than a year straight—without a single restart or system reboot! And here at Ots Labs we've certainly notched up some impressive statistics ourselves. This kind of performance is not something Windows and its applications are typically known for and it's an endorsement we're proud of.
Reliability, of course, is also about far more than just impressive running times (though these can be a great indicator). The design and architecture of OtsAV has been purposefully crafted to limit dependencies on external factors as much as is practicable. This extends to APIs, libraries and operating system layers—which we limit use of to the minimum subset we reasonably can—and also to the design and employment of the Ots Media™ file format which provides a great deal of isolation—at crucial runtime—from the ambiguities, vagaries and incompatibilities of mainstream media formats, and the multitude (and inherent variance among them) of external codecs that are typically used to process and decode such formats.
Not only do Ots Media™ files provide all of the performance, efficiency, functionality and flexibility benefits that the format is well known for, but the adoption of this format—and quite specifically due to the way it has been implemented—means that Ots files act as a defacto media "filter", straining out all the typical file format "issues" and leaving a library of pure bitstream-goodness that is well-defined, maintainable and unambiguously decodeable/playable in any supporting software—and with a result that will be indentical on any machine, no matter its age, power, graphics card or other included hardware, operating system base, installed codecs, drivers, accompanying software, etc. This is a form of reliability you don't typically see in PC-based media applications and one that OtsAV customers have come to love, appreciate and absolutely rely on!
Other areas of—and reasons for—reliability stem from the internal architecture of OtsAV and very deliberate design decisions which in turn are mostly a result of Ots Labs' philosophies of design. In short, reliable applications don't just happen all by themselves—and unfortunately are becoming harder to find in our modern throw-away and fast turn-around culture—but a good working framework and solid foundation can be the basis for something that outlives even the wildest ambitions of its designers.
What is a playout system? »
What is DJ software? »
OtsAV Customer case studies »
OtsAV Customer testimonials »
About Ots Labs' market-leading technology and innovation »
Download OtsAV Free Trial »
IntelliFade, BeatMorph, ClearScale, TrueSmooth, IntelliARC, Ots Media, PureFloat, StablePipe and others are trademarks of Ots Corporation. Windows is a trademark of Microsoft Corporation. ASIO is a trademark of Steinberg Media Technologies GmbH. All other trademarks are the property of their respective owners.