Jim,
It is a small world
I wasn't being sarcastic in my comment - I think you do get a pretty good comparison of forums. Have you posted your question in other places too - I have only seen it on CA, HA and here?
I am painfully aware (having started in 1976 with my first microcomputer, and progressing to UNIX) of how short the half-life of any computer knowledge is. :-/
Thanks, appreciated! My wife is from the US, so we still go there fairly often to meet her family, even if work doesn't take me there as often as it used to, so I do get to pick up stuff - but usually hate to drag it with me in my luggage.
It is a small world
I wasn't being sarcastic in my comment - I think you do get a pretty good comparison of forums. Have you posted your question in other places too - I have only seen it on CA, HA and here?
I am painfully aware (having started in 1976 with my first microcomputer, and progressing to UNIX) of how short the half-life of any computer knowledge is. :-/
Thanks, appreciated! My wife is from the US, so we still go there fairly often to meet her family, even if work doesn't take me there as often as it used to, so I do get to pick up stuff - but usually hate to drag it with me in my luggage.
The three places you mention are it. Don't think I posed the question well enough for the guys over at HA. Actually in this case you, Paul, and phofman have given the best explanations of all the forums.
I don't think this subject is well understood. Clocking, USB, Jitter are all terms that are bantied about by folks, 98% of which don't have a clue of what it is there talking about.
This is very common in HF radio. Guys will talk for hours on the bands, using "nomenclature" words and expressions endlessly, while not having a clue of what an FET is, or whatever it is that they are discussing
Be talking with you,
Jim
I don't think this subject is well understood. Clocking, USB, Jitter are all terms that are bantied about by folks, 98% of which don't have a clue of what it is there talking about.
This is very common in HF radio. Guys will talk for hours on the bands, using "nomenclature" words and expressions endlessly, while not having a clue of what an FET is, or whatever it is that they are discussing
Be talking with you,
Jim
Last edited by a moderator:
HA would probably have the best in-depth knowledge, but asking it the right way so as not to cause a fire storm over there is always a challenge
I think they are well understood in the digital signal processing and hard core computer communities, but not among "audiophiles".
Cool! Here is my main rig:
Last edited by a moderator:
You are never to old to lern! Lots of stuff has already been said, but I think I can add some more.
Actually, an audio player just outputs data to the audio driver. Here you have several options as others already noted, some send data to the OS audio layer, some bypass this, and send it the kernel for further processing.
So here lots of stuff can already go wrong. For instance, there is a sample rate missmatch between player and OS. Then resamping will occur. Of as already noted, the volume control just chops away bits. So even if the player will output the correct bit-perfect data, if can still be ****** up later. This is why it is recommended not to use the volume control, and use an output method that almost directly goed to the sound card driver, like ASIO or Kernel streaming.
And bit or byte... doesn't really matter. It's all bits in the end, and things like sampling and jitter are no real concern at this moment. There happens all kinds of buffering in te layers below to handle irregular delivery.
Well, we covered a big part already. Eventually it will go into the soundcard driver. This will somehow take care of outputting the sound. Here you have lots of options and differences. Even here resampling might occur (again) (mostly on cheap soundchips).
In your case, we are talking about USB audio. In general, this is a special standard that is used by most USB audio interfaces, and therefore makes sure you don't need any extra drivers. Some interfaces do have their own protocol and do need drivers. They will generally claim that this will result in better audio quality, or it is to support sample rates of 24bit/96Khz. This last bit is not needed anymore however, since new USB audio standards also support this.
Anyway, generally audio samples are send over the USB bus via the USB audio protocol. How that works can be found here. Basically there are two versions: sync and async. Sync means that the data rate is synchronous to the USB clock. Aysnc means that that is not the case.
I'm not sure that one, but I guess the sound card driver takes care of this. It needs to clock the data in a way so it is correctly handled by the audio hardware.
Look at the PDF I linked, it shows how it works.
Anyway. It's actually quite simple: your DAC receives it's audio data, and buffers it. Then on the other side of the buffer, it reads the data cocked at rate the your DAC finds fine. This way, all (within limits of buffer length) timing issues that might be present are easily remedied, resulting in a low jitter data feed.
Get it?
Actually, an audio player just outputs data to the audio driver. Here you have several options as others already noted, some send data to the OS audio layer, some bypass this, and send it the kernel for further processing.
So here lots of stuff can already go wrong. For instance, there is a sample rate missmatch between player and OS. Then resamping will occur. Of as already noted, the volume control just chops away bits. So even if the player will output the correct bit-perfect data, if can still be ****** up later. This is why it is recommended not to use the volume control, and use an output method that almost directly goed to the sound card driver, like ASIO or Kernel streaming.
And bit or byte... doesn't really matter. It's all bits in the end, and things like sampling and jitter are no real concern at this moment. There happens all kinds of buffering in te layers below to handle irregular delivery.
Well, we covered a big part already. Eventually it will go into the soundcard driver. This will somehow take care of outputting the sound. Here you have lots of options and differences. Even here resampling might occur (again) (mostly on cheap soundchips).
In your case, we are talking about USB audio. In general, this is a special standard that is used by most USB audio interfaces, and therefore makes sure you don't need any extra drivers. Some interfaces do have their own protocol and do need drivers. They will generally claim that this will result in better audio quality, or it is to support sample rates of 24bit/96Khz. This last bit is not needed anymore however, since new USB audio standards also support this.
Anyway, generally audio samples are send over the USB bus via the USB audio protocol. How that works can be found here. Basically there are two versions: sync and async. Sync means that the data rate is synchronous to the USB clock. Aysnc means that that is not the case.
I'm not sure that one, but I guess the sound card driver takes care of this. It needs to clock the data in a way so it is correctly handled by the audio hardware.
Look at the PDF I linked, it shows how it works.
Anyway. It's actually quite simple: your DAC receives it's audio data, and buffers it. Then on the other side of the buffer, it reads the data cocked at rate the your DAC finds fine. This way, all (within limits of buffer length) timing issues that might be present are easily remedied, resulting in a low jitter data feed.
Get it?
n0vtz, you'll have to excuse me for doing a bit of Internet stalking and reading the discussion over at CA but this discussion got me curious.
you'll have to give me points for guessing that you did spend some time over at CA it really shows and me guessing it wasn't a coincidence. it's not an insult in any way, far from it as our friend Julf who's an outspoken objectivist is a member there too.
many if not most of the things they said there were answered here too.
oh and forgive me for thinking you're an absolute newbie, but it's the OP's responsibility to put the question into perspective, we're not mind readers
I have worked in ASIC verification for more than 4 years. one thing I can tell you is that in a team made of more than 10 people, only one had the big picture of things. and it was only a relatively moderately complex chip (IP core, actually, but it's the same for all practical purposes) by today's standards. he was the principal designer, he oughta. for instance, I could tell you where the data being output was clocked, but if I wre to tell you the amount of jitter the PLL clocking it had, believe me, I'd have pretty much given up before finding the answer. and I was directly involved as a professional in that.
what I mean by all this? I'd be very pessimistic in hoping that you'll find the answers you are looking for here. I'd try in other forums, maybe not even audio-related ones. this is not stuff invented and/or used by audiophiles, as you very well know.
you'll have to give me points for guessing that you did spend some time over at CA
it really shows and me guessing it wasn't a coincidence. it's not an insult in any way, far from it as our friend Julf who's an outspoken objectivist is a member there too.many if not most of the things they said there were answered here too.
oh and forgive me for thinking you're an absolute newbie, but it's the OP's responsibility to put the question into perspective, we're not mind readers
I have worked in ASIC verification for more than 4 years. one thing I can tell you is that in a team made of more than 10 people, only one had the big picture of things. and it was only a relatively moderately complex chip (IP core, actually, but it's the same for all practical purposes) by today's standards. he was the principal designer, he oughta. for instance, I could tell you where the data being output was clocked, but if I wre to tell you the amount of jitter the PLL clocking it had, believe me, I'd have pretty much given up before finding the answer. and I was directly involved as a professional in that.
what I mean by all this? I'd be very pessimistic in hoping that you'll find the answers you are looking for here. I'd try in other forums, maybe not even audio-related ones. this is not stuff invented and/or used by audiophiles, as you very well know.
Last edited:
hasn't any bought a computer in the past 6 years
3 major releases of windows and we still get the "lost bits" nonsense in these discussions
what modern audio sw "chops off bits" that can be heard? - even with 16 bit source windoz today (and for a good while now) can be told that you have 24 bit DAC, will send the top 24 bit of the typically 32 bit internal DSP processing calculation representation to the DAC = at least 48 dB of volume reduction before you are formally "losing bits"
of course by then it don't really matter with 24 bit lsb being way below the DAC's own output stage electronics devices noise floor - even for SOTA external DAC
and no one seems to even want to understand dither...
3 major releases of windows and we still get the "lost bits" nonsense in these discussions
what modern audio sw "chops off bits" that can be heard? - even with 16 bit source windoz today (and for a good while now) can be told that you have 24 bit DAC, will send the top 24 bit of the typically 32 bit internal DSP processing calculation representation to the DAC = at least 48 dB of volume reduction before you are formally "losing bits"
of course by then it don't really matter with 24 bit lsb being way below the DAC's own output stage electronics devices noise floor - even for SOTA external DAC
and no one seems to even want to understand dither...
Last edited:
marce could tell you where, how, why the clocking will happen in the PC, I would think its varies on the transfer mode and who is hosting the connection, the dac or the PC. I doubt it will have anything to do with the audio hardware at all, rather the USB TX since it (the audio data) doesnt really have the clock embedded mostly, as PCM/i2s standard does not contain master clock. MCK is assumed to be in your dac or audio interface, which is now an external USB device
Last edited:
qusp;
Forgot to give you the location of the 3 ps measurement in the Dacit. That measurement is at the clock, or the accuracy of the clock by itself. The Dacit has the ESS Sabre 9023.
Fifo buffer may be exactly what I'm looking for. Wanted to replicate or improve upon the reclocking of the SOTM USB PCI for the system here. I'm beginning to wonder if it will be worth it though? Lots of folks think it is a waste of time, and that the SOTM reclocking affect is minimal in an overall performance increase.
mr_push_pull;
Again, good test. Of course there are checksums. I tried to set up a null test with audacity, but what a pain getting the phases close enough, as well as the problem of tha A/D and problems it introduces.
Would you allow me to post your test at CA, so some impressions can be made over there about bit perfection? A no is perfectly ok. :0)
Haven't read your last post yet.
4real;
Thanks for your post. I haven't had time to go through it yet...
Jim
Forgot to give you the location of the 3 ps measurement in the Dacit. That measurement is at the clock, or the accuracy of the clock by itself. The Dacit has the ESS Sabre 9023.
Fifo buffer may be exactly what I'm looking for. Wanted to replicate or improve upon the reclocking of the SOTM USB PCI for the system here. I'm beginning to wonder if it will be worth it though? Lots of folks think it is a waste of time, and that the SOTM reclocking affect is minimal in an overall performance increase.
mr_push_pull;
Again, good test. Of course there are checksums. I tried to set up a null test with audacity, but what a pain getting the phases close enough, as well as the problem of tha A/D and problems it introduces.
Would you allow me to post your test at CA, so some impressions can be made over there about bit perfection? A no is perfectly ok. :0)
Haven't read your last post yet.
4real;
Thanks for your post. I haven't had time to go through it yet...
Jim
I really don't think that test says all about bit perfection. It only shows that bit error can be heard immediately. There are other ways to get imperfection, and most of them are alredy covered here: resampling and volume control. Those are far les obvious to hear them a random biterror, but still give you an output signal (lets say on spdif), that is not bit for bit the same as what is on file (assuming uncompressed audio) on your PC.
I'd say, forget about the expensive usb PCI card. Your DAC already has all the things it needs to do it's job just fine.
I'd say, forget about the expensive usb PCI card. Your DAC already has all the things it needs to do it's job just fine.
Last edited:
That's pretty close to the mark, but not in the sense you intended.
I had a look on CA and on HA. I think the response on HA was pitched at about the right level. 'Ask a stupid question and you get a stupid answer' is about how I'd paraphrase it.
What are you doing digging into all this stuff when you haven't got the background to pose an intelligent question? Thrashing around in the hope that somebody will spoon-feed you?
Go read some datasheets on USB DACs. TI PCM2906. Do some searches on google. Search synchronous, asynchronous and isochronous USB. All this stuff is out there, it'll only take you a few years to get to the point where you'll be able to understand the answers.
Or he could ask the simple and obvious questions and get some helpful answers. If you are unable to explain things clearly and politely in the face of straightforward questions, then let those who can do it do it.
sure. but I made another set with even smaller difference (yet still audible on my $10 headphones driven by built-in sound card). feel free to choose whichever. see attached files.
of course it only applies to data corruption at transmission side but that's what some folks claim. concerning Windows processing, I haven't searched the Benchmark Wiki page but I'd rather trust them if they say player X is bit accurate. after all, WA and foobar are free, why would they lie? and I'm almost sure there are many other publicly available tests confirming this. should we all buy/build USB analyzers to confirm it?
Attachments
Last edited:
I woudn't doudt it. I'm merely stating that there are factors that might affect your bits. If configured correctly, it works just fine.
Why do that. Just loop your spdif back into your pc and record what you play. Remove the offset and compare original to recording.
Last edited:
covered it first reply
but I might have missed something.I wasn't aware of S/PDIF to USB converters and USB recorders. do you have some links?
Thats not what I meant (would be nice to get 480mbit over spdif though)
I just mean using a usb audio interface with spdif in and out. If loopback gives you no differences, then there no need for an expensive USB analyser. And even if there are differences, you can bet that it is not the USB interface that is mangling the data. It's absolutely nonsensical to think that that might happen. But I guess you already knew that
Thats not what I meant (would be nice to get 480mbit over spdif though)
"No differences" is the problem here, and how that can be known. You can eyeball two comparative spectral representations, and say they look very similiar, but to tell conclusively you need to do a null test with them, obviously inverting one. Audacity allows you to begin to do this. It is matching them for a null test that is difficult.
Volume can be matched with a simple audacity function, but getting them matched so there is no phase differences is difficult.
No matter how careful you are (at least with audacity), where you want silence (if bit perfect in and out) when they are mixed , there will be residual noise apart from discrepancies that may exist in the system that we are actually trying to measure.
Jim
My goodness - busy thread!
It's not hard to achieve bit perfect copies. I've even done it thru the evil K-Mixer, but that might have been at 48KHz.
As for jitter, I do not have a good way to measure SPIDF or USB jitter, but in many ways I don't care. What I do care about is if it makes a difference to the analog output of the DAC. That is the signal that matters, because that is the signal I listen to. Looking at the DAC output via FFT will show, or not show, jitter sidebands in the analog signal. They can be easily seen on cheap DACs, but are very low on better DACs.
That's about as sophisticated as my testing gets, but it works for me.
For bit perfection I do a simple test. I play a file (music or test tone) from a software player on computer A. I send that signal via SPDIF to a SPDIF input on computer B, were it is recorded. I use either a checksum or Diffmaker software to verify.
It's not hard to achieve bit perfect copies. I've even done it thru the evil K-Mixer, but that might have been at 48KHz.
As for jitter, I do not have a good way to measure SPIDF or USB jitter, but in many ways I don't care. What I do care about is if it makes a difference to the analog output of the DAC. That is the signal that matters, because that is the signal I listen to. Looking at the DAC output via FFT will show, or not show, jitter sidebands in the analog signal. They can be easily seen on cheap DACs, but are very low on better DACs.
That's about as sophisticated as my testing gets, but it works for me.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.