BlackCatSound said:
Unfortunately that is one of the very few explanations I came across, which sound logic to me. I regard it as neutral. RME is
not trying to bring its gear into discussion at that point. Beside that there are known for good drivers. I assume they know what they are talking about.
I'd be happy if somebody would come up with a better explanation.
Anyhow I do not intend to defend that theory.
But one thing I know for sure. With Vista MS is introducing some kind of exclusive mode, which gives you direct access to your outputs to avoid let's call it impact ( and not Jitter/LatencyJitter) by other sources! (Perhaps another marketing trap? Who knows!)
It seems that they are well aware of the related problems.
Back to Linux: I'd call that Vista Exclusive approach realtime process under Unix.
I believe that especially within this area Linux could do a better job.
When it comes to extra jitter on top of the let's call it source data jitter, which is already on your CD, I think it is more than obvious that you'll catch it on the way towards your DAC, starting at the last instance doing some kind of very good buffering/reclocking whatsoever.
Jitter is a non-issue in the digital domain as you have no concept of exact timing. The samples are assumed to be a fixed period apart.
Data jitter and clock jitter are totally irrelevant here.
You can process the samples at 1x or 1,000,000x real time, or even process some, wait for a bit, process some more, wait some more and you won't introduce any jitter.
Jitter only ever comes into play when going between the analogue an digital domains. So long as the DAC has a steady supply of data and a good clock it won't matter how you process the data.
If you can't supply data to the DAC in time or have a noisy DAC clock then you get problems.
RME's article is aimed at people doing multi-track, multi layered recordings from multiple analogue and digital sources. In this case varying latency from the different sources does have an impact.
Data jitter and clock jitter are totally irrelevant here.
You can process the samples at 1x or 1,000,000x real time, or even process some, wait for a bit, process some more, wait some more and you won't introduce any jitter.
Jitter only ever comes into play when going between the analogue an digital domains. So long as the DAC has a steady supply of data and a good clock it won't matter how you process the data.
If you can't supply data to the DAC in time or have a noisy DAC clock then you get problems.
RME's article is aimed at people doing multi-track, multi layered recordings from multiple analogue and digital sources. In this case varying latency from the different sources does have an impact.
Bas Horneman said:
So, what would that implementation look like? Putting a flac file on your usb stick in your pc?
As long as you regard the USB stick as system RAM, just give it a try.
Otherwise.
Either you use full file buffering as it is supplied by foobar
or you install a ramdisc where you copy the track or your full
CD (takes 15s on my PC), for applications not supporting
full file buffering.
These days RAM extensions are quite affordable.
For less than 100$ you get 1GB of quality RAM.
An audio PC IMHO should have anyhow at least 2GB RAM.
I didnt see anything in the RME article which actually says that latency jitter has an impact on normal playback quality, only the triggering of synths and samplers. even when it is discussing synth playback it seems only to be in terms of the delay between, for example, a note played on a midi controller keyboard and the point when the triggered sound is heard. There is no suggestion that the triggered sound itself, albeit later than desired, sounds any worse than if it were played extactly on time. Seems the only unique thing about RME's article is that they use the term 'jitter', as lots of places discuss latency.
If you want to try linux - All the efforts in this area in linux are included in the demudi distribution - specifically a low latency patched kernel (audio given priority) and the harmonisation between this and the JACK low latency audio server (you change latency and sample rate settings with this) which connects the audio output of one programme to another (or the soundcard drivers). these things can be set up in nearly any linux system, but come standard in demudi to avoid difficult set up for those who do not want to get into it. this system is built for audio from the ground up. You can get specific latency figures for this distribution based on your hardware, if you know what you can achieve in xp you can make a direct comparison.
I am going ot try your configuration at some point with ramdisk. ramdisk can be set up in linux easily example
If you want to try linux - All the efforts in this area in linux are included in the demudi distribution - specifically a low latency patched kernel (audio given priority) and the harmonisation between this and the JACK low latency audio server (you change latency and sample rate settings with this) which connects the audio output of one programme to another (or the soundcard drivers). these things can be set up in nearly any linux system, but come standard in demudi to avoid difficult set up for those who do not want to get into it. this system is built for audio from the ground up. You can get specific latency figures for this distribution based on your hardware, if you know what you can achieve in xp you can make a direct comparison.
I am going ot try your configuration at some point with ramdisk. ramdisk can be set up in linux easily example
USB jitter
usb jitter
There's actually quite a bit of stuff over there on usb dacs, a number of chips have been tested.
usb jitter
There's actually quite a bit of stuff over there on usb dacs, a number of chips have been tested.
BlackCatSound said:
I don't agree. What you mess up in the digital domain won't be resolved at a later stage! DAC rule: S..t in = S..t out!
Unless, as mentioned before, you gotta have a very good DAC with a buffer and reclocking stage in front of it!
Further - If that's true what you're saying ouput drivers such as the one from usb-audio.com, which just works in the digital domain, shouldn't have any impact at all!
Again - I am still missing the explanation why changes are happening and are audible, in case where the ouput is considered bit perfect!
BlackCatSound said:
I guess I understood what RME with its article is aiming at.
It is just the principle behind it, that buffer contents due to MS interrupt handling are not read and transfered in a linear way.
I still believe you can map that on the audio-path to a certain extent, especially if regarded as a realtime stream.
Though I really do not have a clue how many times the audio datastream is buffered or catching some other unlinarities before leaving the pc-port.
Of course there are more things to consider, when looking at the PC. Such as power supplys, voltage regulation, noise asf..
I was reading that e.g. while running the harddisc the noise level increases in the system.
Of course something like that and more will have an impact on the data signal.
Bas Horneman said:
It's an option under Preferences-Advanced-FullFileBuffering.
The size is to be entererd in kB. Files bigger than the configured
buffer will not be loaded into RAM.
On a 15min track it'll take some seconds to load. That can be a bit annoying if you play a playlist, where breaks between the tracks
are not really wanted.
In this case it would be better to have a ramdisc.
Countryman said:
Again. The bits are the same, nobody is questioning that!
It's the timing, signal level, noise or God knows what.
My recommendation, just give it a try, listen and report. It doesn't cost you anything more than 30min.
A comment about the gear you got connected would also help to understand the situation.
That'll give us the chance to get behind the issues.
Perhaps the reasons are others than I brought up for discussion,
I don't want to challenge this any longer. I just do not have the in depth knowledge to explain it.
What I won't accept are statements like: It's impossible, there is no difference!
I hope that some folks here will try that on high-end setups and confirm, what myself and some others are enjoying for quite some time.
My personal opinion :
CD is obsolete, and the physical CD itself is fragile and short-lived. Many old CDs that I like are now unplayable.
The other media (SACD, DVDA) have the same problem.
A CD player is inconvenient. You have to separate from your couch to switch CDs. They can only read CDs. They break after a few years.
Arguments for using a computer :
You need a computer anyway to play music purchased on the web.
Amarok media player on linux is incredibly easy to use, fun, and user-friendly. The music library and playlist management is excellent.
It's a lot more convenient than a CD player.
A computer will play any future format (except SACD, but I don't care about SACD).
You can backup your music and use software RAID.
You can easily generate MP3s for listening in the car.
You can store vinyl on harddisks.
On linux versus windows : Once configured, Linux will work until the hardware dies. It just works, period. When I want to listen to music, I don't want to mess with a PC. I want to add tracks to playlist and go.
You can slave the PC to the master clock in your DAC.
A computer can do digital active crossover.
And about FLAC sounding different than WAV : it's like the sound of digital cables or different CD-Rom blanks, or different transports. It just indicates that the DAC has insufficient jitter rejection, ie. it is badly designed.
Any signal generated by a computer (USB, SPDIF from soundcard, etc) will have a lot of jitter. That is to be expected and taken into account into your design. That's why the PC must be slaved to a master clock located right next to the DAC chips.
This is impossible to do with USB, because of the way the protocol is designed.
It is really easy to do with a RME soundcard : add a SPDIF output to your DAC synced on the master clock (a simple chip) outputting digital silence, and plug it into the soundcard input. No need to mess with drivers, the "lock" LED will light, it's done.
The only other way is to use a massive PLL like in the Tent DAC or to use a software controlled PLL VCXO in the DAC.
CD is obsolete, and the physical CD itself is fragile and short-lived. Many old CDs that I like are now unplayable.
The other media (SACD, DVDA) have the same problem.
A CD player is inconvenient. You have to separate from your couch to switch CDs. They can only read CDs. They break after a few years.
Arguments for using a computer :
You need a computer anyway to play music purchased on the web.
Amarok media player on linux is incredibly easy to use, fun, and user-friendly. The music library and playlist management is excellent.
It's a lot more convenient than a CD player.
A computer will play any future format (except SACD, but I don't care about SACD).
You can backup your music and use software RAID.
You can easily generate MP3s for listening in the car.
You can store vinyl on harddisks.
On linux versus windows : Once configured, Linux will work until the hardware dies. It just works, period. When I want to listen to music, I don't want to mess with a PC. I want to add tracks to playlist and go.
You can slave the PC to the master clock in your DAC.
A computer can do digital active crossover.
And about FLAC sounding different than WAV : it's like the sound of digital cables or different CD-Rom blanks, or different transports. It just indicates that the DAC has insufficient jitter rejection, ie. it is badly designed.
Any signal generated by a computer (USB, SPDIF from soundcard, etc) will have a lot of jitter. That is to be expected and taken into account into your design. That's why the PC must be slaved to a master clock located right next to the DAC chips.
This is impossible to do with USB, because of the way the protocol is designed.
It is really easy to do with a RME soundcard : add a SPDIF output to your DAC synced on the master clock (a simple chip) outputting digital silence, and plug it into the soundcard input. No need to mess with drivers, the "lock" LED will light, it's done.
The only other way is to use a massive PLL like in the Tent DAC or to use a software controlled PLL VCXO in the DAC.
Re: USB jitter
Hi Ross.
Another great one. I got the feeling, we're getting there.
Very interesting. First it is quite misleading, buter later on....
It is getting really interesting, starting at post 64, when John Swenson enters the scene!!
If I look at my setup with external 12Mhz Tent clock. Audio
PC running from battery. All kind of noisy stuff as well as
HD drives switched off during playback, playing from RAM.
It seems that I am on the right track here!
Pretty much confirming also that noisy PC environments will
have a jitter impact!
You made my day!
rossco_50 said:
Hi Ross.
Another great one. I got the feeling, we're getting there.
Very interesting. First it is quite misleading, buter later on....
It is getting really interesting, starting at post 64, when John Swenson enters the scene!!
If I look at my setup with external 12Mhz Tent clock. Audio
PC running from battery. All kind of noisy stuff as well as
HD drives switched off during playback, playing from RAM.
It seems that I am on the right track here!
Pretty much confirming also that noisy PC environments will
have a jitter impact!
You made my day!
Re: Re: USB jitter
Got any measurements to show this?
Something to note, motherboards have switching regulators on them to generate the core voltage. Even with the drives off etc.. its still going to be noisy. Really the PSUs are the smallest source of noise on such a large and high speed digital PCB.
But noise like that is easy to overcome.
The jitter from a USB DAC will be from its local clock. Not the data, or the fact its USB. The CM108 simply uses a local 12Mhz xtal to generate all the audio clocks. Not a particularly complex or high quality method.
soundcheck said:
Got any measurements to show this?
Something to note, motherboards have switching regulators on them to generate the core voltage. Even with the drives off etc.. its still going to be noisy. Really the PSUs are the smallest source of noise on such a large and high speed digital PCB.
But noise like that is easy to overcome.
The jitter from a USB DAC will be from its local clock. Not the data, or the fact its USB. The CM108 simply uses a local 12Mhz xtal to generate all the audio clocks. Not a particularly complex or high quality method.
Re: Re: Re: USB jitter
Just picked it up in above mentioned thread.
One thing you'll probably confirm:
The more noisy sources you are able to switch off, the less impact you'll see.
If there are some noisy sources left, you might gonna live with a slightly compromised solution.
\Klaus
BlackCatSound said:
Just picked it up in above mentioned thread.
One thing you'll probably confirm:
The more noisy sources you are able to switch off, the less impact you'll see.
If there are some noisy sources left, you might gonna live with a slightly compromised solution.
\Klaus
I didnt see anything in the thread confirming a way forward to reduce the effects being measured - only that the variations between measurements could possibly be accounted for by the PC hardware. In fact someone (think John swenson) noted that the PC's clock could be seen to be drifting in the measurements. If there is nothing that can be done about that it may conclude that PCs can not be the ultimate solution. Anyone ever replaced a motherboard clock?
On the BD design site, discussions of PC setup for the Twindac (usb) details a listening test where a particular USB pci card made a noticable difference - there seem to be many variables.
What do you think makes the RAM better? is it the solid state nature of the memory or the way it is accessed? if its purely a reduction in mechanical parts, then usb pen drives could be used as a cheaper way of expanding available ram, there are also IDE adpaters for flash cards. Whilst I realise the focus here is on sound quality from a pc rather than the interface, I think if I had to mannually load into ram files a song/ album at a time I'd as well stick to the CD player.
Are you using a laptop soundcheck? or have you some how diy'd a battery supply for your desktop?
On the BD design site, discussions of PC setup for the Twindac (usb) details a listening test where a particular USB pci card made a noticable difference - there seem to be many variables.
What do you think makes the RAM better? is it the solid state nature of the memory or the way it is accessed? if its purely a reduction in mechanical parts, then usb pen drives could be used as a cheaper way of expanding available ram, there are also IDE adpaters for flash cards. Whilst I realise the focus here is on sound quality from a pc rather than the interface, I think if I had to mannually load into ram files a song/ album at a time I'd as well stick to the CD player.
Are you using a laptop soundcheck? or have you some how diy'd a battery supply for your desktop?
I didnt mean to say that it did - Im not sure why it would. It was mentioned though by one of the guys measuring the usb chips - he wasn't categorically stating this either, but had detected changes in measurements at the same frequency over time and suggested that the pc clock may have something to do with it. That the 2706 was some how getting its timing from the clock. far from conclusive. He mentions in a previous post that he is using an external clock, so I am not sure why the chip would be using the pc clock as well, unless he is refering to another setup using the chips own clock which it derives from the pc?
At least this is my interpetation of post #66 by john swenson.
"This looks to me like the computer crystal was slowly drifting (as the garrage warmed up) and the 2706 was following it in 5Hz steps, which sounds a lot to me like a frequency synthesizer with a 5 Hz step size."
He also mentions that other cpu loads, other than audio, and even that physically moving the laptop he was using may account for some of the measured distortion. Which is what I think soundcheck's approach is trying to address, and may have some foundation in.
At least this is my interpetation of post #66 by john swenson.
"This looks to me like the computer crystal was slowly drifting (as the garrage warmed up) and the 2706 was following it in 5Hz steps, which sounds a lot to me like a frequency synthesizer with a 5 Hz step size."
He also mentions that other cpu loads, other than audio, and even that physically moving the laptop he was using may account for some of the measured distortion. Which is what I think soundcheck's approach is trying to address, and may have some foundation in.
rossco_50 said:
1. First of all I was happy that they proved that USB is not at all worse than SPDIF. Considering my other tweaks I feel quite comfortable.
2. I am using a Notebook. IBM (lenovo) Thinkpad T60P
newest core duo).
I read it is a must for PC audio to get the best motherboards,
available.
Quite some people are reporting good behaviour of Thinkpads.
3. I read similar things about the PC clock, being not the best choice for audio purposes.
But I think that's what peufeu is saying, when running your DAC as master-clock and your PC as slave. That would be the prefered solution..
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.