What happens to an audio signal from media player to dac

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
I have been trying to figure out from JRiver via USB to a Peachtree Dacit what is happening to the signal precisely and the places and stages of processes it goes through as it moves through the computer and finally to the Dacit.

Possibly someone can direct me to a tutorial, I have looked in vain on the net, or give me a basic description that I can use to figure it out.

Examples;

1.) What is the output of JRiver, a bit or byte stream, embedded with wasapi driver information, or what?

2.) Where does it go from JRiver?

3. )Where is the data clocked by the computer?

4.) Is the USB output to the Dacit in PCM or is it just a raw data stream?

Hope someone has the time and inclination to give me a hand here. Am using JR 17

Thanks,

Jim
 
first, why are you asking this?
if I'm allowed to speculate a bit, did you spend time on "subjective" audiophile websites recently, websites which go on a lot about night-and-day sonic differences between software players?

second, the way the questions are phrased, you seem to be assuming some things and I'm not sure exactly what you mean by them. for instance, inside a computer the data literally goes through millions of flip-flops, each with its own clock, so it's clocked in millions of places. or, what is the difference between PCM and raw data stream? PCM is a series of words which are basically raw data.

if I were to reply to what I think you're asking...
as long as you configure it properly, any player is OK. for instance, if you use Winamp you should just disable the EQ and enable 24 bit output (in case you listen to hires files too). and it's best to use something like Kernel Streaming because it by-passes some Windows layers. for one, XP has the most basic implementation for the volume (it just truncates) so unless you set the volume to maximum (and anyone or any application can mess with it without you knowing) there is truncation going on. second, XP is known to get "stuck" on some output format from time to time. that means that if you happen to play, say a 16/48 file, it may start to internally convert all the subsequent data you play to 16/48. it doesn't always happen AFAIK, I have a DAC which displays the sample rate and sometimes it gets stuck to some random format until I restart the PC. unless I use Kernel Streaming, that is. aside from that there is no internal processing done by Windows, unless you install some third party SW. it has been checked.
oh, and if you're worried about data that gets corrupted somewhere... a single, and I repeat single corrupted bit is *very* audible. I have tested it for fun. take a sine, open it in whatever editor and manipulate just one sample, and it doesn't have to be by a lot. play that sine and you'll hear a very clear click at one point. music would be unlistenable if anything like that really occurred. want my opinion? data getting corrupted by USB transmission is a myth that stems from the days when Windows really sucked and soundcards (plus the respective drivers) sucked even more. I remember that on my first PC simply expanding a tree view (clicking on the "+" inside the square) in Explorer caused a loud screech if there was music playing.
oh, and since we're here, wanna know my opinion about where Winamp's bad reputation started? back in the day when mp3's were invented, many encoder/decoder implementations were awful. I clearly remember that one of the first Winamp versions sounded terrible, made bass guitar sound like piano keys struck with a hammer. but that is a matter of badly decoded data. I think it's the same with Windows, when it was awful, it WAS awful but now it got better and those are non-issues.

and if you use an asynchronous DAC, the clocking is not dependent on the PC, it's the DAC's responsibility. that doesn't guarantee it's all pristine because the DAC can **** it up from there on its own but it's agood place to start.

IMO, if you're worried about sound quality, it is my personal belief and experience that unless you have an absolutely state of the art audio chain that is used in an acoustically treated room, your software player is not the weakest link (if it ever is). foobar and WA are bit accurate (yes, it's been verified) and there are good DACs that take care of the jitter. and galvanically isolated ones are available too, if you're worried about the ground noise.

and one more thing. eventually a subjectivist will jump in and say that all the above doesn't mean iota because he can hear a difference. well, maybe that difference is even real but don't hope to get a reasonable explanation for it.

boy, what a rant this turned into. if the info is of no use to you, well, just my wasted time.
 
mr_push_pull;

Well thanks for the response. Most of your assumptions are incorrect, but that will happen when you do a lot of guessing. :0)

System is; pc (Win 7) (JRiver-JPlay)>USB>Peachtree Dacit (ext. ps for main and USB implementation>Emotiva XPA-5 (bi-amped). Snell C/v's

Just finished putting together a JLH filter for 9v. from a linear and a 7805 with another JLH for 5 v. Humble system, but I like it's sound. Considering modifying the Emotiva.

Reason for questions is to get a better understanding of of the internal dymanics and movement of the audio signal path in the pc. Questions are I believe pretty indicative of that.

Am aware of fundamental digital electronics, and flipping and flopping. :0) Clocking as I assume you know has to do with on board XTAL's, and PCM data is "clocked" in the I/O hub controller (ICS?). Your idea of clocking is actually a function of the specs of transistor and it's biasing characteristics.

So, I've only been at this audiophile business for a couple of years, and have a lot to learn. Learning at 64 is a bit more difficult than when I was a young whipper-snapper. :0)

So that's my motivation. You have a good what's left of the day...

Jim
 
Administrator
Joined 2004
Paid Member
I've been using JRiver for about 5 years now via ASIO drivers. I don't know where it goes once it leaves JRiver, but it somehow ends up at the USB port and then I convert it to SPDIF. Or in one computer it goes to a PCI soundcard with SPDIF output.

Whatever it's doing, it can easily be bit perfect at the output (I've verified it). As for clocking and jitter, I don't see much on the analog outputs of the DAC. I suppose that depends mostly on the soundcard, USB or otherwise.

Sorry not to be more help. I'm slightly curious to know where it goes, too. You may find an answer on the JRiver interact forum.
 
Pano;

I'd be interested in how your verifying bit perfection, and how your measuring jitter at your analog output.

Been getting this slowly figured out with a lot of help from a lot good folks. A track picked in JRiver is transferred to Ram (random access memory), where it is decompressed back into it's original PCM ( or LPCM ) or wav. format. Then it is buffered and sent off to USB in the I/O controller hub. by ASIO or Wasapi, whatever API we are using in JRiver. Hope I have that all correct.

I used an Asus Xonar card before for S/PDIF (Coax), and it was very good, but after I cleaned up the power supplies for the Peachtree Daci, USB noticeably outperformed S/PDIF.

Be nice to hear back from you about evaluating jitter procedures you use, and verifying bit perfect conditions.

See ya,

Jim
 
I believe his point was that if you are using an asynchronous source/dac (key point), the clocking and encoding of the raw data itself in the USB and PC (bitclock, wordclock, sdata) has no impact, only the local dac clock does. provided the data is bitperfect and timing info only imposed at the last minute, it really does not matter what happens on the way there.
 
Last edited:
qusp;

Thanks for your comment. The Peachtree Dacit is adaptive (isochronous), purporting to correct the data stream for jitter to 3 ps. Hehe, that claim tends to get people riled up!

Actually my purpose in trying to understand the audio signal path and pc clocking is to do by way of DIY what SOTM has done with it's USB PCI, that is to reclock the serial PCM to a higher level. I tend to believe that a better corrected data stream input to the Dacit, will give an improved output as compared to data clocked only by the pc clock.

Of course opinions vary on this subject, but that is my bias.

madtecchy;

Peachtree Dacit does not support ASIO, so I have no experience with that API for my present setup. Using Wasapi-event style, which functions in exclusive mode.

DQ828;

Have no experience with SQB.

Jim
 
thats alright, we are running a system here on the forum that is outputting ~1.5ps buffered i2s. measured, proven. well actually Ian had to cripple the unit with a higher jitter generic clock to get a measurable result of 5ps, because his scope has a 2ps noise floor. using the intended 0.5ps clocks it works out to 1.5ps period jitter including the small amount from the flip flops.

so if your one gets people riled up... =) i'm readying for war lol.

if the peachtree uses a similar memory buffer type reclocker, actually your efforts, though understandable, would be in vain. a large amount of jitter may perhaps cause an overrun on the memory. probably it has an isochronous connection to the micro doing the conversion to i2s, but the output of the memory is asynchronous to that input (offset by the time it takes to half fill the fifo buffer) but if it doesnt overrun, I cannot think of any mechanism in the PC that would improve on it.

the measurements of this system were taken with 150ps jitter on the input signal and its the same whether optical, electrical spdif or i2s input. a complete leveller, the dac becomes completely transport agnostic.
 
qusp;

Well, from now on when they give me headaches about 3 ps at the clock in the Dacit, I'm going to just send them your way, hehe. :0)

I might have to find out more about that Dac. The fact that coax or toslink are giving the same readings is interesting.

God forbid, ps, I wish I could measure at those levels. I have a heck of a time just measuring uv's for the JLH filter. I use VA Analyzer (free software), but trying to calibrate and verify a reference voltage is pretty iffy. My scope goes to 50 mv increments, so uv measurements are; how thick is the trace line. :0)

Thanks for the explanation on the Peachtree and my quest for better clocking. It seems anyone that knows what they're talking about says the same thing. I'm going to have to think through what you said.

The system here now works so well, but you know how it is, we just need to find something to screw with...

Sincerely,

Jim
 
Most of your assumptions are incorrect, but that will happen when you do a lot of guessing. :0)
like I said, my wasted time.

Reason for questions is to get a better understanding of of the internal dymanics and movement of the audio signal path in the pc. Questions are I believe pretty indicative of that.
I'm not sure exactly how it helps. after reading the rest of the replies I'm still not sure what you're getting at.

Clocking as I assume you know has to do with on board XTAL's, and PCM data is "clocked" in the I/O hub controller (ICS?). Your idea of clocking is actually a function of the specs of transistor and it's biasing characteristics.
it has to do with board XTALs, board PLLs and many other things. if it's jitter you're getting at, there are even more factors involved (noise that gets into the circuits involved in many ways, power supply noise, the quality of all the circuits involved and even mechanical vibration which the XTALs are susceptible to etc). I believe the extent of control you have over what's going on inside your PC wrt jitter is very limited but I may be wrong. unfortunately jitter reduction is not a matter of just clocking in the right place. just search for some technical articles on PLL implementation details and unless you're very inclined or an EE you'll likely give up pretty soon as its not exactly science for the masses.

I'd be interested in how your verifying bit perfection, and how your measuring jitter at your analog output.
you have the option to just trust what others have done, for instance Benchmark Media: Main Page - Benchmark
I remember reading there that they test the SW players for bit "perfectness".
there's a setup page for J-River: J River for Windows - Setup Guide - Benchmark maybe they say something about it there.
second option is to do my test. and to make things easier for you, I'm attaching two 16/44.1 files containing a 440Hz sine, one of which has a sample altered (see pic). give them a listen and see if you can detect the clicking sound. ok, maybe you'll say that you listen to music, not sines but whatever artifact of the kind that is audible with music will be even more audible with sines (I assume that you know how low amounts of harmonic distortions are very audible with sines but not so obvious with real music). and unless for some reason it's just one of the least significant bits in the data that is corrupted and it only happens in the most "convenient" moments, you'll hear it. just try it, it takes a few seconds to download and unpack the files.

USB analyzers are expensive, there is no other cheap and quick way to test bit accuracy for yourself.

as for jitter, it's more complicated. search for J-Test and Julian Dunn. Julian Dunn (RIP) was the first to devise the jitter test signal as it is used now in measurement procedures (the plots you see in Stereophile et al. are derived from a digital J-Test signal fed to the D/A converter). you will need rather expensive equipment to do that sort of testing so that you can be sure you're not really measuring its limitations. a very good pro soundcard may do the trick but the cost is again significant.


I'm sorry if I'm stating the obvious and/or it's all old news to you, as you can see I have poor mind-reading abilities :)
 

Attachments

  • pack.zip
    574.3 KB · Views: 34
  • altered.gif
    altered.gif
    26.8 KB · Views: 126
its not a dac, its a dedicated i2s Fifo Memory Buffer has modules for spdif input a couple different clock modules, a galvanic isolation module to wall off the PC ground and a PCM adapter daughterboard to allow it to work with different dacs that dont take 32bit PCM, or require special clocking tricks like TDA1541, PCM1704 etc etc.

its a pretty long thread, there is a wiki with a compiled list of important links in the development thread as well as detailing the different modules. its only new so not exhaustive yet.

Its a very well executed build, one of if not the best conceived digital modules on this forum IMO. its not very happy news for some people that just love tweaking their PCs and have invested a great deal of money and time, but that was the point and only recently (a few days ago) did he go through with the in depth measurements, because as you mention its not an easy task and we all were very confident in the result.

all the same to see the objective data to confirm it was a pretty happy moment.

that being said, if the numbers they are quoting are real and you are happy with the way the dac itself performs, I reckon just move on and find something else to tweak, (speakers...) the difference between 3ps and 1.5ps is exceedingly unlikely to be audible. is that 3ps the output of the clock, or where are they measuring that? are they still using ES9018 in that like the Nova?

the fifos power is that it means we can get this same performance with our dacs of choice and which ever type of input we like, but a well executed integrated dac can work just as well. suits me better as I tweak constantly. plus it will handle 44.1->384kHz in synchronous mode with my ESS dacs and it has proper impedance controlled layout and impedance controlled connections on u.fl micro BNC

people will start to think i'm a salesman for Ian hehe, but the truth is, not only would there be little margin for that (the pricing is almost too good) but i'm simply just happy to try and curtail the tail chasing involved in fighting the wars inside the computer when even a perfectly conceived computer transport still leaves issues that need solving; best just tackle it at the dac where its easier to control/ modify. plus with these latest measurements I can be more confident in recommending it, because i'm not just recommending on design and faith in that design functioning as intended.
 
Last edited:
Jim,

I guess you will also get a pretty good comparison of the expertise levels and helpfulness of various computer audio forums :)
I happen to run into CA pages when googling for various stuff. I generally end up closing the tab on my browser after reading no more than 4-5 posts :) a great, very informative website, in no way full of misleading or downright false info. oh, and obviously in no way plagued by marketing.
 
mr_push_pull;

Thanks for the response. Yep, 2nd file you sent, about 3 seconds in. In your opinion, what does your test and the fact that I detected that click mean in terms of jitter and the system here?

Your correct about inner pc exercises toward perfection. I have isolated with an external ps and a JLH filter the 5 v. (<100 uv noise and ripple) the usb implementation to the Dacit here, but the serial data is another story. As you say, there are EMR and RFI contaminates in this signal and there is little I can do about it, except rely on fifo and clocking in the Dac to correct it and it's potential effects.

If you get a chance check out VA Analyzer, a free software that I use in addition to my old fashioned scope, you may find it useful for attempting some low voltage measurements. The generator and spectrum analyzer are quite good as well.

Thanks again for the files, hope to hear from you about what this test indicates.

Jim
 
it doesn't tell one thing about jitter but it pretty much tells everything about bit accuracy. you mentioned bit accuracy in reply #6.
the idea is that any corrupted bit in the data stream would render even more destructive (audible) results, compared to what you can see (and hear) in the attached files. one bit that gets changed from 1 to 0 or vice-versa can give an error close to 100% as long as it's in the most significant position within a word. and also remember that it's precisely one bit changed out of 44100 words / second that you heard.
maybe I'm preaching to the choir but fact is that there are audiophiles who are convinced that with lower quality (read cheap) D/A converters there is data corruption going on.

jitter is either evaluated by listening or objectively with rather expensive equipment, like I said I'm not aware of any cheap and reliable way to assess the jitter amount.

thanks for taking the time to give the files a listen, you are correct about the position of the altered sample.
 
Julf;

LOL, good to run into you. BTW, your post at CA was very helpful. Had a computer/electronics repair and build shop (come get a dmitri computer!) a long time ago. Boy, I'm not "with it " anymore. Have to do some serious homework. Your post was very helpful, as some here are. Hope to keep running into you. :0)

Jim

ps If you need any parts or stuff from the usa, let me know.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.