Home Computer Audio Asylum

Music servers and other computer based digital audio technologies.

Well, here's some more :-)

*** 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.


This post is made possible by the generous support of people like you and our sponsors:
  Atma-Sphere Music Systems, Inc.  


Follow Ups Full Thread
Follow Ups
  • Well, here's some more :-) - Christine Tham 16:36:57 08/25/06 (4)


You can not post to an archived thread.