id Software: Linux Hasn't Produced Positive Results

[Scali]

My entire point is those said updates SHOULDN'T be causing programs to stop working in the first place.

Yup, I fully agree. But we know from experience that this is certainly not the case, and I don't see that changing anytime soon (these are independent projects, who don't care at all for Valve and its applications), so I assume there will still be breaking changes in the future. So I wonder how Valve/Ubuntu will deal with that.

[Scali]

And internal kernel api is none of your business anyway.

It is, indirectly. Namely, Valve depends on nVidia's binary drivers. These drivers depend on the kernel API, and they have a long history of new kernels breaking existing drivers, requiring updates from nVidia.
New kernel means no nVidia drivers, means no Valve games.

[Scali]

And what has your app to do with xorg or the kernel?

Games need OpenGL, OpenGL needs display driver and Xorg, Xorg and display driver need kernel.

[yogi_berra]

And what has your app to do with xorg or the kernel?

Try playing the loki port of Tribes 2 (or any of their other games) in a modern distribution and see for yourself.

[ownagefool]

Games need OpenGL, OpenGL needs display driver and Xorg, Xorg and display driver need kernel.

Thats an argument that OpenGL should be a well defined standard that the games should code against then, don't you agree?

Try playing the loki port of Tribes 2 (or any of their other games) in a modern distribution and see for yourself.

I don't own a key, so I won't bother, but I'll assume for arguments sake that the game doesn't work. That isn't an argument against the kernel instability, but that libraries inbetween Linux and the game are at fault, or that the game itself was poorly ported. Given that I was playing ut99 last year on ubuntu, I'd hazard a guess that this is a mostly solved problem. If not, I would imagine one of the pieices of work in the future, will be an open source compatibility layer to solve any such issues.


P.S. I don't imagine that the NT kernel devs stop working on their kernel just because Windows is sitting on what is basically an LTS version. Nobody says you need to install a new kernel every few weeks.

[ninez]

Man, you have completely lost it. All I see is you (wrongly) assuming that I don't know what I'm talking about, then jumping to all sorts of far-fetched conclusions, and just insulting me, and you keep pounding and pounding and pounding.

Sorry Scali. But over and over you have made claims, that simply weren't true - that isn't making assumptions, that it looking at the facts.... You insulted me a whole lot to, so for you to have the expectation that it can only be a one way street - is well laughable... and as i said before that argument holds no weight... and you're right, i did keep pounding and pounding - responding to every single one of your bogus claims and unlike you, actually backed them up.

Anyone can tell you that your own links don't even support your case (like that link you posted, where they literally say ASIO itself works fine, there is just a problem with some cheap hardware/poor drivers (hence WIFI issues and such). This doesn't happen on Macs because Apple doesn't ship cheap hardware and poor drivers in the first place. Can't blame Windows for cheap hardware with poor drivers).

Microsoft is the one whom lays out how their OS works and how drivers are to interface with it - not the manufacturers. And when MS doesn't go to the same effort as Apple does, through coercion of well-defined interfaces for 3rd parties to make 'proper choices' in coding practices in writing drivers - that does fall on them. I am not 'blaming' MS - just pointing out the reality of the situation. Of course buggy firmware, low quality H/W can be a problem, but that is only one piece of the problems that exist. Some of them are MS issues, while some are not. But it is essentially a moot point, because 'generally speaking' - Apple provides a better platform for Proaudio than MS does - since it is actually something important to them (apple), while to MS it really isn't.. I'd also like to point out while you sum it up to 'cheap' hardware - i don't consider a firewire interface that is worth $1000+ to be 'cheap' - we obviously have very different standards :\

Moving on, So you accuse me time after time of not having any 'reading comprehension', and yet clearly you have demonstrated AGAIN that it is actually you whom is having comprehension problems, furthermore i can demonstrate (very easily) either A) your lack of comprehension B) your making fallacious claims, totally misreperesenting what i actually said (hence why you didn't bother to quote what you are trying to quote me vs. the article) C) that you are disingenuous or D) ALL of the above;

The problem with Windows and Proaudio doesn't just come down to ASIO vs. CoreAusio - there are bigger issues such as, developers having to deal with 1000s of different H/W configurations, when making drivers/other software ~ developers/companies targeting Apple do not have this problem. The fact that MacOSX scheduling is much better than Windows, at least in terms of proaudio interfaces, the OS stays out of the way... Here is an article that discusses these and some other issues. You might want to read the part that a developer from Focusrite/Novation has to say about Win vs. Mac for proaudio;

http://www.djtechtools.com/2010/06/2...-macs-and-pcs/

There are also a lot of other articles similar floating around the web. ASIO isn't bad, it's actually pretty good, but like i said it really isn't necessarily the big issue ~ and your perception of CoreAudio is blatanly absurd.

Now, from the actual article;

If ASIO is as good as Core Audio, and the people writing Windows audio drivers can manage to make them work with every possible hardware combination, then Windows latency should be the same as Mac, right? Perhaps not.

Hodder describes for the layperson why extra latency may be unavoidable on some Windows machines. ?There?s a difference in the way the OS handles task scheduling,? he said. ?On Windows, a degree of cooperation between the drivers on the system is required. If any one of them doesn?t play by the rules (which are not enforced by the OS), the performance of the entire system is degraded (DPC latency). This interference from other drivers can mean your driver performs poorly on some systems?no matter what you do! The Mac architecture does not suffer from this problem, making performance a bit more predictable.?

and..

Macatee is on point when he says: ?It?s a difficult task for Microsoft to make a software operating system for a hardware device that can be built by anybody and has to support all known applications in the world. That?s no small feat.?

The conventional wisdom on this topic is that Macs generally perform better than PCs with audio latency, and the sheer complexity in the Windows universe seems to have lead to this.

and..

Dave Hodder, Product Development Engineer for Focusrite/Novation, explained that ?The Mac development path is well defined, so you can focus almost immediately on writing the audio engine itself. *On Windows*, there are several ways to make a driver, and they don?t focus on high-performance audio, so there?s a lot more work to do before developing your audio engine. But the Windows development tool chain is arguably better than the Mac?s. Analyzing a crash dump after a ?blue screen of death? is a joy compared to the Mac.?

I could go on, but i don't even half to. You'll notice the bold parts of both my and the article's correspond, where as your 'opinions' do NOT. You have demonstrated that you fall into category A B C and/or D - that i listed above. So on the consistency of my points vs. this article - i was VERY consistent, where as you are pretty much ignorant or FOS.

The same is true of your linux isn't strong at providing low-latency - by saying that - you did in fact (whether intentional or not) to be claiming that you know better than all of the many companies in the music industry using rt-linux (and every other company in every other industry using it). It was dumb statment on your part, that clearly shows you don't know much about this stuff... and when you claimed shortly after that 'i must be doing something wrong, for tweaking windows' - you were asserting the same nonsense of knowing better than the leaders of the industry and companies whom specifically tweak Windows for their Workstations...

I'm sorry you can't think critically, and are too consumed by your own ego and biases to not understand some pretty simple stuff here, but at the end of the day - that is your problem. But if i were you, i would start using my brain before speaking :\

[Scali]

Microsoft is the one whom lays out how their OS works and how drivers are to interface with it - not the manufacturers.

Yes, in a perfect world, everyone does exactly what Microsoft prescribes, and all hardware and drivers are perfect and bug-free.
But the world is not perfect, so the moment you allow third parties to sell hardware, write drivers or applications, you open up your platform to potential issues of resource hogging and whatnot. Apple's OS X is not immune to this (it somehow sounds like you think OS X has some unicorns and fairy dust that prevents the system from ever becoming unresponsive, crashing or whatever else. I know from experience that this is not the case), it's just that it is more rare on OS X, because of various reasons.

One experience I had was with an Athlon system with VIA KT133A chipset. It just WOULD NOT run properly with low latency, even though I used the same Terratec EWX24/96 card that worked fine in various other systems, or some USB devices that would easily get ~3 ms on other systems. The problem was that VIA's chipset and drivers were just very poor, and ran into trouble at the 25 ms mark already.
On systems with Intel chipsets, things worked fine, both for PCI and USB devices.
Now, have you ever seen any Apples with VIA chipsets? And how many Apples have Intel chipsets?
So I think I know why Apple users would never run into this particular problem...

Apple provides a better platform for Proaudio than MS does - since it is actually something important to them (apple), while to MS it really isn't..

The beauty is, Microsoft doesn't have to.
ASIO is a standard defined by Steinberg, just like VST.
ASIO is more or less the audio equivalent of OpenGL in the sense that it is not the 'official' Microsoft API, but the Windows driver model is open enough that IHVs can implement these alternative standards themselves.
So like OpenGL, ASIO is not dependent on Microsoft at all. If you want the latest version, you just get the latest drivers from your IHV. ASIO is a direct interface to the driver, and does not rely on any common layer of functionality like DirectX or CoreAudio.

I'd also like to point out while you sum it up to 'cheap' hardware - i don't consider a firewire interface that is worth $1000+ to be 'cheap' - we obviously have very different standards :\

I doubt it's the firewire device that's causing the issues, see above.
Connect expensive firewire device to el cheapo firewire port... and you have a recipe for disaster.
Apples don't have el cheapo firewire, ever.

Now, from the actual article;

Firstly, developers don't have to deal with all those hardware configurations at all. Neither do users.
Secondly, even if these developers *did* have to test on various hardware configurations, I don't see how that affects users at all.
If it works, it works, right? Users could care less about how much trouble the developers went through. They just want a product that works.
And as the article states, as long as you don't have any 'rogue' drivers on your system:

Generally speaking, ASIO drivers are no less capable of delivering low latencies than Core Audio, a stance backed up by Steve Macatee, Director of Product Development at Rane Corporation. ?We consistently see ASIO and Core Audio performing with the same high quality and low latency,? he said

So that already completely debunks your claim of CoreAudio being "vastly superior" and delivering "much lower latencies".
I on the other hand merely said they were about equal in terms of latencies, which this article supports just fine.

So on a properly functioning system, ASIO works fine. Which means that neither Windows nor ASIO have any inherent problems that prevent them from reaching low latencies. This is supported by the article you're quoting.
Now clearly you're walking a *very* thin line when you try to blame Microsoft for some rogue third-party drivers (you even claimed Windows has broken scheduling and such... not at all, because if they did, *no* device would *ever* work properly with ASIO, but clearly your article says this is not the case).

The same is true of your linux isn't strong at providing low-latency - by saying that - you did in fact (whether intentional or not) to be claiming that you know better than all of the many companies in the music industry using rt-linux (and every other company in every other industry using it).

When I say 'linux', I mean linux, as in the official linux branch, not 'rt-linux'.
Clearly, a custom version for realtime usage would have more strict timing than any non-realtime system, by default (at the cost of higher CPU usage). Windows is not a realtime system, nor does it try to be. It is however a 'near-realtime' system, and a good one at that, since unlike linux for example, you can do most (near-)realtime audio/video processing out-of-the-box with Windows.
In fact, my company specializes in realtime video processing/projection. We aim to support Windows, OS X and linux, so I think I have a reasonable idea of how the various systems work under such circumstances.

So no, I never said anything about companies using rt-linux, and I suppose rt-linux could work just fine, since it is designed for low latencies, as long as they put enough CPU-power in their systems.
Doesn't rule out that they may be able to do the same thing with another OS using less powerful CPUs though.
However, I found that in general, the choice for linux in such embedded systems is because it is the simplest solution: they can just grab the sourcecode and modify it to their needs, rather than writing something from scratch. I've worked at companies that used linux for their custom hardware for the same reason. And our company may build a linux live DVD in the future, because it would make for an easy turn-key solution.
Windows simply does not give us that option. Hardly a technical consideration.
So I wouldn't be so naive as to think that every company using linux is some kind of confirmation of linux' absolute technical superiority.

and when you claimed shortly after that 'i must be doing something wrong, for tweaking windows'

Disabling/removing hardware does not qualify as 'tweaking Windows'.

[Scali]

Thats an argument that OpenGL should be a well defined standard that the games should code against then, don't you agree?

Not sure what you mean. OpenGL is a well-defined standard. Problem is, it's just an API, and doesn't define how it should be implemented on an actual OS.
Aside from that... As already pointed out, if you want to develop games or other 3d accelerated software on OS X, linux, FreeBSD, Android etc, you don't have a choice but to use OpenGL. So what games 'should code against' is always a given on these platforms.

[ninez]

Yes, in a perfect world, everyone does exactly what Microsoft prescribes, and all hardware and drivers are perfect and bug-free.
But the world is not perfect, so the moment you allow third parties to sell hardware, write drivers or applications, you open up your platform to potential issues of resource hogging and whatnot.

I don't care what happens in some imaginary 'perfect world' ~ the Bottom line, Apple defines to 3rd-parties how to write software/drivers/etc for their platform FAR better than Microsoft does. End of story.

Apple's OS X is not immune to this (it somehow sounds like you think OS X has some unicorns and fairy dust that prevents the system from ever becoming unresponsive, crashing or whatever else. I know from experience that this is not the case), it's just that it is more rare on OS X, because of various reasons.

So now, you are yet again, misrepresenting my position - talking utter CRAP and then smacking it down - to give yourself some points... What a fucking joke you are. Did i EVER claim it was impossible to Crash a Mac?!?! - NO i did not. In fact, i actually gave an example where i did crash it. Where do you even come up with this stuff?!?! stop making up shit! it just makes you look obtuse.

One experience I had was with an Athlon system with VIA KT133A chipset. It just WOULD NOT run properly with low latency, even though I used the same Terratec EWX24/96 card that worked fine in various other systems, or some USB devices that would easily get ~3 ms on other systems. The problem was that VIA's chipset and drivers were just very poor, and ran into trouble at the 25 ms mark already.
On systems with Intel chipsets, things worked fine, both for PCI and USB devices.
Now, have you ever seen any Apples with VIA chipsets? And how many Apples have Intel chipsets?
So I think I know why Apple users would never run into this particular problem...

So what you are essentially saying then (which i have been saying all along) is that Apple typically designs a better platform for Proaudio than Windows/their OEMs typically provide <- Thanks for finally admitting that. Unlike you - i don't need to blame Windows, Apple or the hardware or make some other excuse. Microsoft defines how their os works, their driver model, APIs, etc, etc ~ and they work with the OEMs that ship computers with their 'seal of approval'... Apple IS better for Proaudio, typically. (just to make that clear, yet again!).

The beauty is, Microsoft doesn't have to.
ASIO is a standard defined by Steinberg, just like VST.
ASIO is more or less the audio equivalent of OpenGL in the sense that it is not the 'official' Microsoft API, but the Windows driver model is open enough that IHVs can implement these alternative standards themselves.
So like OpenGL, ASIO is not dependent on Microsoft at all. If you want the latest version, you just get the latest drivers from your IHV. ASIO is a direct interface to the driver, and does not rely on any common layer of functionality like DirectX or CoreAudio.

I am well-aware whom ASIO is developed by, the history, etc, etc. I never claimed ASIO was dependent on Microsoft, however the only platform it is used on is Windows (WineASIO in linux, is just handing it of to jack)...as a side note: Something interesting to point out though, being as you were constantly arguing in favor of OOTB - you do realize that OOTB Windows can't even be used for proaudio, while a Mac can... Also the 'real beauty' is that Mac's are largely designed with these goals in mind, so it's no surprise they tend to get it right out of the box, working across their hardware - while MS relies on a 3rd-parties, outlines bad driver development practices, puts their stamp of approval on junk hardware and since not designing their OS with professional audio in mind at all. Suffer from problems that Mac's typically won't.

I don't know where you get the idea that it is a beautiful thing. it's shit really.

I doubt it's the firewire device that's causing the issues, see above.
Connect expensive firewire device to el cheapo firewire port... and you have a recipe for disaster.
Apples don't have el cheapo firewire, ever.

Except for the fact it wasn't 'cheap hardware' not the device, not the MOBO (which was Intel with i7) and not the firewire port (which was not via). - this is the only thing you can say, really - blame it on the hardware. ~ you are very slippery! ..but your right, Apple doesn't ship cheap firewire interfaces - that's because they know many of their customers will be *using those ports*. MS and many OEMs do not give a shit - they just want your money, and since they are more concerned with Office/business and don't target proaudio in many cases, i don't think they care about quality in many cases.

...and again, another reason why Mac's tend to be better for Proaudio than Windows Machines, especially going with your own OOTB approach - which your such a big fan of

Firstly, developers don't have to deal with all those hardware configurations at all. Neither do users.
Secondly, even if these developers *did* have to test on various hardware configurations, I don't see how that affects users at all.

When did i assert either of the things you are saying above? i didn't. Developer/programmers writing those drivers may not have to test them on all of that hardware, but if they wan't people to buy and use their devices, it has to work properly ~ or they just lost a customer (for the long term) and rather than quoting one meaningless sentence and replying to it. could you please actually quote what your are responding to (?).

If it works, it works, right? Users could care less about how much trouble the developers went through. They just want a product that works.
And as the article states, as long as you don't have any 'rogue' drivers on your system:

IF it works...but what if it doesn't? sorry, you are out of luck, end user - should of bought a Mac, and not played 'Russian roulette' with Windows and the OEMs selling that junk ~ since you may be a non-techy musican who probably isn't aware of Via chipsets being bunk, etc... Rogue driver is pretty vague, how is john-doe musician going to know the difference? (hint: he wouldn't). Basically, what you are driving at is that Musicians should focus more on the underpinnings of Windows and beware of the OEMs and know all of the specifics of what chipsets are in their computer, rather than just making music. Sounds awesome! ~ No wonder Apple is the preferred platform!

So that already completely debunks your claim of CoreAudio being "vastly superior" and delivering "much lower latencies".
I on the other hand merely said they were about equal in terms of latencies, which this article supports just fine.

Except you are mis-quoting me YET AGAIN. What i actually said is that i think CoreAudio is superior to Windows audio subsystems and that OOTB in MacOSX - i get lower latencies (which is ENTIRELY true, ASIO is a 3rd-party's product). I love how fallacious almost everything coming out of your mouth is... what a crock of shit. you are either incompetent, stupid or smart but extremely deceitful - take your pick :\

So on a properly functioning system, ASIO works fine. Which means that neither Windows nor ASIO have any inherent problems that prevent them from reaching low latencies. This is supported by the article you're quoting.
Now clearly you're walking a *very* thin line when you try to blame Microsoft for some rogue third-party drivers (you even claimed Windows has broken scheduling and such... not at all, because if they did, *no* device would *ever* work properly with ASIO, but clearly your article says this is not the case).

I'm not blaming Microsoft and we have been through this. Apple provides a 'proper way to do things' when developing on their platform, Microsoft is much looser, which can lead to problems in their drivers. I also NEVER said there scheduling was quote 'broken', both the Article and myself cited that;

?There?s a difference in the way the OS handles task scheduling,? he said. ?On Windows, a degree of cooperation between the drivers on the system is required. If any one of them doesn?t play by the rules (which are not enforced by the OS), the performance of the entire system is degraded (DPC latency). This interference from other drivers can mean your driver performs poorly on some systems?no matter what you do! The Mac architecture does not suffer from this problem, making performance a bit more predictable.?

that doesn't mean it is broken, it just means Mac's don't have this problem. Again, stop being so disingenuous, i have a better memory than you apparently and see right through your fallacious bullshit. end of story.

When I say 'linux', I mean linux, as in the official linux branch, not 'rt-linux'.
Clearly, a custom version for realtime usage would have more strict timing than any non-realtime system, by default (at the cost of higher CPU usage). Windows is not a realtime system, nor does it try to be. It is however a 'near-realtime' system, and a good one at that, since unlike linux for example, you can do most (near-)realtime audio/video processing out-of-the-box with Windows.
In fact, my company specializes in realtime video processing/projection. We aim to support Windows, OS X and linux, so I think I have a reasonable idea of how the various systems work under such circumstances.

When we are talking about low-latency systems built using linux - we are talking about rt-linux not 'generic' linux, and as someone who felt it was necessary to point out to me that those were ingo's patches (albeit outdated info) you knew what i was talking about... You are just back-peddling, just like you did before (and now again) with your OOTB nonsense, alternative kernel nonsense and unofficial patch nonsense. ~ it all a load of crap. You are just slippery and just VERY dishonest. As i said before 'Windows can't replicate my system OOTB (and probably not at all).

You run any system at extremely low latencies / small samples (even in Windows or Mac) you will experience higher cpu usage, You claiming to the contrary is BS - i have seen this with my own eyes countless times over many many years... I don't give a shit what your supposed 'credentials' are, you have been wrong about so much crap with so many fallacious comments(including the above appeal to authority), i can't take you seriously at all. Go peddle your nonsense elsewhere.

So no, I never said anything about companies using rt-linux, and I suppose rt-linux could work just fine, since it is designed for low latencies, as long as they put enough CPU-power in their systems.
Doesn't rule out that they may be able to do the same thing with another OS using less powerful CPUs though.

Like i said before, Go tell that to Muse Research, Harrison Consoles, etc. Tell them to use MacOSX or Windows in their products over RT-linux. and FYI - Muse Reseach's products don't have have crazy CPUs - they are mobile/laptop CPUs - but they wouldn't be using Windows in their products, even if it did allow them to use 'less powerful CPUs'.

However, I found that in general, the choice for linux in such embedded systems is because it is the simplest solution: they can just grab the sourcecode and modify it to their needs, rather than writing something from scratch. I've worked at companies that used linux for their custom hardware for the same reason. And our company may build a linux live DVD in the future, because it would make for an easy turn-key solution.
Windows simply does not give us that option. Hardly a technical consideration.
So I wouldn't be so naive as to think that every company using linux is some kind of confirmation of linux' absolute technical superiority.

Windows is limiting, i'll agree with that. Now, that we've gotten that out of the way, Riddle me this,then ~ why were you telling me (and arguing) that i should be running my VSTi's in Windows over linux when CLEARLY it is NOT suited for my purposes..??! That was completely moronic. You are forgetting the part where you claimed that Wine was for people whom wanted to run their 'hated' windows software, even though it is actually WAY smarter for me to NOT do what you were saying i should be doing (aka: using Windows over linux). I also cited the success of a company like Muse Research - since they are doing essentially the same thing - and make VERY high-quality products that are used by a great many professionals. They are a great example, after all - of why your arguments are silly ~ My considerations were both technical and logical...Your considerations are based on uninformed junk...

Disabling/removing hardware does not qualify as 'tweaking Windows'.

Strawman. I clearly said in both instances 'tweak Windows' NOT 'tweak workstation FOR Windows'. But you already knew this, since before hand you told me and I quote " if you need to tweak a Windows machine for better low-latency with today's hardware, you're doing something quite wrong" ... so clearly, you were WELL-AWARE that i was not talking about tweaking hardware.

Who said anything about disabling/removing hardware??? i sure as hell didn't. They tune the OS - not remove hardware (but do use high-quality parts) - and YES windows can be tweaked - but why do i need to tell you this, you're the expert, right??? and since you are the expert, it really does beg the question -> how come you didn't even consider that these companies actually modify some of windows settings to improve it for their more specific task???? Can you explain this to me, please??? because from where i am sitting, you really come off as not knowing much about this stuff...

someone as 'knowledgable' as you, who owns a cutting-edge company making (near)realtime audio/video apps/products would surely already know all of this stuff. But i guess you do not, and probably shouldn't even be arguing about it, in the first place.

[Scali]

I don't care what happens in some imaginary 'perfect world' ~ the Bottom line, Apple defines to 3rd-parties how to write software/drivers/etc for their platform FAR better than Microsoft does. End of story.

No they don't. But what would you know? Did you ever write a driver for any of these platforms? Because I have.

So what you are essentially saying then (which i have been saying all along) is that Apple typically designs a better platform for Proaudio than Windows/their OEMs typically provide <- Thanks for finally admitting that.

Lolwat, Apple uses off-the-shelf Intel CPUs and chipsets, like most OEMs do. AMD-based machines are rare, and non-Intel chipsets for Intel CPUs died out years ago because Intel stopped licensing the bus on their newer CPUs.
The machine I described was decidedly a-typical and low-budget.

Also the 'real beauty' is that Mac's are largely designed with these goals in mind

The obvious flaw in your reasoning is that you think that 'pro audio' is somehow some specific functionality that you can just 'put in your OS'.
It's not. Pro audio software is just software, and pro audio hardware is just hardware.
The only requirement is that of low-latency I/O.
Now while Microsoft does not specifically target pro audio, they *do* target low-latency I/O, since it is a more common problem, and proper low-latency I/O will make the OS suitable to a large variety of software, which Microsoft *DOES* target.
You just don't seem to see the bigger picture.

For Apple, audio is one of their niches, so they market their machine to maintain or even extend their marketshare there. Doesn't mean there's anything more than marketing in it.

Apple doesn't ship cheap firewire interfaces - that's because they know many of their customers will be *using those ports*.

Apple was committed to firewire early on, they saw it as a superior solution to USB.
The PC-world instead went for the cheaper USB option, and as such, firewire interfaces were rare, and usually cheap third-party solutions were added to systems.
Apple does not cater to the budget market, so they can afford to make their machines more expensive, and add things like Firewire and SCSI interfaces.
Such PCs have always existed as well, if you look at the more expensive workstation series from Dell, HP or Compaq. It's just not what most people buy, because they go for the bargain basement stuff. Gee, not surprising if a PC of half the cost of an Apple doesn't quite work as well.

MS and many OEMs do not give a shit - they just want your money, and since they are more concerned with Office/business and don't target proaudio in many cases, i don't think they care about quality in many cases.

Actually, the 64-bit version of Logic was one of the applications that Microsoft used to promote Windows XP x64.

Except you are mis-quoting me YET AGAIN.

Not at all: http://phoronix.com/forums/showthrea...096#post281096
"MacOSX OOTB has much lower latency than windows (and a superior audio subsystem aka: CoreAudio)"

The out-of-the-box thing is utterly meaningless obviously, since you do not need to make any changes to your Windows configuration at all to get low latency. All you need is a proper ASIO device.

Oh btw, I didn't see your rant earlier on guitar fx.
Sadly for you, I'm actually a 7-string playing shredder. Playing fast, REALLY fast is what I do.
You're also wrong about older guitar fx being slower. If anything, they were faster, because they were mostly analog. It's mostly the early digital modelers that can be rather annoying in terms of latency and response. But not my PC setup. Plays just fine.
Besides, guitarists generally play over real amps, not digital crap, so they know what NO latency is like.

So, nice try, but as usual, completely uninformed and mostly your wrong assumptions.

You run any system at extremely low latencies / small samples (even in Windows or Mac) you will experience higher cpu usage

As usual, you don't quite seem to understand the context here, so let me point out the obvious:
On linux, if you tweak it for 'lower latencies', you are actually reducing the timeslice length of the entire system, meaning you get more CPU usage *all the time* because the system performs more context switches per second.
On Windows you do not need to modify the timeslice length at all, you do not need to 'supercharge' the thread scheduler to make it more responsive. Out-of-the-box settings are good enough for < 1 ms latencies.
As a result, the CPU usage is the same as it always was.

Like i said before, Go tell that to Muse Research, Harrison Consoles, etc. Tell them to use MacOSX or Windows in their products over RT-linux. and FYI - Muse Reseach's products don't have have crazy CPUs - they are mobile/laptop CPUs - but they wouldn't be using Windows in their products, even if it did allow them to use 'less powerful CPUs'.

Right, once again you don't quite get what I'm saying. I said that if it works for them, then why not.
Also, obviously as long as your processing requirements are low enough, then so are your CPU needs. Even my phone can easily run most of the VSTs that I used 10 years ago. That however does not change the fact that the CPU overhead may be higher than with another system. That's all I said. But apparently you are having trouble separating absolute and relative characteristics.

Who said anything about disabling/removing hardware??? i sure as hell didn't.

Yes you did, but you probably weren't aware of it.
You quoted those statements about DPC overhead in Windows and all that.
The only way to get rid of that DPC overhead is to disable the device whose driver is causing this. Hence, disabling/removing hardware.

The longer you rant on, the less convincing you sound...