![]() ![]() |
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
75.131.20.113
In Reply to: RE: I have to Agree With Fmak and Carcass posted by Tony Lauck on July 10, 2012 at 11:04:15
Have you verified that both O/S configurations are bit perfect? If so, how did you do this?
Two ways.
One send a higher sample rate to the Dac and watch the light reflect sample rate.
Two:
cat /proc/asound/card0/pcm0p/sub0/hw_params
This will give you the result of sample rate and bit depth.
Also like I said....using "hw" to set up MPD is bit-perfect.
CPU bugs affecting one mode of addressing.
Kind of hard to swallow that my CPU has a BUG which contributes only to digital audio. Everything works perfectly in 32 and 64 bit.
I looked at the Wadia web site to see how their USB input works. I didn't get a good feeling for what I read. It looks like copy written by the marketing department.
The Wadia uses XMOS as the USB interface, if there is a fault or defect in the device it would fall into XMOS's lap. BTW I do have another USB-to-SPDIF converter that is Asynch. In fact I have two, the Musical Fidelity V-Link and the M2Tech HiFace 2.
In your case, you've said the differences are large, so isolation may be (relatively) easy, particularly if you have a variety of equipment you can mix and match for listening tests.
Yep, I have tons of gear, converters and Dacs with a variety of input methods. Really easy to start changing variables.
Either way, I am not an isolated case. Others hear differences as well, we can not assume that everyone who hears a difference has a Bug in their CPU or defective gear. At some point we have to accept the reality that people can perceive differences in sound from the computer.
The only way to get to the bottom of this is acknowledge all perceptions and start to isolate and manipulate variables. Still, given a large enough sample size there will be those who fall at the ends of the Bell Curve [no difference at all -and- a marked difference] and those who fall at various points within the curve at hearing a difference when certain variables are manipulated.
This kind of study may be useful to a manufacturer who wants to spend time/money on variables that are perceived by the greatest number of people as having a impact on sound.
People on one end of the spectrum will likely not notice any advantages to features developed to enhance sound. While people at the other end will likely notice differences in sound related to enhancements. Of course those who do not notice any difference will not understand or believe that anyone could legitimately discern a difference.
Dynobots Audio
Music is the Bridge between Heaven and Earth - 音楽は天国と地球のかけ橋
Follow Ups:
What you described shows that the sample rate getting to the DAC is what you expect. It does not show that the bits are correct. Similarly, showing the setup parameters of the MPD shows how the software is "supposed" to work, but not that it actually is working this way.
My comment about CPU bugs was in the spirit of showing that trusting a complex piece of computing equipment may not be wise if it is possible to perform tests to verify correctness. Intel got to the problem with CPU bugs in the Pentium, where certain floating point calculations were incorrect. They were going to cover this up rather than spend the million(s) of dollars to scrap and retrofit, but were convinced by some experienced people that this would ruin their reputation. We didn't have this problem with the VLSI CPUs designed at Digital Equipment Corporation, but only because we had previously experienced problems with inaccurate arithmetic. At least one published scientific paper in a refereed journal had to be recalled after errors in calculation were found to have arisen due to a logic design error in one of our CPUs. As a result of this experience, an entire department of "computation quality" was established at DEC to prevent these kind of errors from happening again. Fortunately, no one was killed, as might have happened if the error had appeared when designing a bridge or airplane.
Everything does not work perfectly. If it did you wouldn't be hearing differences. Since you are hearing differences, something is not working perfectly. If you care about these differences then with sufficient determination you can get to the bottom of them.
The reason why I don't presently hear differences in my transport is that I have systematically exterminated them to the point where the ones that remain are beyond the resolution of the rest of my system and my hearing. If I had not gotten to this point I wouldn't be posting now, I would be trying to figure out what is causing the differences that I hear and what I could do about them. In the case of any new piece of equipment this process can be very time consuming, whether it is a computer, a new OS, a new player, a new DAC, new amplifiers or speakers, etc. I am talking about months of testing and tweaking.
Saying that "everything matters" in audio is a cop-out. If everything matters then nothing matters and one will be constantly spinning one's wheels. Focus is needed.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
Everything does not work perfectly. If it did you wouldn't be hearing differences. Since you are hearing differences, something is not working perfectly.
this is really a tautology, and while true in some sense, just seems to beg the question.
If one can isolate the cause of a difference to a part of the system that is relatively easy to improve one can make progress. This can be done by careful experimentation involving a combination of listening tests and measurements.
It is inexpensive but not necessarily easy to achieve bit perfect audio from a computer system. This is is one of the easy steps that can make a big difference. Some posters seem to believe they have achieved this, but from reading their posts it seems likely that they have been fooled. (This is based on my personal experience of having been fooled more times that I would want to admit.)
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
I can see that you are firm in your position.
Stubborn....hmmmmmm
Dynobots Audio
Music is the Bridge between Heaven and Earth - 音楽は天国と地球のかけ橋
You haven't shown that you are getting bit perfect audio from the two versions of Linux. I would bet that you aren't, since the history of digital audio shows that bit perfect sound is rare. Here's a little history to consider:
Going back about 10 years when pro audio software started to be used to produce recordings on computers there were many packages that had poor quality DSP and that were not bit perfect in "bypass mode". This was the rule, rather than the exception. After bad press, articles, books and tools appeared this situation started to change. Computer audio then moved into the audiophile arena. Going back about four or five years, all the Apple fanboys used to complain about how bad Windows was, how it it wasn't bit perfect, etc. Eventually people figured out how to work around these limitations. Then about two years ago the Apple fan boys started noticing that there were problems with the Apple audio software and a proliferation of audiophile products started appearing. Perhaps it's now time for Linux and we will start seeing the issues appearing and getting solved. Or perhaps there are other forums where these issues have already surfaced.
Even when software is known to be bit perfect there are still so many combinations of options, knobs, switches, etc., that it is never clear whether a particular setup is actually bit perfect. The only way to know for sure is to test it. Software is so easy to "update" and "improve" that even if things are bit perfect today, tomorrow they may not be. So it is necessary to periodically vet the software.
Tony Lauck
"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar
You haven't shown that you are getting bit perfect audio from the two versions of Linux.
----------------------------------------------------If I send 3 different files recorded at 3 different sample rates and both the proc information from the computer and the Dac say they are sending and recieveing the sample rates correctly how is this not proof of bit-perfect?
If I used the guide lines provided by the audio software [MPD] and ALSA to configure bit perfect audio, how is this not proof of bit-perfect?
I have been using Linux for the past 6+ years and have always gotten bit-perfect. I've been into Computer Audio for nearly 10 years so the pro's surely have been using it longer than me. Bit-Perfect from Linux is no secret and it surely does not lag behind Windows and Mac.
If you don't think people can and do get bit-perfect audio from Linux then what can I say? I guess Linux will be bit-perfect when you say it is....and Linux users will know how to get bit-perfect when you show us how because we are all doing it the same way.
BTW, Pro audio was using computers a lot longer than 10 years ago. ProTools has been out for more than 20 years.
Wiki:
The first version of Pro Tools was launched in 1991, offering 4 tracks and selling for $6000USD. The core engine technology and much of the user interface was designed by and licensed from a small San Francisco company called OSC. OSC was known at the time for creating the first software-based digital multi-track recorder, called DECK, in 1990.[5] That software, manufactured by OSC, but distributed by Digidesign, formed the platform upon which Pro Tools version 1 was built. The OSC designers and engineers responsible for that technology, Josh Rosen, Mats Myrberg and John Dalton, split from Digidesign in 1993 in order to focus on releasing lower-cost ($399)[6] multi-track software that would run on computers with no additional hardware. Although the original design remained largely the same, Digidesign continued to improve Pro Tools software and hardware, adding a visual MIDI sequencer and more tracks, with the system offering 16 bit, 44.1 kHz audio recording. In 1997 Pro Tools reached 24 bit, 48 track versions. It was at this point that the migration from more conventional studio technology to the Pro Tools platform took place within the industry.[7]
Dynobots Audio
Music is the Bridge between Heaven and Earth - 音楽は天国と地球のかけ橋
Edits: 07/10/12 07/10/12
.
I don't see how any of your tests prove anything about the data other than it is the same depth and rate.
Bit perfect to me means if the original file sample stored on the computer is 1101 1001 1111 0101 then what ends up being fed to the DAC chip is the same 1101 1001 1111 0101 and no samples are altered.
How does any of what you stated prove that is true? How did you prove that the data had not been somehow changed?
.
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: