"On the other hand Vista's audio system provides automatic calibration that detects the distance of a presumed head position from each of your speakers then adjusts when it delivers the audio signal to each speaker resulting in the audio reaching your head position simultaneously from all speakers."
That is a long way of saying: "Vista adds a configurable delay to output lines".
A separate scheduler class for time-critical processes is OK. Deliberately slowing down parts of system to make sure that your scheduler has lower latency is absolutely NOT OK.
Linus would have crucified anyone who proposed such a hack for the mainline Linux kernel.
I write drivers - it's kinda hard to test them on without a second computer. VMWare on my notebook works just fine with Windows XP - audio works perfectly with a pretty big safety margin of latency to spare. And Vista doesn't work well on the same hardware, despite its multimedia scheduler.
"Right. Zero latency. Talk about lies. It establishes callbacks in the apps, writing into shared memory segments which are then mixed and delivered to the standard linux audio device."
That's pretty much all I want from my audio system. Just give me a precise control over my audio stack and then you can build anything on top of it.
XP does exactly this - there's a fast, efficient, hardware-friendly kernel streaming layer.
Vista on the other hand forces you to use inferior-quality stack because MS couldn't figure out how to do protected audio path with kernel filters.
"Yeah. Zero latency as long as you stay ahead of the playback. Just like pretty much every sound system since the days of the original Soundblaster Pro using DMA."
DirectShow is famous for its imprecise timing control due to KMixer;) My previous employer made a lot of $$$$$$ by making time-correcting kernel streaming filters.
"Where's the signal processing layer in there? Oh, it's third party. Where's the channel synchronization? Can't find it."
Everything is third-party. JACK only gives you a microsecond-precise information about audio system. You can do the rest yourself.
"And shockingly enough it's all software. Where's that hardware acceleration you're so fond of?"
It's possible to have hardware filters in JACK. The problem is that hardware filters are not that useful for professional-type audio systems. Look at OpenAL/EAX for hardware acceleration of spatial sound and other goodies.
BTW, OpenAL Creative Drivers even work on Vista by bypassing all its audio stack.
"And what happens under load and the realtime scheduler can't quite keep up? Ah, I see, you get drop outs. What happens on Vista? Nothing, they hook into the scheduler to guarantee that their audio paths get time on the CPU."
Newsflash: if Vista scheduler can't quite keep up - you'll get sound drop-outs (I _do_ get them when I test my audio app on VMWare). There's no way around it. Realtime scheduler guarantees that your audio stack will get the highest priority, just like in Vista.
"It's not a matter of delaying individual streams. It's a matter of delaying individual channels from the same stream. So that your rear speakers sitting against the far wall behind you play just a bit earlier."
That doesn't matter. It's still not hard to do using kernel streaming.
I can distinctly remember that nice '3d-room' settings on my Creative Audigy 2 back in 2003. All in hardware.
I quite understand what Vista audio system does (down to the driver level). For one thing, it doesn't use hardware acceleration (!!!) anymore and does everything in software.
"It is by far the most advanced personal computer audio system available on any platform." - is a complete lie.
JACK (http://jackaudio.org/) is probably the best personal high-quality audio system (it has a zero-latency design). It's followed by PulseAudio which is now not quite yet zero-latency but much more efficient.
Adding some more latency into audiobuffers to adjust timing is a fairly trivial task. Also, a good implementation would just turn off this misfeature if the system uses only one sound sink.
Nope. CPUs nowdays use 'registers renaming' (http://en.wikipedia.org/wiki/Register_renaming) techniques, which give much larger effective register sizes.
And in any case, these data will be pre-fetched into L1 cache which is not shared between CPUs.
Atom CPUs use resurrected hyper-threading to cope with pipeline stalls and branch mispredictions. In the ideal world it should compensate for them almost as good as advanced out-of-order execution and branch prediction, but in the real world a lot of applications are single-threaded.
64-bits might help. Personally I'd better use a good architecture like MIPS with a lot of 32-bit registers;)
What exactly discredits my words? Vista got so bad at audio performance that they had to hack around it by slowing down other parts of the system (by adding 'multimedia class scheduler'). It exactly mirrors my observations.
I had to add a workaround to my application because waveOutGetDevCaps function became about 100x slower on Vista than on XP so it became impossible to use it in a single thread with interactive audio.
Also, empirical observation: it became impossible to work with video on Vista in VMWare on my notebook. Even though it worked fine on XP.
As for gaming benchmarks: I don't care about them. There are too many different parameters affecting them.
Filesystem performance (which already is more than 10 _times_ slower than on Linux) in Vista is also hit because of overhead of transactional NTFS and more complex stack.
Also, we can consider using money to fix this problem. For example, we can make all CAs put a big sum of money into an escrow account to be given to the first person who shows that CA doesn't perform 'due diligence' while issuing certificates.
It's better to use private companies with government oversight.
I now live in Ukraine and we have such a system. Government licenses private companies to work as certification centers and mandates that only certain (strong) crypto algorithms must be used.
As a result, I can use my private key to sign my tax report for IRS (or tax report for my company). IRS in turn uses its own key to sign their letters.
It's slow (some functions work _1000x_ times slower than on WXP), it doesn't support acceleration, etc.
Transactional NTFS sounds like a good idea. But I have already encountered subtle race conditions with it. Now I'm not even certain that it's possible to create a fully transactional 'classic' filesystem.
I'm a Windows programmer (in fact, I write everything from drivers to high-end enterprise software).
There's not that much differences between W2k and WXP from programming viewpoint. Actually, from my experience I can only remember using improved monitoring interfaces in WXP which were not available in W2k.
Also, Eastern Orthodox Christians celebrate Christmas on January 7, because they still use old Julian calendar and not the new-fangled Gregorian Calendar.
But why? FreeBSD, Linux and even Windows (http://www.fs-driver.org/) have native ext2/3 drivers which are much faster and feature-complete than FUSE drivers can be. There's just no need for FUSE.
Slashdot Mirror
"On the other hand Vista's audio system provides automatic calibration that detects the distance of a presumed head position from each of your speakers then adjusts when it delivers the audio signal to each speaker resulting in the audio reaching your head position simultaneously from all speakers."
That is a long way of saying: "Vista adds a configurable delay to output lines".
A separate scheduler class for time-critical processes is OK. Deliberately slowing down parts of system to make sure that your scheduler has lower latency is absolutely NOT OK.
Linus would have crucified anyone who proposed such a hack for the mainline Linux kernel.
I write drivers - it's kinda hard to test them on without a second computer. VMWare on my notebook works just fine with Windows XP - audio works perfectly with a pretty big safety margin of latency to spare. And Vista doesn't work well on the same hardware, despite its multimedia scheduler.
"Right. Zero latency. Talk about lies. It establishes callbacks in the apps, writing into shared memory segments which are then mixed and delivered to the standard linux audio device."
That's pretty much all I want from my audio system. Just give me a precise control over my audio stack and then you can build anything on top of it.
XP does exactly this - there's a fast, efficient, hardware-friendly kernel streaming layer.
Vista on the other hand forces you to use inferior-quality stack because MS couldn't figure out how to do protected audio path with kernel filters.
"Yeah. Zero latency as long as you stay ahead of the playback. Just like pretty much every sound system since the days of the original Soundblaster Pro using DMA."
DirectShow is famous for its imprecise timing control due to KMixer ;) My previous employer made a lot of $$$$$$ by making time-correcting kernel streaming filters.
"Where's the signal processing layer in there? Oh, it's third party. Where's the channel synchronization? Can't find it."
Everything is third-party. JACK only gives you a microsecond-precise information about audio system. You can do the rest yourself.
"And shockingly enough it's all software. Where's that hardware acceleration you're so fond of?"
It's possible to have hardware filters in JACK. The problem is that hardware filters are not that useful for professional-type audio systems. Look at OpenAL/EAX for hardware acceleration of spatial sound and other goodies.
BTW, OpenAL Creative Drivers even work on Vista by bypassing all its audio stack.
And.... SURPRISE! Windows Vista uses 32-bit floats as internal audio sample format ( http://blogs.msdn.com/larryosterman/archive/2007/04/03/volume-in-windows-vista-part-1-what-is-volume.aspx )!
"And what happens under load and the realtime scheduler can't quite keep up? Ah, I see, you get drop outs. What happens on Vista? Nothing, they hook into the scheduler to guarantee that their audio paths get time on the CPU."
Newsflash: if Vista scheduler can't quite keep up - you'll get sound drop-outs (I _do_ get them when I test my audio app on VMWare). There's no way around it. Realtime scheduler guarantees that your audio stack will get the highest priority, just like in Vista.
"It's not a matter of delaying individual streams. It's a matter of delaying individual channels from the same stream. So that your rear speakers sitting against the far wall behind you play just a bit earlier."
That doesn't matter. It's still not hard to do using kernel streaming.
I can distinctly remember that nice '3d-room' settings on my Creative Audigy 2 back in 2003. All in hardware.
I quite understand what Vista audio system does (down to the driver level). For one thing, it doesn't use hardware acceleration (!!!) anymore and does everything in software.
"It is by far the most advanced personal computer audio system available on any platform." - is a complete lie.
JACK (http://jackaudio.org/) is probably the best personal high-quality audio system (it has a zero-latency design). It's followed by PulseAudio which is now not quite yet zero-latency but much more efficient.
Adding some more latency into audiobuffers to adjust timing is a fairly trivial task. Also, a good implementation would just turn off this misfeature if the system uses only one sound sink.
Nope. CPUs nowdays use 'registers renaming' (http://en.wikipedia.org/wiki/Register_renaming) techniques, which give much larger effective register sizes.
And in any case, these data will be pre-fetched into L1 cache which is not shared between CPUs.
Atom CPUs use resurrected hyper-threading to cope with pipeline stalls and branch mispredictions. In the ideal world it should compensate for them almost as good as advanced out-of-order execution and branch prediction, but in the real world a lot of applications are single-threaded.
64-bits might help. Personally I'd better use a good architecture like MIPS with a lot of 32-bit registers ;)
What exactly discredits my words? Vista got so bad at audio performance that they had to hack around it by slowing down other parts of the system (by adding 'multimedia class scheduler'). It exactly mirrors my observations.
I had to add a workaround to my application because waveOutGetDevCaps function became about 100x slower on Vista than on XP so it became impossible to use it in a single thread with interactive audio.
Also, empirical observation: it became impossible to work with video on Vista in VMWare on my notebook. Even though it worked fine on XP.
As for gaming benchmarks: I don't care about them. There are too many different parameters affecting them.
Driver signing requirement is NOT for rootkit prevention.
It's here to make pro-DRM studios happy. Plain and simple.
You forget than 64-bit pointers also are twice as long as 32-bit.
And in practice extra x86-64 registers are not that great improvement because modern CPUs got very good at pipelining and data prefetching.
Vista _IS_ slower.
It can pull some tricks, but at the end of the day it IS slow.
For example, its audio stack is just HORRIBLE. Some functions work more than 100 _times_ slower than on XP ('protected' audio path and all that...).
Scheduler in Vista also performs worse than on XP (so MS had to resort to such hacks: http://blogs.technet.com/markrussinovich/archive/2007/08/27/1833290.aspx ).
Filesystem performance (which already is more than 10 _times_ slower than on Linux) in Vista is also hit because of overhead of transactional NTFS and more complex stack.
That's all objective and measurable.
Yes, there are certified secure hardware tokens available. They are optional, though.
There's also a centralized mechanism for key revocation.
So we need some way to rate CA quality...
Also, we can consider using money to fix this problem. For example, we can make all CAs put a big sum of money into an escrow account to be given to the first person who shows that CA doesn't perform 'due diligence' while issuing certificates.
It's better to use private companies with government oversight.
I now live in Ukraine and we have such a system. Government licenses private companies to work as certification centers and mandates that only certain (strong) crypto algorithms must be used.
As a result, I can use my private key to sign my tax report for IRS (or tax report for my company). IRS in turn uses its own key to sign their letters.
That's pretty cool, if you think about it.
Vista audio stack is crap. No, it's real CRAP.
It's slow (some functions work _1000x_ times slower than on WXP), it doesn't support acceleration, etc.
Transactional NTFS sounds like a good idea. But I have already encountered subtle race conditions with it. Now I'm not even certain that it's possible to create a fully transactional 'classic' filesystem.
I'm a Windows programmer (in fact, I write everything from drivers to high-end enterprise software).
There's not that much differences between W2k and WXP from programming viewpoint. Actually, from my experience I can only remember using improved monitoring interfaces in WXP which were not available in W2k.
I hope they learned their lessons from http://en.wikipedia.org/wiki/Therac-25 machines and installed hardware safety devices.
GM Volt? Chrysler also has announced it's going to produce plug-in hybrids 'real soon'.
Also, Eastern Orthodox Christians celebrate Christmas on January 7, because they still use old Julian calendar and not the new-fangled Gregorian Calendar.
They also can be disabled. Nobody's forcing you to use them.
Also, I _like_ the smoothness of console switching which KMS gives. It's way too cool.
No problem. Just add "nokms" parameter to the kernel command line and it'll start kernel without kernel mode-setting support, in a plain old console.
It's perfectly possible to teach yourself C++ programming in 21 days.
PS: it requires days to be polar days ( http://en.wikipedia.org/wiki/Polar_day ) though.
Iranian president has been elected by a popular vote.
But why? FreeBSD, Linux and even Windows (http://www.fs-driver.org/) have native ext2/3 drivers which are much faster and feature-complete than FUSE drivers can be. There's just no need for FUSE.
Also, it seems to be a good time to plug Dokan and my FUSE4Win project :)
There's a wonderful project named "Dokan" (http://dokan-dev.net/en/), it makes posssible to write user-space filesystem in Windows.
I've adapted FUSE interface for it, so it's possible to use (almost) unmodified FUSE filesystems in Windows: http://hg.sharesource.org/fuse4win
Currently, SSHFS works fine. NTFS3g also works :)
It's not as bad as GIMP :)