Hi phofman.
The issues we have with standard players is a well known fact.
That's "one" of the reasons why I use ecasound or brutefir.
Audacious is AFAIK the only standard player which allows to turn off all
DSP functions. Even Amarok samples to 48k by default.
The other audible differences are related to the OS setup.
The other day I stepped over a nice article from the SuperComputer area.
They have introduced a term called OS-Jitter causing
latencies and non-linearities. This OS-Jitter will heavily impact processing
performance.
I see there quite some similarities to what I am writing about since quite some time.
I just read that some of the SuperComputer guys are thinking about introducing
a RT-kernel. They already developed a stripped down Linux-OS for their purposes.
I guess the PC audio freaks are well ahead of these guys. 😉
The issues we have with standard players is a well known fact.
That's "one" of the reasons why I use ecasound or brutefir.
Audacious is AFAIK the only standard player which allows to turn off all
DSP functions. Even Amarok samples to 48k by default.
The other audible differences are related to the OS setup.
The other day I stepped over a nice article from the SuperComputer area.
They have introduced a term called OS-Jitter causing
latencies and non-linearities. This OS-Jitter will heavily impact processing
performance.
I see there quite some similarities to what I am writing about since quite some time.
I just read that some of the SuperComputer guys are thinking about introducing
a RT-kernel. They already developed a stripped down Linux-OS for their purposes.
I guess the PC audio freaks are well ahead of these guys. 😉
Audio jitter and applications jitter are unrelated if enough buffers between the application and the part clocked by the audio clock are provided to avoid xruns.
phofman said:
Never ending discussion. 😉
However, there is hope. Since you realized after a couple of years of discussion that applications do cause this or that impact on sound ( which were not possible according to your "theoretical approaches under perfect conditions"), I'd guess it'll take another 3 years that you realize that the OS has a certain impact on audio.
I guess one day it'll dawn on you that there is another world than your "theoretical" world out there and that there are indirect relations causing the trouble. ( I can prove the impact - though
I can not scientifically explain it)
I think it is obvious that OS-Jitter is not "directly" affecting the PCM related jitter in front of the DAC.
I remember to have read somewhere in the deep web about Meridian using several buffer stages. Why several?
In my opinion buffers can decouple from e.g. OS jitter. But only in the case when the buffers have separate data and adress busses. If computer and soundcard share the same busses by applying some tristate logic then the access to the buffers is dependent on access rights (DMA or whatever).
This would be my explanation for cases where buffers do not prevent from OS jitter.
And maybe that's the reason for the Meridian buffer stages.
But beside this there also may be some other effects in the game like the power supply behaviour at different computer activity or EMC distortions.
In my opinion buffers can decouple from e.g. OS jitter. But only in the case when the buffers have separate data and adress busses. If computer and soundcard share the same busses by applying some tristate logic then the access to the buffers is dependent on access rights (DMA or whatever).
This would be my explanation for cases where buffers do not prevent from OS jitter.
And maybe that's the reason for the Meridian buffer stages.
But beside this there also may be some other effects in the game like the power supply behaviour at different computer activity or EMC distortions.
Hi Uli.
I think phofman mentioned some time ago that only the "last buffer" in the PC should be looked at. That only this one will impact directly thestream. This makes pretty much sense and has never been questioned.
As you mention this final buffer-management and performance might be impacted by system anomalies (e.g. timer drifts, you name it). As long as the last buffer is not slaved to the device further downstream you'll have a problem I guess.
We shouldn't forget the physical implications caused by the OS-Jitter sources.
That's what I call indirect impact. Processor and other peripherals varying load
conditions, will impact e.g. the power conditions. HW timers, etc. won't run stable.
We shouldn't forget automated load balancing, power control, dynamic bandwidth allocations
all this might impact the "linearity" at a certain relevant point in the system,.
An interesting learning from my side is that if you stream to an external audio streaming
device (with own processor) you usually decouple from your main PC automatically.
You move your "last point of control" to somewhere else, and you won't face any indirect impacts.
That could be the reason why FGPA based soundcards inside the PC are much
less of a problem, then e.g. my USB-sound-card. These kind of PCI cards might suffer from
power/EMI/RFI problems only.
I think phofman mentioned some time ago that only the "last buffer" in the PC should be looked at. That only this one will impact directly thestream. This makes pretty much sense and has never been questioned.
As you mention this final buffer-management and performance might be impacted by system anomalies (e.g. timer drifts, you name it). As long as the last buffer is not slaved to the device further downstream you'll have a problem I guess.
We shouldn't forget the physical implications caused by the OS-Jitter sources.
That's what I call indirect impact. Processor and other peripherals varying load
conditions, will impact e.g. the power conditions. HW timers, etc. won't run stable.
We shouldn't forget automated load balancing, power control, dynamic bandwidth allocations
all this might impact the "linearity" at a certain relevant point in the system,.
An interesting learning from my side is that if you stream to an external audio streaming
device (with own processor) you usually decouple from your main PC automatically.
You move your "last point of control" to somewhere else, and you won't face any indirect impacts.
That could be the reason why FGPA based soundcards inside the PC are much
less of a problem, then e.g. my USB-sound-card. These kind of PCI cards might suffer from
power/EMI/RFI problems only.
soundcheck said:
What? You have intentionally avoided the "bit-perfection" condition I always emphasize. This kind of arguing is called demagogy, isn't it? Why should I ever say a player with crappy upsampling must sound the same as another one with quality filters? But any bit-perfect player with properly coded alsa support (not trivial, true) will perform the same. It is possible some GUI-intensive player may put more strain on the PSU, indirectly affecting the sound card clock and analog circuits. But just the same load increase is a result of the RT kernel and low-latency setup so loudly supported here.
Of course playback of 44.1kHz material on 48kHz-only USB soundcard will never be bit-perfect and the quality of upsampling plays a major role.
What linearity are you talking about? Is it just you like the word, or do you have anything specific in mind?
Sound is only data, timing, quality of the HW and level of noise. If the chain is bit-perfect and fast enough, the data are OK. The timing is independent of SW and only a function of clock quality and noise. All the functions mentioned by you can affect the noise. I doubt many people have the knowledge and technical equipment to correlate noise vs. SW on a general basis (i.e. works for me, thus will work for you), especially on a general purpose OS (linux, or even black-box windows). There are certainly easy logical wins (e.g. shutting down hard drives), but the kind of consistent quality control authors of some windows players offer while still stating a whole-chain bit-perfection is beyond my understanding. The truth is they almost never provide source code or even try to explain in technical terms the principles or their "tweaks".
Coming from a windows point of view and using multitrack software to abuse my computers on a regular basis I might be able to offer a little bit of insight into the variables OSes and hardware can throw at your audio. This of course is a much more processor and ram intensive task because what I do is take an upward of 20 individual wav files and sum them down into 2 tracks while running various VST plugins on the fly.
By far what effects the performance of audio on a computer the most is the user's ability to fine tune/reconfigure that computers hardware and OS to perform it's best for audio and not word processing or security. This is a lengthly topic and I do not have the time to get into every aspect of fine tuning an OS - because there are so many problems due to most OSes being optimized by default for networking, security for networking, and word processing. For instance a common mistake is to set your processor priority for programs instead of background services. ASIO is a background service and this can impact it's performance.
One tool I have found to be great for testing a system and how it will deal with audio/video on *windows* is DPC latency checker. I assume that every OS has an equivalent to DPC latency but might call it something different. This is basically the latency your OS encounters when trying to figure out how to prioritize tasks. It can jump up and interfere with the simplest of audio tasks - play a hi res flac for instance.
There are other things that can go wrong without any indication. Programs that utilize ram are prone to this imo. Combine a program that pulls info from ram with a poorly setup computer which ram has generic timings and you could be pulling "silent errors" from the ram.
By far what effects the performance of audio on a computer the most is the user's ability to fine tune/reconfigure that computers hardware and OS to perform it's best for audio and not word processing or security. This is a lengthly topic and I do not have the time to get into every aspect of fine tuning an OS - because there are so many problems due to most OSes being optimized by default for networking, security for networking, and word processing. For instance a common mistake is to set your processor priority for programs instead of background services. ASIO is a background service and this can impact it's performance.
One tool I have found to be great for testing a system and how it will deal with audio/video on *windows* is DPC latency checker. I assume that every OS has an equivalent to DPC latency but might call it something different. This is basically the latency your OS encounters when trying to figure out how to prioritize tasks. It can jump up and interfere with the simplest of audio tasks - play a hi res flac for instance.
There are other things that can go wrong without any indication. Programs that utilize ram are prone to this imo. Combine a program that pulls info from ram with a poorly setup computer which ram has generic timings and you could be pulling "silent errors" from the ram.
Hi Key.
Just to let you know, I am ( and I guess some others around here) following
CICS (Audio Asylum) approach. I started a similar approach 3 years ago -
under Linux.
For sure CICS pushed the Windows performance to the limits. I referred
to his stuff several times.
The question over here is not really how to optimize the OS. It is rather the
question, if it makes sense.
I think there is no dispute about PC-HW related or better physical impact on sound quality
over here. (Hmmh - No, No I am not really sure here: If you read the CICS related threads,
you will learn that different RAM sounds different, a lot of other stuff will impact
the sound according to the CICS instructions and community. phofman will like that one I guess 😉 )
Anyhow. phofman standpoint is: There is a final buffer right in front of the soundcard.
It doesn't matter what happens before (upstream). It doesn't matter how jittery the stream will be at this point in time. At this final buffer everything is set back to zero. Yep I agree,
that's probably the only valid assumption. (Though, if you read Uli's latest remar about "multistage buffer decoupling" I am not really sure if we miss something here)
The questions that are not answered: What buffer are we talking about? How much is this buffer performance affected by OS system variables, causing this are that amount of jitter.
phofman claims: There is no impact! Quite some others claim: There is impact - we can clearly hear it.
Another important issue to mention: Different soundcards show different behavior. Some
of them are more affected some others less. This of course will depend heavily on their
buffer managment, how much there are able to decouple from the PC datastream anomalies.
Just to let you know, I am ( and I guess some others around here) following
CICS (Audio Asylum) approach. I started a similar approach 3 years ago -
under Linux.
For sure CICS pushed the Windows performance to the limits. I referred
to his stuff several times.
The question over here is not really how to optimize the OS. It is rather the
question, if it makes sense.
I think there is no dispute about PC-HW related or better physical impact on sound quality
over here. (Hmmh - No, No I am not really sure here: If you read the CICS related threads,
you will learn that different RAM sounds different, a lot of other stuff will impact
the sound according to the CICS instructions and community. phofman will like that one I guess 😉 )
Anyhow. phofman standpoint is: There is a final buffer right in front of the soundcard.
It doesn't matter what happens before (upstream). It doesn't matter how jittery the stream will be at this point in time. At this final buffer everything is set back to zero. Yep I agree,
that's probably the only valid assumption. (Though, if you read Uli's latest remar about "multistage buffer decoupling" I am not really sure if we miss something here)
The questions that are not answered: What buffer are we talking about? How much is this buffer performance affected by OS system variables, causing this are that amount of jitter.
phofman claims: There is no impact! Quite some others claim: There is impact - we can clearly hear it.
Another important issue to mention: Different soundcards show different behavior. Some
of them are more affected some others less. This of course will depend heavily on their
buffer managment, how much there are able to decouple from the PC datastream anomalies.
Well the thing with ram to me is that rarely does anyone test there ram for silent errors.
And even with all that said I will say that in my experience most digital problems are on and off situations. Either it's broken - lots of clearly noticable jitter and buffer errors - or it's not. Just my personal experience. Beyond that once in a while I think I might have a clock that sways - especially if it hasn't warmed up the songs sound too fast or slow. But this might be in my head.
And even with all that said I will say that in my experience most digital problems are on and off situations. Either it's broken - lots of clearly noticable jitter and buffer errors - or it's not. Just my personal experience. Beyond that once in a while I think I might have a clock that sways - especially if it hasn't warmed up the songs sound too fast or slow. But this might be in my head.
soundcheck said:
This may be the point me (and phofman?) are missing. You use a usb sound card.... for all your talk of 'people who dont have the high resolution system I have cant hear it' you use a usb soundcard? Correct me if I am wrong, but the clock of the usb bus will not be properly decoupled (from dac etc) in any consumer usb sound device, akin to a jittery SPDIF stream no? Maybe this is why you are so sensitive to variations in load etc?
I have read and looked into building an external dac, always finding dead ends when the interface must be usb... there are no usb receiver chips around that can extract the I2S data with proper reclocking rather than using the clock of the usb bus....
Re: USB audio
Hi there.
I am pretty careful taking statements on computer-audiophile for granted.
They talk about "thousands of hours" implementing asynchronous USB mode. G.Rankin said that he did it in 800h. He is licensing his stuff to rest of the world (e.g. Ayre).
The TAS1020 you'll find in the M-Audio Transit (asynch mode up2 48khz), EMU 0404USB and many more pro-audio interfaces. They all do 24/96 and are affordable for the masses.
Cakewalk UA-101 is also doing asynch USB.
Don't believe that the Wavelength or Centrance firmware completly resolves the OS-Latency jitter (or however you call it) issue. You'll also experience this or that change
on sound quality if you tweak the OS.
I had a Benchmark at home. They even claim that the DAC1 is immune against incoming jitter. Hmmh, what can I say. If the product sheet says so. 😉
Even Gordon Rankin mentioned at AA that he can not explain the issue. His guess: "no-jitter probably timing issues" . I asked: "So what's the definition of jitter ?" 😉 No answer.
If you look at AA, there are numerous examples of other (pci-)cards then PCM270x based USB-cards where CICS player or XX-HE greatly enhanced the playback quality.
Hopefully one day somebody is able to show what's going on.
.: ZMN :. said:
Hi there.
I am pretty careful taking statements on computer-audiophile for granted.
They talk about "thousands of hours" implementing asynchronous USB mode. G.Rankin said that he did it in 800h. He is licensing his stuff to rest of the world (e.g. Ayre).
The TAS1020 you'll find in the M-Audio Transit (asynch mode up2 48khz), EMU 0404USB and many more pro-audio interfaces. They all do 24/96 and are affordable for the masses.
Cakewalk UA-101 is also doing asynch USB.
Don't believe that the Wavelength or Centrance firmware completly resolves the OS-Latency jitter (or however you call it) issue. You'll also experience this or that change
on sound quality if you tweak the OS.
I had a Benchmark at home. They even claim that the DAC1 is immune against incoming jitter. Hmmh, what can I say. If the product sheet says so. 😉
Even Gordon Rankin mentioned at AA that he can not explain the issue. His guess: "no-jitter probably timing issues" . I asked: "So what's the definition of jitter ?" 😉 No answer.
If you look at AA, there are numerous examples of other (pci-)cards then PCM270x based USB-cards where CICS player or XX-HE greatly enhanced the playback quality.
Hopefully one day somebody is able to show what's going on.
The message should have been more precise in its wording: 24/96 available for the masses ... on Linux. 🙂
Thanks for sharing your insights on the topic. I am sure I did not do my homework as well as the majority of this threads posters, but until now I have not found the proof for linux support for anything above 48k on devices using that chip. Do you think 24/96 is available for the TAS1020 or any of the devices based on it on linux?
I must admit that the more I read about USB audio implementations to get to 24/96 to work well (opinions mostly, facts sometimes) the more I get the feeling that getting it working properly will depend on a lucky/astrological/occult alignment of hardware, OS, drivers, apps, versions of apps and very talented individuals with the programming know-how to mix them together.
Thanks for sharing your insights on the topic. I am sure I did not do my homework as well as the majority of this threads posters, but until now I have not found the proof for linux support for anything above 48k on devices using that chip. Do you think 24/96 is available for the TAS1020 or any of the devices based on it on linux?
I must admit that the more I read about USB audio implementations to get to 24/96 to work well (opinions mostly, facts sometimes) the more I get the feeling that getting it working properly will depend on a lucky/astrological/occult alignment of hardware, OS, drivers, apps, versions of apps and very talented individuals with the programming know-how to mix them together.
Actually, that reminds me to add some praise to mpd+pipe+ecasound solution as suggested by soundcheck in his wiki. That is a very nice 'alignemnt'. It is the best sounding solution I used so far on my Ubuntu based system.
just for info: I use a setup with two outputs (therefore two pipes in the mpd config). The only disadvantages I noticed are a slight lag between the two outputs, a slight lag in operations in mpd and instances of broken pipes which make me have to press 'play' a few times to get output.
just for info: I use a setup with two outputs (therefore two pipes in the mpd config). The only disadvantages I noticed are a slight lag between the two outputs, a slight lag in operations in mpd and instances of broken pipes which make me have to press 'play' a few times to get output.
.: ZMN :. said:
1. Are you running Ubuntu Studio and/or rt-kernel? If not -- try it.
2. Checkout the ram playback tweak
3. Regarding 24/96.
Below the output of /proc/asound/card0/stream0 towards my M-Audio Transit while running 24/96 to a TAS1020. Any more questions?
----------
M-Audio Transit USB at usb-0000:00:1d.2-1.3, full speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 1
URBs = 8 [ 1 1 1 1 1 1 1 1 ]
Packet Size = 576
Momentary freq = 96000 Hz (0x60.0000)
Interface 1
Altset 1
Format: 0x20 (24 bits)
Channels: 2
Endpoint: 3 OUT (ADAPTIVE)
Rates: 48001 - 96000 (continuous)
Interface 1
Altset 2
Format: 0x20 (24 bits)
Channels: 2
Endpoint: 3 OUT (NONE)
Rates: 8000 - 48000 (continuous)
Interface 1
Altset 3
Format: 0x2 (16 bits)
Channels: 2
Endpoint: 3 OUT (ASYNC)
Rates: 8000 - 48000 (continuous)
-----------
4. Below shows my M-Audio Transit running 16/44.1. Checkout the the terms ASYNC and ADAPTIVE.
--------------
M-Audio Transit USB at usb-0000:00:1d.2-1.3, full speed : USB Audio
Playback:
Status: Running
Interface = 1
Altset = 3
URBs = 8 [ 1 1 1 1 1 1 1 1 ]
Packet Size = 196
Momentary freq = 44100 Hz (0x2c.199a)
Interface 1
Altset 1
Format: 0x20 (24 bits)
Channels: 2
Endpoint: 3 OUT (ADAPTIVE)
Rates: 48001 - 96000 (continuous)
Interface 1
Altset 2
Format: 0x20 (24 bits)
Channels: 2
Endpoint: 3 OUT (NONE)
Rates: 8000 - 48000 (continuous)
Interface 1
Altset 3
Format: 0x2 (16 bits)
Channels: 2
Endpoint: 3 OUT (ASYNC)
Rates: 8000 - 48000 (continuous)
----------------
Note: There are different type of implementations of ASYNC USB mode.
It seems that there is a kind of stream and a bulk transfer mode.
I have no clue how to find out which one is used.
Key,
If I understand correctly, the goal of your tuning is having a stable playback of 20 channels with some VST magic while keeping minimum latency, probably for recording, composing, or mastering work. That is no doubt a difficult task and every subtle tweak in HW/SW can make a big difference.
However, the usage scenario here is very different - just playback. The overall latency apparently does not matter at all (e.g. playback from RAM, requiring reading the whole track from drive first - seconds of latency). Still, some people claim here that keeping the system at lowest latency changes the sound (clear highs, wider soundstage, strong lows).
BTW, what do you mean by "silent errors"? I tried to consult google and found only an article discussing the rate of silent errors in FB DIMM of less than one in 100 yrs http://www.theinquirer.net/inquirer/news/1040218/the-beauty-of-intels-fb-dimm-architecture . If that is the case then silent errors could easily cause a system crash. I do not think that is something normally occuring in our PCs since our machines generally do not crash. But I may have got it wrong.
If I understand correctly, the goal of your tuning is having a stable playback of 20 channels with some VST magic while keeping minimum latency, probably for recording, composing, or mastering work. That is no doubt a difficult task and every subtle tweak in HW/SW can make a big difference.
However, the usage scenario here is very different - just playback. The overall latency apparently does not matter at all (e.g. playback from RAM, requiring reading the whole track from drive first - seconds of latency). Still, some people claim here that keeping the system at lowest latency changes the sound (clear highs, wider soundstage, strong lows).
BTW, what do you mean by "silent errors"? I tried to consult google and found only an article discussing the rate of silent errors in FB DIMM of less than one in 100 yrs http://www.theinquirer.net/inquirer/news/1040218/the-beauty-of-intels-fb-dimm-architecture . If that is the case then silent errors could easily cause a system crash. I do not think that is something normally occuring in our PCs since our machines generally do not crash. But I may have got it wrong.
soundcheck said:
The last buffer details have been discussed here several times.
PCI: The "reclocking" buffer is implemented in the PCI sound controller. For buffer details see e.g. page 46 of Envy24HT datasheet http://ftp.iasi.roedu.net/mirrors/ftp.alsa-project.org/manuals/icensemble/Envy24HT091DS.pdf .
USB: The buffer is the central part of the USB controller. Each "slot" contains data for 1ms and its reading is timed by a HW clock. For initial details see http://www.diyaudio.com/forums/showthread.php?postid=1690264#post1690264 , no need to repeat again.
Exact length of the slot is controlled by the Start of Frame Modify Register (see chapter 2.1.6 in http://download.intel.com/technology/usb/UHCI11D.pdf ). The default value of 64 means the divider from 12MHz is 11.936 + 64 = 12.000. Linux kernel keeps the default value, i.e. exactly 1ms - see http://lxr.linux.no/linux+v2.6.27.10/drivers/usb/host/uhci-hcd.c#L180
The only variable in this concept is number of audio frames in each "slot" (called packet in usb-audio.c. I was still wondering if the driver writes the same number of audio frames to each packet, keeping thus the flow constant and relieving the PLL in adaptive-mode USB sound cards.
I put a few extra information into the usb-audio proc output. It lists a number of bytes/audio frames of all scheduled packets (i.e. each 1ms transfer) at any moment, plus records any potential differences in the frames count. As expectable, the count was always 192 bytes, i.e. 48 frames each 1 ms. The count is independent of any load (unless undeliveries-xruns occur but these are reported by alsa-lib). It has to be constant since its calculation is very simple for the adaptive mode http://lxr.linux.no/linux+v2.6.27.10/sound/usb/usbaudio.c#L511 .
Actually, the number of audio frames is where adaptive USB and asynchronous USB differ. In adaptive USB the number is constant (48 frames for 16/48, i.e. any regular USB sound card). In asynchronous the card basically keeps telling the driver back how many samples should come in the next packets to keep its internal reclocking buffer optimally filled. The USB Audio standard defines the exact meaning of the returned number, but some cards (e.g. E-MU 2020 USB) relate the number to a different time frame. That is why they need special drivers (and simple "hacks" in alsa). I guess these are in fact the mentioned difference between the various asynchronous modes.
All of the above holds for linux and anyone can read that from the source code and corresponding datasheets. I have no idea how windows work (but probably very similarly).
Well there are different types of latencies. I am guessing you are thinking of ASIO buffer which in cases of real time processing or software synths is an issue. This is not what I was referring to. I am talking about the underline latency on an OS. On windows this is called Deferred Procedure Call. And seemingly faster OSes like Vista 64 running 8gigs of ram can actually be less stable for streaming audio and video than XP with 4gigs of ram running the same hardware.
Now with ram what I mean about silent errors are errors that your ram could be causing because of it's timing being incorrect or slightly unstable. This can happen on a level where it goes entirely unnoticed by the host OS, and Software. The only way I know to be sure is by running long tests on your ram with something like memtest. This is something that people only normally do when overclocking to double and triple check for errors - which in a lot of processing intensive applications like gaming for instance can actually be negligible. I would not consider it negligible in the recording and playback of music - at least in my case of using a PC for production.
Now with ram what I mean about silent errors are errors that your ram could be causing because of it's timing being incorrect or slightly unstable. This can happen on a level where it goes entirely unnoticed by the host OS, and Software. The only way I know to be sure is by running long tests on your ram with something like memtest. This is something that people only normally do when overclocking to double and triple check for errors - which in a lot of processing intensive applications like gaming for instance can actually be negligible. I would not consider it negligible in the recording and playback of music - at least in my case of using a PC for production.
I fully agree with you that setting up a PC (both windows and linux) for professional audio production is pretty complicated. The description you used is "less stable for streaming ..." and that is the point. Low latency is absolutely critical for audio production and it is difficult to keep it stable. A random latency spike (i.e. latency jitter) will ruin the recording session.
But the discussion here is about playing back pure audio (no video, no lips delay issues) from various sources, where latency is absolutely unimportant. It does not matter if I hear the sound a second after pushing the button (and in case of RAM playback the overall latency is much longer). The discussion here is about quality (not stability) of the sound. My argument is that lower latency itself cannot produce any change in the quality of the sound apart from the clearly hearable dropouts - instability in your terms.
I can imagine a lower latency (i.e. higher CPU load) will change spectrum of power supply noise - but results will not be consistent across various CPUs, motherboards and PSUs enough to say "do this and it will sound better".
Those white errors - they can be undetected by the OS until they corrupt a memory variable of the OS kernel, leading most likely to system lockup/crash/BSOD. Developing linux drivers trained me in pushing the reset button 🙂 True, the kernel occupies only lower parts of memory, but the errors would still result in application crashes.
I have had numerous PCs/DIMMs which kept crashing OS/applications. They were ecologically recycled ( 🙂 ) right away. But our production machines do not experience anything like that, e.g. our servers run many months without rebooting or a single random application crash.
But the discussion here is about playing back pure audio (no video, no lips delay issues) from various sources, where latency is absolutely unimportant. It does not matter if I hear the sound a second after pushing the button (and in case of RAM playback the overall latency is much longer). The discussion here is about quality (not stability) of the sound. My argument is that lower latency itself cannot produce any change in the quality of the sound apart from the clearly hearable dropouts - instability in your terms.
I can imagine a lower latency (i.e. higher CPU load) will change spectrum of power supply noise - but results will not be consistent across various CPUs, motherboards and PSUs enough to say "do this and it will sound better".
Those white errors - they can be undetected by the OS until they corrupt a memory variable of the OS kernel, leading most likely to system lockup/crash/BSOD. Developing linux drivers trained me in pushing the reset button 🙂 True, the kernel occupies only lower parts of memory, but the errors would still result in application crashes.
I have had numerous PCs/DIMMs which kept crashing OS/applications. They were ecologically recycled ( 🙂 ) right away. But our production machines do not experience anything like that, e.g. our servers run many months without rebooting or a single random application crash.
- Status
- Not open for further replies.