|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
65.19.76.104
In Reply to: RE: Snap Crackle and Pop posted by Bob_C on April 10, 2014 at 22:53:08
Snap crackle and pop were the rule with an ancient laptop that I bought in 2011. This machine has been demoted to serving as a remote control for a Chromcast. The machine that replaced it and the machine that replaced that one were free from snap crackle and pop once a little tuning was done, mostly ensuring that system maintenance functions did not occur while listening to music.
Nothing to obsess about. There is grossly excessive computational horsepower available in today's processors to prevent snaps, crackles and pops. If these happen then something is seriously broken or misconfigured in a modern system. If you wanted a real problem, then you should have been trying to make high quality audio work back in the early 1990's on machines with a 1 MHz clock rate, like some of the people who worked for me at that time were doing.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Follow Ups:
the culprit for me has been wireless, networks and useless software in the background casing high latency spikes that are very high. Soemtimes it is a driver issue even with nominally the correct one.
Wireless can have huge latency, since sometimes packets are lost completely and have to be retransmitted. This can happen due to noise if the reception isn't so great, but it can also happen due to two stations transmitting simultaneously. I have some computers off in a distant part of my home and these are behind a wireless bridge. Pinging this bridge or the computers behind it usually shows low latency, but sometimes there will be a large spike, over 1 second, which I attribute to retransmission. On extreme cases I've seen packets dropped.
The latency tests show operating system latency handling upcalls to applications. Even if this latency is good there can still be problems if the system is starved for CPU time at peak instants. To some extent this problem can be alleviated by raising the priority of the audio application threads, but if another application running at lower priority gets a lock on a critical system resource there can be "priority inversion" whereby the higher priority audio program ends up waiting anyway.
Real time operating systems are designed to deal with these problems, not so much as to banish the problem of running out of CPU time but rather to allow the system to be designed and configured that overloaded configurations can be eliminated when the system is designed and configured. Unfortunately, existing operating systems are not built this way. They can be used for real-time operation provided the load is kept low enough. Unfortunately, general purpose operating systems aren't built on top of a real-time kernal and don't provide the necessary configuration tools and enforcement thereof. Example: a good real-time operating system would not allow a driver to exceed a budgeted time or receive an excessive rate of interrupts, so that the miscreant driver would get nailed rather than the correctly operating audio driver.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"useless software in the background casing high latency spikes that are very high."
Always a bad thing.
I was just hoping that more people might realize the detriment of program/OS activity in general. The lower we can go, and the closer to a direct stream the better IMO. I think this idea might be lost on some though.
playback software. Certainly, - Itunes playback on a PC is much different than jplay....
"Asylums with doors open wide,
Where people had paid to see inside,
For entertainment they watch his body twist
Behind his eyes he says, 'I still exist.'"
"playback software. Certainly, - Itunes playback on a PC is much different than jplay...."
Absolutely... I used the general term "transport" in hope to avoid some people going into seizure during the discussion. Clearly some software is cutting edge, and others pretty bad.
Hi Tony,
I have never actually had such a problem with my systems. But... my thought process was that if the music can be affected, in an extreme case...
Shouldn't the natural progression be to the lowest possible OS interference? Not just low enough?
I prefer WAV to FLAC files, if one can hear this difference, why not look for the lowest OS intrusion possible?
Again, not an obsession,but a noble goal.
regards
Bob
At a certain point where there are no more clicks and pops the question comes whether more tuning should be attempted. At some point, one reaches the point of diminishing returns. Note that as clicks and pops become rarer and rarer it becomes more and more time consuming to find and change proposed tweaks that might be the cause. So if one is following the "start big" diagnostic strategy, one has to stop at some point. Of course if one is also tuning for improved sound quality that is another reason to keep on going, but this is also time consuming, because it may take a lot of listening time to see whether a change is beneficial.
The other approach is to "start small" with an absolutely minimal system that includes the minimum operating system that runs well enough so that you can tweak it, and than add functions needed to run the audio software, the volume holding the music library and the audio interface connecting to the DAC. This is a completely valid approach. Indeed, this is the "purist" approach. Were I to do it, I would probably start with a purpose built operating system that is stripped down totally, something like Arch Linux. That way I would have the potential advantage of being able to read the source code and understand what is going on. This is probably the fastest way to get excellent results if one has the necessary experience with the chosen software, but I haven't tried this yet because I am still a "newbie" when it comes to various Linux distros and lack the facility that I had with navigating via command line, such as I did in the 1960's with various PDP-10 operating systems.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
"The other approach is to "start small" with an absolutely minimal system that includes the minimum operating system that runs well enough so that you can tweak it, and than add functions needed to run the audio software, the volume holding the music library and the audio interface connecting to the DAC. This is a completely valid approach. Indeed, this is the "purist" approach. Were I to do it, I would probably start with a purpose built operating system that is stripped down totally, something like Arch Linux. That way I would have the potential advantage of being able to read the source code and understand what is going on. This is probably the fastest way to get excellent results if one has the necessary experience with the chosen software, but I haven't tried this yet because I am still a "newbie" when it comes to various Linux distros and lack the facility that I had with navigating via command line, such as I did in the 1960's with various PDP-10 operating systems."
Yes a valid and interesting approach. Here are a couple good threads.
I just picked up a Utilite Pro to play with.
Computers can be like riding a bicycle, once you get on you never forget.
But... we are just slower now and need glasses. :)
http://www.diyaudio.com/forums/twisted-pear/250583-building-open-embedded-audio-applicance.html
http://forums.slimdevices.com/showthread.php?97881-Community-Funded-Squeezebox-Replacement-Would-you-be-interested
Post a Followup:
FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
This post is made possible by the generous support of people like you and our sponsors: