diyAudio

diyAudio (http://www.diyaudio.com/forums/)
-   Digital Line Level (http://www.diyaudio.com/forums/digital-line-level/)
-   -   What happens to an audio signal from media player to dac (http://www.diyaudio.com/forums/digital-line-level/227344-what-happens-audio-signal-media-player-dac.html)

n0vtz 8th January 2013 07:27 PM

What happens to an audio signal from media player to dac
 
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

mr_push_pull 9th January 2013 11:10 PM

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.

qusp 9th January 2013 11:19 PM

Bravo!

n0vtz 10th January 2013 02:51 AM

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

Pano 10th January 2013 03:18 AM

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.

n0vtz 10th January 2013 04:03 AM

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

qusp 10th January 2013 09:55 AM

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.

madtecchy 10th January 2013 10:11 AM

Well for one thing .. If you use an aiso driver you can be sure the data wont pass through windows mixer.. on a plus point windows mixer is good for late night listening.. As you reduce the volume level on windows it also reduces the dynamic range ...

DQ828 10th January 2013 10:31 AM

How do you implement "Kernel Streaming"

I use Winamp & SQB Touch with SQB server

n0vtz 10th January 2013 02:41 PM

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


All times are GMT. The time now is 12:09 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio


Content Relevant URLs by vBSEO 3.3.2