|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
85.211.128.44
In Reply to: RE: cPlay - the open source high-end audio player using ASIO posted by Ken Stuart on January 04, 2012 at 09:57:24
my question then is, "efficiency in doing what ?"
In crude terms, the number of instructions the program executes to perform a given operation. I'm no programmer but I recall working with programmers who would write a program so it worked after a fashion then spend a long time refining the code so it ran faster. Compare e.g. "the square root of the product of the square of four and the square of two divided by four times the square of one" with "one plus one". (I think I have that right).
One particularly skilled programmer I worked with would get his routines working in Fortran then re-write them in Assembly language. I've seen differences of one, maybe two orders of magnitude in runtime.
cPlay is doing something . . . that causes the audio waveform to have less added distortion
As I see it, no waveform is passed to the DAC - the DAC creates one from a stream of data but has to do so in real time. (The meaning of "real time" has been disputed here but it's clear enough IMHO in the USB audio context.)
It's not related to timing, because I am using an asynchronous USB DAC.
An asynchronous transfer protocol reportedly reduces USB timing errors (I say 'reportedly' because I've never heard a device using one, let along compared it with others) but developers on this forum at least are adamant that it is not a panacea. I don't think that anyone seriously suggests that a correctly-configured Foobar (e.g.) is not "bit perfect". USB cables apparently affect asynch devices. And so on: the effects are subtle.
If I may say so, it is refreshing to read a post that starts with perceptual evidence and queries the orthodoxy rather than the other way round. A common response is "I don't see how it can . . therefore it doesn't".
Follow Ups:
"As I see it, no waveform is passed to the DAC - the DAC creates one from a stream of data but has to do so in real time."
Yes, "audio waveform" is talking about the eventual analog. In terms of digital, it would be alterations of data values.
Now, I can certainly see how electrical noise, voltage spikes, etc. could cause alternation of data values in a PC, so all the hardware mods make sense (with the only variable being the actual degree of benefit of any particular mod, which varies with each listener's ears and audio setup).
And I can see how any process running the same time as an audio player could cause a disruption (skeptics clearly do not understand the difference between a real-time streaming digital process and an error-corrected "offline" process).
But I don't understand how any non-faulty code in a player, can sound better than non-faulty code in a different player, both of them running on the same PC, so the above factors of hardware and OS generated noise and spikes are the same for both players.
You state: "I've seen differences of one, maybe two orders of magnitude in runtime." An audio player has to process one second of audio data within one second, since it is real-time. I don't see a benefit for completing it in a tenth of a second.
I'm not using upsampling, so that is not part of the equation, and it's a 2.80ghz dual core processor, so it is not being taxed at all by any audio player.
PS I'll table the USB/jitter issue for now, except to agree that it is not a panacea, because timing jitter is certainly not the only distortion.
hey Ken,
I certainly dont know for certain and Ryelands and steppe have given some good explanations.
But I don't understand how any non-faulty code in a player, can sound better than non-faulty code in a different player, both of them running on the same PC, so the above factors of hardware and OS generated noise and spikes are the same for both players
Not sure it is that simple. And I definitely DONT think that all players create the same hardware and OS noise. I know this for a fact.
Let me explain. There was a time when none of my outlets were grounded (it was an apartment). There was a something similar to hum, but it was different in that there were just noises that ranged up and down the audio spectrum. Some players sounded like a growl, some like a delivery truck backing up, some a bit of both. I think that alot of the sound might be from the HDD or cpu, etc.. The sound was soft and with the volume down you could hear it but it didnt change with the volume. The computer noise was definitely different among different players.
The main things that people complain about cplay are IMHO some of the reasons it sounds so good. For instance the black and white no nonsense display. That cuts down on video noise. The ASIO only capability. As steppe mentions that bypasses a bunch of badsounding os stuff. I recall cics talking about "period jitter" and how asio could control it. See the link below. I know he spend a bunch of time on asio refinements and i can tell you from my Lynx card that asio drivers make a huge difference.
Finally cplay is the only player I know of that was designed around a comprehensive hardware and software approach and I think it shows.
No one here remembers the bending of our minds
Hey Ken,
More on the async usb
No one here remembers the bending of our minds
Fortran...I used to program in that many years ago as well as Basic and APL. We had a version of Fortran developed by Nasa called Nastran that did highly sophisticated stress analysis (for its day) of Vehicle parts. For sure this was a long time ago when the computer was humongus in size (maybe the size of todays c class car (focus)). Ahh the good old days.
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: