|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
66.122.76.214
In Reply to: RE: cPlay - the open source high-end audio player using ASIO posted by cics on May 05, 2008 at 13:31:58
I compared cPlay to MusicBee to MusicBee playing the same 24/96 file from Ramdisk.
Ramdisk made a mild improvement, but cPlay was noticeably better yet.
So, what does cPlay do differently from other players - other than RAM Memory playback ?
(Or is it some sort of secret?)
Follow Ups:
as the saying goes. Hello, everybody. You have probably forgotten, that cplay appeared at first as a supplement player to the cmp shell. CMP was designed earlier to, mainly, stop or kill or suspend other processes that a pc is running commonly while playback takes place. I have seen a diagram of the windows audio process - its TERRIBLE. Before data reaches kernel and after it passes through "fire and water and copper pipes". Then asio itself, its driver uses several other dlls and drivers like portculs.sys and f*ng drmk.sys that portclis is dependent on, but there are many many stages, where echo canceller and audio splitter and sysaudio and redbook and codeks all take place (sorry for punctuation). Cplay was specifically designed to avoid many of the nasties and it is and was to exploit the benefits of cmp. Also, if you read the logs with care, you will find that mostly Cics wrote of ASIO refinements, not DSP. especially at first. Note that cplay is an asio-only player, no foo-out dlls and crap. It's the shortest and most minimalistic player, that I know of. Even video interference was partially taken of by cmp tweaks.
I bet, cics would explain better. But it's ASIO changes that matter most, IMHO.
Serge.
Edits: 01/04/12
is it some sort of secret?
I don't think it was ever a secret though it has never been formally written up, the nearest thing to a write-up being the Release Notes, esp (obviously) those for the last version, v 39.
Though noting that this or that release features "DSP improvements" is a bit cryptic, it does suggest that the program was continually honed to make the code more efficient rather than, as is more common, taken to the point where it worked well enough then inflicted with "features". The approach is in line with the general thrust of the cMP2 "project".
cPlay is of course feature light with a CUI (Clunky User Interface) rather than a GUI. Those who followed the program through fifty-odd releases can testify that its sound quality did steadily improve over the two years (Sept 2008 to October 2010). Try comparing (say) v 2.1 with 2.39 and bear in mind that the only difference between the two besides minor GUI improvements is the efficiency of the code.
Interestingly, the developer of Pure Music, an affordable player for the Mac, seems to be taking much the same approach with, if users are to be believed, much the same results.
HTH
Dave
Thanks for your reply.
You stated:
"Try comparing (say) v 2.1 with 2.39 and bear in mind that the only difference between the two besides minor GUI improvements is the efficiency of the code."
Okay, my question then is, "efficiency in doing what ?"
cPlay is doing something differently than other players, that causes the audio waveform to have less added distortion in the playback process.
At first glance, I thought this was due to RAM memory playback, but the comparisons with other players using RAMdisk confirmed that this is only half the story.
It's not related to timing, because I am using an asynchronous USB DAC that creates its own timing internally.
So, some other usually found distortion has been eliminated in cPlay, and it would be quite worthwhile to everyone to pin down exactly what it is.
(Perhaps what is needed is a very detailed change log, if one exists ??)_
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".
"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: