|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
60.227.59.154
In Reply to: I like nitpicking, it's my hobby :) posted by jbmcb on August 25, 2006 at 10:59:06:
*** Yep, but as far as the end user is concerned, it's a file with some routines that apps use. ***No, not really, hence the widespread misunderstanding. DLLs in Windows are *not* just a passive collection of shared routines, unlike a Unix .so library. DLLs in Windows can also behave similarly to "kernel modules" in Linux, and service interrupts or run a polling loop.
*** However, in my experience, if something breaks in windows it breaks *hard*. ***
Not my experience at all.
*** Right, however if there's a sample rate issue you're going to hear it right away, usually it plays back REALLY slow. ***
Not really, because Windows and/or the device driver resamples. Problem is, sometimes you can't control when resample happens. In theory, AC97 always resamples everything to 48kHz, but many prosumer audio cards have a WDM driver implementation that allows the default sample rate to change (ie., intentionally breaking AC97).
Imagine the following situation - a driver that allows the base output sample rate to change, and resamples all open connections to this rate (usually the rate is determined by the first open connection). Ie. if an application opens the driver in 44.1kHz, the driver will set the sound card to 44.1. Then if another application also simultaneously opens a connection at a different sample rate (say 48kHz), the driver will now silently resample this second connection to 44.1kHz as the first application is still open.
Now if during startup an app or DLL plays a Windows system sound (usually at 22.05kHz) but for some reason keeps the connection open. Then you open your sound playback application and play a CD at 44.1kHz. The driver will resample your CD to 22.05kHz!!! This has actually happened to me a few times with a particular sound card, and it took a while to isolate how this behaviour came about.
This is an example of behaviour that will cause degradation in sound quality, but the degradation may not be immediately obvious, and it's *not* a hard failure, but everything working as designed.
*** I'm not sure where "spurious junk" will come from, either there's audio data being played or there isn't. ***
I'm getting the feeling that you do not have a lot of experience, because your statements show some naivity.
Again, consider the situation where a background task (again, this is a real example) periodically opens and closes an audio connection - possibly because it is polling something, and playing an alert tone depending on a condition, but even if there's no alert, it opens and closes the audio device anyway but sends a blank audio file (poor programming practice, but hey there's some stupid people out there).
This will cause "spurious junk" to be overlayed onto the audio being played back, depending on how the application opens and closes the audio device, and the device driver. And don't forget many applications like to keep the sound device open permanently, hence making driver resampling very likely.
Typically, in real life, this "junk" usually comes about from Windows system sounds, which is why it's a really good idea when building a digital audio workstation (and I have built several) to have a different device (ie. the motherboard audio device) act as the default multimedia device, and have a second dedicated audio device (that Windows doesn't see or touch) for music.
*** I find that's usually a hardware compatability issue, coupled with lousy drivers. ***
Maybe, maybe not. And the problem may not may not obvious, despite what you think. For example, increased jitter due to PCI bus contention may not immediately translate to stuttering or gaps in the sound, but it will cause a degradation to the sound.
*** My contention isn't that unrelated software cannot affect the audio, but that such an issue would be patently obvious. ***
In my experience, your contention is not true. I have already described several examples where the issues are not patently obvious. For example, not many people can immediately tell when 44.1 is being resampled to 48 and vice versa. But it *will* result in degradation of sound.
*** My background is in high speed data aquisition and playback ***
And *my* background is designing and building large complex systems where the interactions between different components are so complex they appear to be non deterministic and sometimes downright illogical. I have also written a thesis on computer music, and built a very early computer music real time performance system. I have also participated in distributed operating system research in the 80s, as well as early work on digital room correction. I have also written several device drivers. Of course, most of these feats happened very early in my career, these days I manage a team of people who manage the designers who then manage the developers, but it's always good to have a strong technical background, especially since I'm ultimately accountable for the overall architecture of the organisation.
Follow Ups:
> No, not really, hence the widespread misunderstanding. DLLs in Windows are *not* just a passive collection of shared routines, unlike a Unix .so library. DLLs in Windows can also behave similarly to "kernel modules" in Linux, and service interrupts or run a polling loop.Right, but they don't just load themselves into memory to service an interrupt, they are called to monitor an interrupt by an application or system service via ntdll.dll, or whatever they are calling it these days. Keep in mind I'm referring to those who claim exiting out of mcafee or zonealarm improves the sound of their media player, and looking at Process Explorer I don't see either one of those loading winmm.dll. Could they be trapping some other system call and degrade timing precision in some real-time process? Possibly, but I haven't seen it affecting an 8Mbps RS422 link running for two weeks straight.
> I'm getting the feeling that you do not have a lot of experience, because your statements show some naivity.
Well now that's a bit presumptuous.
> Again, consider the situation where a background task (again, this is > a real example) periodically opens and closes an audio connection - > possibly because it is polling something, and playing an alert tone > depending on a condition, but even if there's no alert, it opens and > closes the audio device anyway but sends a blank audio file (poor > programming practice, but hey there's some stupid people out there).
How often do you see this? I've done loads of long-term testing playing audio files with kernel streaming, with bit-perfect results (comparing lossless file decompressors into a virtual soundcard) WDM will mess with your output, though I haven't seen any conclusive evidence that it's readily audiable.
> Maybe, maybe not. And the problem may not may not obvious, despite what you think. For example, increased jitter due to PCI bus contention may not immediately translate to stuttering or gaps in the sound, but it will cause a degradation to the sound.
C'mon, if the PCI bus is so laggy that it's draining the buffer of your sound card (probably the slowest device on the bus), you'll be noticing some effects other than degraded sound. Probably crashing, as PIO requests from other devices on the southbridge queue up and pound the memory controller.
> In my experience, your contention is not true. I have already described several examples where the issues are not patently obvious. For example, not many people can immediately tell when 44.1 is being resampled to 48 and vice versa. But it *will* result in degradation of sound.
44.1KHz being resampled to 48KHz WILL result in a degradation of sound? That's an interesting contention.
> And *my* background is designing and building large complex systems where the interactions between different components are so complex they appear to be non deterministic and sometimes downright illogical.
Ever deal with enterprise java programming? :)
> I have also written several device drivers.
Yep, I miss DOS, too.
/*Music is subjective. Sound is not.*/
*** Well now that's a bit presumptuous. ***Hey, if you quack like a duck ...
*** How often do you see this? ***
At least once. Remember, in order to disprove your "contention", all I need is *one* counterexample. Which I have provided.
*** I've done loads of long-term testing playing audio files with kernel streaming, with bit-perfect results (comparing lossless file decompressors into a virtual soundcard) WDM will mess with your output, though I haven't seen any conclusive evidence that it's readily audiable. ***
You do realise, don't you, that kernel streaming is *part* of WDM, so your statements are contradictory (I think i know what you are trying to say, though)
*** C'mon, if the PCI bus is so laggy that it's draining the buffer of your sound card (probably the slowest device on the bus), you'll be noticing some effects other than degraded sound. Probably crashing, as PIO requests from other devices on the southbridge queue up and pound the memory controller. ***
Well, what can I say? Your analysis is way too simplistic. Hint: measure the jitter output from your soundcard (using a variant of Julian Dunn's J-test). Measure it whilst the CPU is relatively idle, vs heavily utilized. Do you see a difference? Have any bits been lost in either case? What do you think accounts for the difference?
*** 44.1KHz being resampled to 48KHz WILL result in a degradation of sound? That's an interesting contention. ***
Try doing this. Take any source material in 44.1kHz, resample to 48kHz (using your favourite resampling algorithm). Then resample back to 44.1.
If the process was truly lossless (ie. no degradation in sound), you should get back exactly what you started with - bit for bit (or at least, close enough, accounting for quantization error).
Do you? Hint - have a look at behaviour for frequencies close to Nyquist.
The whole notion that resampling is somehow "transparent" or "lossless" is one of the great myths of digital audio.
*** Ever deal with enterprise java programming? :) ***
Not me, personally, as I've said a lot of my hands on stuff is well over twenty years ago. However, my team was responsible for doing some interesting stuff on services oriented architecture which i have presented in several conferences around the world (we do have a patent for the specific application though).
You do realise of course that "enterprise java programming" is an oxymoron? :-)
*** Yep, I miss DOS, too. ***
> Hey, if you quack like a duck ...Um, OK...
> You do realise, don't you, that kernel streaming is *part* of WDM
Of course. So what? waveOut resamples, kernel streaming doesn't. Same driver model, two different interfaces. Tack on DirectSound and the windows media player interfaces on top of that. Kernel streaming is the least damaging of all of them, and what I'm assuming most people using foobar2000 are using (that or ASIO.) So how is another process degrading the sound by (attempting) to open the audio device?
> Measure it whilst the CPU is relatively idle, vs heavily utilized. Do you see a difference? Have any bits been lost in either case?
Those tests are low on my list of priorities, but I'll run them when I get a chance. I've yet to hear the effects of jitter, however.
> Try doing this. Take any source material in 44.1kHz, resample to 48kHz (using your favourite resampling algorithm). Then resample back to 44.1.
Well now, that wasn't what you said in your previous post.
Of course upsampling mangles the original data, and up/down sampling is even worse. However, many on this board will contend that it sounds better when done properly. I could care less, 44.1KHz sounds fine to me.
> You do realise of course that "enterprise java programming" is an oxymoron? :-)
It is when poorly implemented, same as any other "enterprisey" language.
> Actually, no - don't confuse your background with mine. :-)
Actually I'm more accustomed to low level '64 programming. The SID was a thing of beauty...
/*Music is subjective. Sound is not.*/
*** So how is another process degrading the sound by (attempting) to open the audio device? ***I think I already gave you several examples, which I won't bother repeating.
*** Those tests are low on my list of priorities, but I'll run them when I get a chance. I've yet to hear the effects of jitter, however. ***
Hence my comment about your lack of experience. If you *had* run those tests, you would not made some of your comments ...
*** Well now, that wasn't what you said in your previous post. ***
Actually, it was. For reference, let me requote, word for word: "For example, not many people can immediately tell when 44.1 is being resampled to 48 and vice versa. But it *will* result in degradation of sound."
Of course, you can argue whether the degradation is audible or not. I suspect your ears are not well trained, so it may well be that you won't hear the artefacts.
If you are familiar with the sort of artefacts generated by resampling, you can train your ears to spot them, just like you can train yourself to distinguish different dithering algorithms. Search the web, there's at least one site offering "blind" comparisons.
*** However, many on this board will contend that it sounds better when done properly. ***
I'm not one of them.
*** It is when poorly implemented, same as any other "enterprisey" language. ***
Ahh, you completely missed my point! Never mind ...
This post is made possible by the generous support of people like you and our sponsors: