Expectations-The OS

In the days before we started using computers in the home and studio for writing and recording orchestrally based music, manuscript, or "parchment" was the desktop of the day. Unlike a computer monitor, manuscript didn't need batteries, or power, and if you made a mistake, you used an eraser to perform the modern day equivalent of cut or delete.

There are many examples online of famous composers' drafting work, with mistakes either vigorously crossed out, possibly reflecting the author's frustration at getting it wrong, or patches of near transparent paper where a stone, or pumice, was used to scrape off most of the ink. Computers, and more importantly, the software, gave us arguably more freedom to edit, and formulate large and comprehensive scores in a far shorter timescale. I'd argue this point, as years of practise, and creative expectation gave me some pretty tidy skills, and efficency when it came to writing scores, and i still draft work this way, today. However i have to concede the modern computer has also given us many attributes as well, from using large and complex sample libraries, to efficient editing tools, and in a well setup professional system, great playback. This still depends on the skill of the operator, but one could say that for any craft, or occupation.

The Computer, as a working environment, has plusses and minuses, like any tool of use. And it's even more so in creative fields, where a user's vision can often lead them in directions that highlight a restriction, or missing feature in software, resulting in frustration, or, unless you're very determined and completely focused on what you have singing in your head, a dampening or stultification of the creative flow. This was never truer in the early days of music making software, but ironically, also less true, when we were working within parameters we understood to be the outer limit at the time. There were also some fine applications in those early days, as developers picked up momentum, and appreciated the simplicitiy of doing 1 job very well indeed. Early trackers and midi sequencing applications were like this, and although most had a flaw or two, they did the important stuff pretty well, within their design spec. Since then, both user and developer expectations have grown considerably, and applications these days can be highly complex, intuitive to user needs, configurable to more than one workfow design, and host a variety of features, useful or not, as the user perceives them. They can, ironically, be a lot more complex to operate, and are just as likely to kill worklfow, as an early incarnation.

None of this is relevant without  two things. An operating system, and some degree of skill and effort on the part of the user.

My early days in Linux, as mentioned previously, were filled with bewildering terms, designs, the formerly intimidating terminal, and syntax that had little to do with writing music, and everything to do with aspirations of a gig with NASA, seemingly designed to leave me on the other side of the fence, away from..."coders." This, as i learned, was a erroneous perception on my part, but i still sympathize to a degree with those who come to linux with expectations of continuing on where they left off in closed source, profit based operating systems, and interfaces. And why should they aspire to anything different. Music software grew up on windows and mac, and the creative community in general was subjected to decades of carefully engineered, software designated workflow, that literally TOLD the user which way to work. I say users deliberately here, as coders in general, in my humble experience, tend to blur the lines between OS's with their perspective of code framework and design, before OS "brand".

Users had no such choice, and were, and still are, entirely at the mercy of the closed sourced operators, and what seems a perpetual quest to drive software development by profit, with the user experience as a close second, depending on how much profit potential it has.  Fora to this day are replete with workflow angst, and the general plea from serious users, to "get the basics right."

Finding an operating system that was infinitely more configurable, user oriented, and importantly, offered a fruitful collaboration and a partially at least, altruistically based partnership between developer and end user, was a powerful attraction. I heard a lot of what is now known as FUD along the way. Lines like "But it's for geeks", and "linux audio sucks!" came up on a regular basis, along with the inevitable condemnation from those who had tried and failed, and in most cases, unfairly blamed the entire OS for their own lack of commitment, effort, and most importantly, lack of idea of what they wanted. More than any other reason i've heard, or seen written, this one, imho, is the end result of much of the guff and chaff about linux, linux audio, and other urban myths. This is, frankly, FUD. If users put as much time into learning how to use and operate a linux based system, as they have win or mac over the course of their lives, then they'd see nothing out of the ordinary at all in using the powerful toolset, or writing their own scripts, or quickly building a small tool to so a task. It'd be like having breakfast, or riding a bike, or any number of routine tasks and expectations we fill our daily lives with.

So, let's get on with the foundation, and why linux audio works so well, imho.

As a user, i want some reliability, first and foremost. I had a studio based on 5 gigastudio boxes, and it averaged a crash at least once a day, often more, based on the windows operating system. Frankly, looking back now from the comfort of my reliable and powerful linux OS, it sucked, badly. So i have high expectations of what constitutes a reliable rig, and the experience to quickly ascertain how much or little work i have to do on a daily basis, just to keep things running smoothly. In the course of thinking of what to write in the expectations series, i did a rough calculation of what it took each day to keep my modest studio rolling.

3 hours a day. Non Productive maintenance, just to keep the system running, all day, and a good chunk of each night too. Some days were more, others were less, but that's a fair figure, and reflects my personal view that "commercial reliability" is nothing more than a profit driven OS gimmick designed to provoke you into parting with your hard earned cash for poorly written code, and usually far removed from any reality. And the irony is, if i'd devoted 3 hours a day backl then to learning to code, for linux, i'd be at the very least, a code janitor by now, instead of having to solve the same problems, the same way, every time, with the same deafening wall of silence, from the OS license owner. It was the same with mac, although the spinning beach ball remains to this day an artful piece of deception, designed as it is to lull the user into the false hope that things will "recover", or somehow return to normal.

Next, i want to start the box, and have it start the same way each time, without complaint. I don't want to take time out defragging or checking drives, or any number of tasks that require you to be logged in, and spending your valuable time sorting out stuff that is, in effect, a workaround for inefficent, and arrogantly sloppy coding. I'd rather have that admin stuff happen, where possible, while the box is booting up, and i have coffee, and a bite to eat before i get into a productive and trouble free day. When i sit down, i expect to be ready to go.

When i set the sound up, i want it to work, within the parameters i set, with the understanding on my part as a user, that the hardware and software perform within certain specs, and if i exceed them, and something goes wrong, then i'm the one to blame, and not chorus to the world that "Linux Sucks." It doesn't. More often than not, my skills suck, and that reality is one i fight to change, on a daily basis. A workman shouldn't blame his tools, right?

Let's kill another urban myth here..

"There's so many sound options in Linux! Why can't they have just one like windows?!!!"

Well, let's compare apples with windows with linux. Windows has multiple options like MME, DirectX, Asio (the protocol developed by a private company, because vanilla windows audio sucked for musicians, and ms aren't going to fix it. Ever.), and others. Apple has coreaudio, and at least it's one system i guess, although those of us on the wrong side of 40 will remember how many times Apple tried to get it right, and failed, often spectacularly, and usually at our expense. Trying to run multiple audio apps with coreaudio isnt easy, and even with the latest aggregate features, it's still problematic for some.

Linux has 4, being ALSA, OSS, JACK, and Pulseaudio, but the important difference here, is Linux has "Stacked" audio (Thanks Paul, i was searching for a way to describe this). Jack sits on top of ALSA, and either ALSA or the remnants of OSS will interact directly with the kernel. Pulseaudio is a domestic use server for Desktop users, and doesn't fit into any sort of professional audio useage case. It's not designed that way, and it's a bit flaky at the moment, even within it's own design spec. But it's stackable too, and uses ALSA or OSS as the kernel modules.

Putting all of this together though, one burning question remains. With all these options, in any OS, does the USER know what he or she wants?

A resounding No is the answer, in most cases, and i made the point before about multiple choices, and exceeding design specs. The reason Linux Audio is perceived to be less than optimal is user experience based on their own expectations, usually imported from other OS, and exceeding specs, something they couldn't even neccessarily do in a previous OS life, because they weren't allowed to, as any sort of audio enhancement was deemed unprofitable for the "tiny" niche of users who want to write music on a serious basis.

Whatever studio success stories you may tell, the bit that doesn't get mentioned is the high maintenance involved, or the embarrasment of having to deal with a "Your application has stopped responding", or that highly irritating spinning beachball, in front of a client. Apples and digital oranges...... In these cases, the story teller is usually attemping to justify their financial outlay, as if they've been "fiscally clever" in some way, and studiously and sometimes belligerently avoids any unpleasantness involved in a coldly practical assessment of rig performance.

The reality is a fulltimer wants stuff to work, and doesn't care that much what the brand on the box is, unless it's Neve, or they've willingly bought into another urban myth that describes Protools as some sort of "Industry Standard."

Users hold the responsibility here, and should step up and take it. If you're asking an OS to multitask, outside of the software design, then frankly, you deserve what you get, and no amount of bleating gets away from the fact that using an onboard soundchip to attempt to record a masterpiece, is aking to putting a  2CV 2 stroke motor in a Lambourghini, and then complaining it doesn't sound right.

You're right. It's going to sound horrible, and you did it. You can't do a decent job of recording a great piece of music with the onboard sound chip in ANY operating system, so blame them all, if that's your way of justifying the inevitable. If you want to run a professional sound system and play games or youtube all day at the same time, well, tough. It's your choice, and you'll get exaclty what you set yourself up for. So, for domestic use, use a domestic setup.

For professional use, you'll need a decent soundcard, a solid OS, a  robust, powerful, professional sound server, and the effort required on your part to make it work together, reliably, day in, day out, as it's your job, and keeping a steady stream of pizza deliveries, paying the electricity bill, or feeding the groupie, depends on it.

We have this in Linux Audio already.......

Stay tuned.....