Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Vincent Kars]

This is a more slippery claim.  I've heard machines where moving the mouse cursor was audible on the sound card, or where CPU or GPU usage caused playback hiccups (especially with USB interfaces).  Hard drives can also cause audible noise on poorly shielded outputs.

Nice post Matt.

There is nothing slippery about this type of claims.
Here we talk about clearly audible artifacts (probably CRS errors/high latency)
Here the bits obviously got mangled or arrive too late.

The intriguing part is where the bits don’t get mangled.
Kill a couple of system services. Yes they do reside in memory, no they don’t do anything at all. How could this improve SQ?

Likewise memory playback.
No head movements during playback so if this affects SQ it is not in the bits but in the timing apartment.

[JimH]

By "slippery", I think Matt may have meant something like elusive or fleeting.  A mouse driver should not be able to affect the sound device driver in any way.  Suggesting that sound could be improved by disabling a mouse driver is misguided at best.

The path of trying to fix other company's driver problems is also a slippery slope, and one I'm not eager to embrace.  That type of problem is one best left to Microsoft.

Spinning down a drive is safe, but pointless, in my opinion.  It can't affect the transmission of bits to a device driver unless there is a flaw in the driver or in the player software.  

Playback from memory is in the same category.

Fiddling with Windows services and other processes is potentially dangerous.  If you think that's an effective approach, I'd urge you to start a software business doing it.

And the "latency" issue is also overblown in my opinion.  You would have to have a ridiculous latency to interrupt the flow of bits to a sound device.  If the driver is well written and the software talking to it is also good, then there is no way that "latency" could cause a problem.   The power of a modern computer makes such issues a distant memory.  

As Matt said, if a machine is using 1/2 a percent of its CPU, it's hard to imagine how anything less could be better.

Sorry, Vincent, to be so blunt.  You're a nice guy and a valuable resource in other respects.

[Alex B]

I would even say that the audio signal does not exist before the first clock device. Everything that resides in MC's output buffer is just bulk data. It does not have any kind of timing. MC can easily keep its output buffer filled regardless of the possibly applied internal processing. Outside MC there is at least one more buffer stage before the data is converted to a timed signal.

In other words, there is no timed flow of the digital audio signal before the clock device creates the timed signal.

Anything that MC does simply cannot cause slight timing errors. Of course, also the flow of the bulk data may be interrupted when something is really not working correctly, but then the audio output will be severely broken.

[Vincent Kars]

Hi Jim

I don’t think you are blunt (this time  )

If you hang around on too many audio forums too long and too often like I do, you will notice that a lot of people do experience problems with playback.

Hearing mouse movements are not uncommon. In fact if I connect my USB DAC to the same internal hub as my Bluetooth mouse, I can hear it the moment I move it.

Likewise drop-outs due to DPC latency are common.
Anti-virus software, bad Wi-Fi drivers (Vista!) hogging the system are common problems.
Mind you, USB audio is a isochronous stream so ‘soft’ real time.

We are doing audio on a multitasking system. By design the delivering of the data in time is not guaranteed. The speed of the CPU might be blistering, the buffer of the audio device is in general small so easily drained.

Here we talk about mangling the bits (CRC errors) or hogging the CPU or the PCI bus to such extend that the data flow is interrupted.
This is not uncommon and clearly audible.

I don’t call this a sound quality issue, it is a system error.

The problem starts when the bits are not mangled.
Playing from a HD or loading the track in memory first won’t alter the bits.
One uses exactly the same data.

As PCM audio is sample + sample rate, obvious we cannot explain this by the bits. They are and will remain the same.

However, audio playback is clock driven.
If you have a SPDIF out, you do have a clock driving the sample rate.
A VCXO is by design voltage controlled. You can’t rule out that spikes on the power modulate the speed of the clock.

Here we might have a plausible technical explanation why e.g. memory playback might have an impact. No I/O is less electrical activity (RFI, EMI, ripples on the power) during playback so less disturbance of the clock.

I won’t say this is true but I do argue that PCM is sample + time step by design.
Both must be right. You can’t explain PCM audio by the bits alone. You need to take the timing in account too.

However I would love to see some measurements, somebody proving that changing system load indeed affects the jitter (the timing).
In a lot of cases (killing idle system processes) I don’t see why this should be the case.

All the best

Vincent

[Vincent Kars]

So the bit I don't understand is that if the Player (MC for example) is just filling a DAC's buffer how can it affect the DAC's output as long as the buffer never unexpectedly empties.  Is there some other communication done between the Player and the DAC on this timing as otherwise I don't get it.  Of course a good sample size ABX test would confirm the effect but I'm interested in the why as well.

In adaptive mode the PC sends a certain amount of data and the DAC has to adapt its speed.
So the clock of the DAC is modulated to run faster or slower.
In async (asynchronous synchronisatieon) the DAC runs ate a fixed speed.
No the amount of data send by the PC is altered to keep the buffer filled.
Async is zero input jitter by design.

One of the few measurements demonstrating this I know is by Jim Lesurf


http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html

[jmone]

I get that this would be important in a Real Time system with no buffer, but say I use an extreme example and have a DAC with a large enough buffer to drop a whole songs worth of PCM data into it...how can the method of filling the buffer matter?  I must be missing a concept.

[Vincent Kars]

Yes if….
Most USB DACs do have a small buffer.
The only one I know having a very big one is an old model by Chord.

In practice isochronous transfer is used (talking USB audio).
This is a (soft) real time stream.
You can compare it with SPDIF where the rate of the stream is the sample rate.
The obvious problem: if you use this mode and have a track of 15 minutes, it will take 15 minutes before the track is fully loaded in the memory of the DAC.
Talk about latency….

http://thewelltemperedcomputer.com/KB/USB.html

[JimH]

USB 2.0 has a nominal speed of 480 Mbits/second and a practical speed of around 25MB/second.  That's enough to transfer a lossless track in under two seconds.   Why would would anyone write a driver that didn't take advantage of this speed?  The speed of USB and of well written drivers is just not an issue in communicating with a DAC.  It's around 100X faster than it needs to be.

http://en.wikipedia.org/wiki/USB#Transfer_rates

[jmone]

Hi Vincent, my example was just taking it to the extreme.  A Buffer just isolates two components to reduce their interdependency (eg on timing) as the PC is adding data to one end of the buffer at the rate it can, and the DAC is taking it from the other end as it needs it.  As long as the PC can keep adding more data in the buffer faster than what the DAC needs at any one time then the two are effectively decoupled.  The DAC never directly talks to the PC, just gets the next packet from the buffer (which has heaps queued up).  I'm still failing to understand how the method a PC uses to fill a buffer impacts how the DAC takes stuff out (also I'm using the term DAC in the widest sense be it the DAC on a soundcard, in a receiver, or a standalone USB "DAC")

[jmone]

I've heard machines where moving the mouse cursor was audible on the sound card, ....

I've got one of these.  Prior to updating the chipset drivers on my Asus P6T motherboard I could easily hear my mouse movements.  It was so bad I actually thought I had a ground loop issue somewhere but lived with it till I got a pair of Axiom Audio's Audiobytes which really exposed the issue.  Updated the drivers and it is gone.  How dodgy is that!

[Vincent Kars]

USB 2.0 has a nominal speed of 480 Mbits/second and a practical speed of around 25MB/second.  That's enough to transfer a lossless track in under two seconds.   Why would would anyone write a driver that didn't take advantage of this speed?  The speed of USB and of well written drivers is just not an issue in communicating with a DAC.  It's around 100X faster than it needs to be.

http://en.wikipedia.org/wiki/USB#Transfer_rates

Hi Jim

USB audio  has become popular because the manufacturer doesn’t have to bother about the PC.
All (Win, OSX, Linux) support USB audio class 1 natively.
OSX and Linux also support USB audio class 2.
So you don’t have to develop a device driver for the PC, you only need a USB receiver at the DAC.

Both USB class 1 and 2 uses isochronous transfer. This is a (quasi) real time stream so the amount of data send (every 1 ns in case of class 1=full speed)  more or less equal the sample rate.

It can be done different e.g. bulk mode but then you are no longer compliant with the USB audio standards. This forces you to develop something of your own and that is a very expensive process.

[Vincent Kars]

Hi Jmone.

You forget one thing, buffer management.
If you have a bi-directional protocol everything is fine.
The sender send a package, the receiver acknowledge it.
The sender sends some more, the receiver starts complaining, sorry my buffer is full.
The receiver expects buffer under run so sends a message to the sender, please send me some more. Etc.

In case of uni-directional protocols things are a bit different.
In case of SPDIF, the sender simply sends. It is up to the receiver to keep up with the send rate and the only way to do so is to slave its speed to the sender.
You might even disconnect the DAC, the sender will simply continue to send.

Adaptive mode USB audio works the same. The PC sends it data regardless of the receiver.
The buffer management in this case is up to the DAC.
If the buffer is drained all the DAC can do is lowering its speed.
If the buffer runs the risk to overflow, all the DAC can do is increasing its speed.

In async mode the DAC runs at a fixed speed. A control loop is setup.
The moment the buffer starts to drain, the PC is told to send more data.
The moment the buffer will overflow, the PC is told to reduce the amount of data.

As a buffer has a finite size and as “clocks” never will be perfectly in sync, you need some kind of buffer management.

[jmone]

So I get that and I'm OK with the various issues that may arise in the Mgt of how to correctly fill a buffer, but I'm still missing the concept on how the method of filling the Buffer can impact how the DAC process the data.  As the buffer is just a queue of data, one process fills it up from one end and the other consumes it from the other so at no point (unless there is an issue) would the two ever met on a single byte of data, the PC and the DAC are decoupled by the buffer.

[JimH]

I'm with jmone on this.  Nice description.

[MrC]

Vincent - I don't believe it works this way.  Smart devices today consume from larger buffers provided by the device driver.  These are typically ring buffers where the buffer is filled, and the device consumes the data on its own, as it needs the data, according to its own clocks and needs.  Devices intelligently post interrupts when their buffers are, for example, half-empty, so that software can keep the larger buffers filled.  They post interrupts when, on input, data is available for the driver to post to the software process.  This is a producer/consumer model, which is very efficient.

For under-runs or over-runs, the system either needs to be overtaxed, underpowered, the driver must be faulty, or there are hardware issues.  None of these is something MC deals with.

In older Windows systems, interrupt management, devices and device drivers where weak at best.  Often audio devices, modems, and mice shared the same interrupt, so faulty drivers could cause problems in other subsystems.

Once a software process posts data to an instance of the open device, the driver and the hardware are in total control - MC is out of the loop.  A process (or thread) will be sleeping and waiting to be woken up when more data can be produced - and there is under normal circumstances, plenty of time in which to provide the subsequent bytes.

[Vincent Kars]

If you play e.g. Redbook, every 1/44100 of a second a sample should be processed by the DAC.
Not at 1/44101, not at 44099 but each time at 1/44100
As you can see in post 12 (the picture) in adaptive mode the DAC runs at +2 for a while and then at -6. So the speed is fluctuating due to the buffer management.
In other words, they are not decoupled.
Playing Redbook properly requires a fixed time step for each cycle.
In case of adaptive mode the time step fluctuates.

[JimH]

If you play e.g. Redbook, every 1/44100 of a second a sample should be processed by the DAC.
Not at 1/44101, not at 44099 but each time at 1/44100

I can see how a DAC could get that wrong, but if it does, how is that at all related to the software on the PC, whose job is only to fill the DAC's buffer by sending more data when it asks for it?

[Vincent Kars]

MrC

I’m afraid USB audio uses isochronous transfer.
It is a uni-directional protocol without retry or guarantee of delivery.
If you think this information is wrong, please guide me to a better one.
http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous

[Vincent Kars]

I can see how a DAC could get that wrong, but if it does, how is that at all related to the software on the PC, whose job is only to fill the DAC's buffer by sending more data when it asks for it?

Jim

The answer is the protocol.
In case of adaptive mode USB or SPDIF, the protocol is uni-directional.
There is no 2 way communication between the sender and the receiver.
The sender simply sends, the receiver can only adapts it speed to the incoming stream.
No software on the PC can directly control the clock of a SPDIF header.
No software on the PC can directly control the rate of adaptive mode USB.
There is some XO somewhere running at a certain speed and has its intrinsic jitter.
That’s the hardware. You can tell it to run at 44.1 or 192 kHz but not to do so with e.g. an intrinsic jitter of 1 ps.

[DarkPenguin]

I can see how a DAC could get that wrong, but if it does, how is that at all related to the software on the PC, whose job is only to fill the DAC's buffer by sending more data when it asks for it?

The dac doesn't ask for it.  It is sent on a schedule.  This isn't a great idea across USB.  This is the great advantage of Async USB.  The driver just sends data on down to the device as the device wants it.

[Alex B]

The isochronous USB audio protocol is indeed a special case. In this case the bulk data hits the first clock already in the PC. However, this is an inherent HW design problem and I don't think a software player can do anything about it. I also don't think reading the played file from a hard drive or any other normal activity can have an effect to the USB clock accuracy (or inaccuracy). As Vincent explained, a way to avoid this problem is to use the asynchronous mode.

IMHO, a good PCI or PCI-E sound card is even better (and usually a lot cheaper) solution than an asynchronous USB DAC device.

[MrC]

I’m afraid USB audio uses isochronous transfer.
It is a uni-directional protocol without retry or guarantee of delivery.
If you think this information is wrong, please guide me to a better one.
http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous

The Windows device driver manages this - not MC.  A program opens an instance to the driver - it does not control the hardware directly.  The separation is roughly like this:

                Process
------------------------------
Windows kernel | Device driver
------------------------------
                Hardware

[jmone]

http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html

Ok - I read the report, and without a doubt there is a measurable difference in the Analog Output created by the DACMagic when feed from a SPDIF Source (Halide Design USB-SPDIF Bridge) and directly from the USB.  The issue with the write up is the assignment of the cause of the issue being the PC over DACMagic itself.  It both cases, the data leaves the PC using USB ports, one goes directly to the DACMagic one to the the Halide Bridge then to the DAC Magic.  Both sources of data leave from the DACMagic on the same path.  Hence the only differences in the processing chain is the Halide Bridge and the SPDIF vs USB interface on the DACMagic.  Given the data leaves the PC in an identical form, method, port etc I'd say the DACMagic is the one with issues in this case.

[Sandy B Ridge]

Discussions about audio transfer to DAC, be it via USB, FireWire, spdif or HDMI always seem to cause polarisation between the 'believers' and 'non believers'. I for one have no specific knowledge of the ins and outs of how specific drivers send out packets of data downstream, but one explanation that I like is as follows. If you send a compressed stream from the source to be decoded by a receiver and you can't hear any White noise then the packets must arrive at the decoder intact. So the fact that I hear perfect audio from my TrueHD blurays with the twinkly light on my amp means that the process of getting high bitrate data over the pipe isn't breaking sweat when sending 'low bitrate' CD PCM at 44.1.

I do realise that this does not take into account of any jitter, but since the compressed TrueHD is of variable bitrate I would assume that the amp was reclocking the output from the decoded buffer otherwise it would be garbled. So the only source of jitter should be the amp (the output from its buffer) and not the source.

When I see 'respected' magazines reviewing HDMI cables and say that one gives better 'saturated' and 'lifelike' images than the other, then I move on.

SBR

[jmone]

It is worth restating the obvious as a few terms seem to get blended together when looking at the chain of events, for playback we are going to need a:

1) File Parser / Source Filter / Splitter (something has to read the file, understand what is in it and start outputting the raw data)
2) Decoder (if needed) to covert the audio format used (such as FLAC, APE etc) into PCM
3) DAC (digital to analog conversion) to convert the PCM into an Analog wave form (this could be a chip on the Motherboard, an outboard DAC device, or your receiver)
4) Amplification to well.... make it louder! (could be an amp, receiver, powered speakers, soundcard)

In between each of these step is a transport layer and all they bring (handshaking, mgt, buffers etc).

In many cases you get to choose what device does what part of the four parts of the chain (and this will then impact the choice of transport layer).  For example, my Yami V3000 can use DLNA over my network to read a MP3 file, decode it, convert it to analog and make my speakers work all in one "box".  Alternatively I could use my HTPC to read the file, decode it to PCM and send over HDMI to my receiver where the A3000 does the DAC and Amplification.  I know that Matt likes to use his HTPC to even do the DAC then output the multi channel analog to an amplifier.  To each their own.

Did I miss something?

[jmone]

Processing:  And this is where we started in other threads.  In addition there is then the topic of various DSP and where they are applied and why.  If I have a look at my setup, I have potential DSP in MC, the Receiver, and believe it or not even my Sub Woofer has DSP processing in it to try to flatten the frequency response down to as low as 12hz.

[jmone]

My Perception Bias on Quality:  We all have one, and I tend to be focused more on working forward from the source and back from the speakers.  

My two top ones are:
Source:  If your collection is MP3's, then the rest is less important as this could be your weakest link
Speakers:  If you make you own in the back shed with bits you got from Radio Shack (I'm looking at you Matt) then it will be pot luck if they are any good (and I don't like your chances).  I'm comfortable with the advice that the speakers should make up 50% of your AV Investment.

Next would be:
DAC:  To me - it seems reasonable DACs are available in modestly priced receivers and even soundcards that I've never felt the need for a dedicated DAC device
Amplification:  Likewise good clean amplification seems to be available in modestly priced receivers unless you had specific sound pressure requirements
DSP:  I'm very happy to apply various DSP effects that for me are on convenience (eg re-sampling) rather than worrying about any impact on quality that I don't think I could hear

Last would be:
Speaker Cables:  Any reasonable priced, reasonable thickness ratio for the length of the run (impedance drop) is fine
Interconnects:  Any reasonable priced digital interconnects are fine

[JimH]

The dac doesn't ask for it.  It is sent on a schedule.  This isn't a great idea across USB.  This is the great advantage of Async USB.  The driver just sends data on down to the device as the device wants it.

You're the expert, Tom.  I will never cross you.

But

A lot of the USB DAC's we play to are using a USB driver made by Gordon Rankin, owner of WavelengthAudio.

[DarkPenguin]

You're the expert, Tom.  I will never cross you.

But

A lot of the USB DAC's we play to are using a USB driver made by Gordon Rankin, owner of WavelengthAudio.

They use async usb.  http://www.usbdacs.com/Concept/Concept.html

Every USB DAC you have ever heard uses Adaptive Mode USB Audio. This means the computer controls the audio transfer rate, and the USB device has to follow along updating the Master Clock (MCLK) every one millisecond. The USB bus runs at 12MHz, which is unrelated to the audio sample rate of any digital audio format (i.e. 44.1K requires a MCLK = 11.2896MHz). Therefore Adaptive Mode USB DACs must derive the critical master audio clock by use of a complex Frequency Synthesizer. Since the computer is handling many tasks at once, the timing of the USB audio transfers has variations. This leads to jitter in the derived clock, which means you are not getting the maximum sonic potential available from computer-based audio.

Now, for the first time ever, Wavelength Audio has developed Asynchronous Mode USB Audio. This means the computer is controlled by the USB DAC. No longer is the tail wagging the dog. Instead, an ultra-low-jitter audio master clock located in the DAC controls the audio transfer rate from the computer. Jitter is reduced by a factor of greater than 100 times! What's more, this is accomplished using the standard USB drivers (Windows or MacIntosh) for easy plug-and-play installation. Now the convenience of computer-based audio is combined with the lowest possible jitter. This breakthrough technology from Wavelength Audio delivers the highest level of sonic performance and a new era in digital audio.

I might be wrong on the data being sent.  It is probably just the clock.

My HRT Music Streamer is also an Async USB device.

[MerlinWerks]

FWIW, I've always liked the explanation HERE, at least wrt usb audio.

[pcstockton]

SOURCE FIRST:
The most important component of your stereo is the source component (i.e. cd player, DAC or record player etc). The quality of the musical signal coming out of this first component defines the ultimate ability of any stereo system. Every other component in the system merely passes on this signal with greater or less accuracy. None can enhance or improve it. Many people believe that cd players are all essentially the same because they are digital and somehow perfect as a result. The same is often thought of MP3 sound files. Nothing could be further from the truth and people are quite impressed when they can easily discern the differences for themselves. A poor Cd player can distort the very fabric of music. Turntables have their own set of requirements to accurately do their transcribing, and tuners must have a quality antenna to make proper music.


Preamp:
The next piece is the pre-amplifier. This component is responsible for volume adjustment, input switching and a gain stage. The importance of this component is often overlooked because its duties seem so mundane, but because the signal it passes is so small, any distortions it introduces are then amplified again by the main amplifier which drives the speakers. The result is a number of musical distortions which are usually blamed on the power amp or the speakers, or the room. A higher quality pre-amp will allow its partnered power amp and speakers to perform much closer to their capabilities. Those looking for more bass or better resolution and will intuitively want bigger, better speakers or a higher quality power amplifier. The demonstration of a higher quality preamp will almost always give them the musical remedy they are looking for. The system will sound clearer, it will image better, the bass will be fuller and tighter, more nuances will be heard in the performance, harmonics will be more faithfully rendered, and leading edges of notes will be more realistically portrayed. All of these improvements from the little box in the middle. Who knew?

Amplifier:
Following faithfully behind the pre-amp is the power amp. Its job is to move the speakers back and forth with control and accuracy while not introducing any noise or distortions to the musical signal it receives from the pre-amp. It must amplify the full bandwidth of 10 octaves with complete linearity. It must not shift phase at any frequency and it must not amplify any harmonics more than others. To do so would distort musicality and leave you with speakers moving back and forth and a room full of sound, but not music.

Speakers:
The last bit of kit is the speakers. Many people believe that the speaker is the most important link in the hi-fi chain. Intuitively this makes sense because it is where the sound comes from. And true enough, if you change in a nicer pair of speakers a very different sound will come forth, but remember that the CD player is the most important component and they can't share that honor. In fact, because the speaker is the only passive device in the chain, in ways it is the least important. That said, speakers are probably the hardest to get right. The speaker's job is to turn that beautifully musical signal coming down the speaker wire into an acoustic event in your room. And there is the rub, in your room. Speakers are extraordinarily room dependant and since every room is different, a speaker simply cannot be designed to work predictably in every room. The larger your listening room, the more bass your speaker will need to produce to properly load that space and keep the bass in balance with the higher frequencies. The tonal balance of the speaker will be affected by things such as furnishings; window treatments; floor, ceiling and wall surfaces; the room shape; building construction methods and materials: and of course the speakers own dispersion pattern. Add to these complications the trend for speakers to become smaller and "invisible" and problems start to really add up for the stereo company who wishes to provide a product that makes music in the home.


This is how I feel about my experience with hifi over the last 20 years.  I think anyone who believe all hifi to be created equal are not listening to music at all.  They are simply hearing sounds.  Just because all McDonald's cheeseburgers taste the same doesn't mean ALL cheese burgers do.  Do yourself a favor and go to your highest end hifi store.  Ask to your hear favorite CD on their lowest end kit.  Then on the best they have.  Does it sound identical to you?  Really?

Clearly on Crazy Pills,
Patrick

[Pjotr]

They use async usb.  http://www.usbdacs.com/Concept/Concept.html

Quite confusing. They claim asynchronous communication but at the same time the use of the standard build-in win/mac/linux drivers and not dedicated drivers tailored to asynchronous communication. Up to my knowledge there are no standard asynchronous drivers available in either OS.

There are some real asynchronous USB Dacs on the market like from E-MU and asynchronous USB --> S/PDIF converters from Musiland and M2Tech. They all come with their own dedicated drivers (and luckily also ASIO drivers )

Any capable programmer should be able to get the data from disk to the drivers without loosing a bit. If not, he/she should left the building If data is not correctly transported that will be clearly heard as annoying noise or drop outs. Not as a change of changing sound colour as claimed by many reviewers.

I have seen/heard many USB dacs and tested some on jitter. There are for sure differences, but all originate from the analogue electronics. And yes jitter has an analogue origin, not a digital if systems are synchronised.

From the testing (using a Julian Dunn 1/4 fs test signal): All standard USB dacs and USB --> S/PDIF converters show notable 1 KHz intermodulation products from the USB 1 KHz sync data (the DAC conversion clock is in the end locked to that 1 kHz sync data). This is completely absent with real asynchronous DAC's that come with their own drivers.

It amazes me every time that many so claimed "Hig-end" (and accordingly priced) DAC's  simply put in a $1 PCM2704 BB chip as the USB receiver. Not a really bad chip but only capable of the default isosynchronous data transfer.

An other major jitter source is power supply noise in the DAC itself. The standard Crystal/Cirrus S/PDIF receivers are quite sensitive to it.

@Vincent Kars

If your mouse interferes with your DAC on the same hub, that's quite possible. The hub has to switch between both endpoints interfering with the exact timing of the 1 Khz sync data. I did not encounter this with asynchronous transfer. (I am using a Musiland USD01 USB --> S/PDIF converter hooked to a netbook playing from a NAS.)

[nwboater]

I still subscribe to "The chain is as strong as it's weakest link".

You could have an incredibly good source but have lousy speakers, or a lousy amp or preamp. You will get lousy sound out.

Some reasonable balance of quality is needed through the entire system.

My two bits worth for today.

Rod

[jmone]

I agree with Rod.  The cost benefit of changing bit of the chain varies enormously.  I can decide to only buy CD's no longer MP3 and while the cost differential is small (if anything) the impact is very noticable.  Likewise pcstockton focus on the source device (eg CD Player) as the "most" important may be relatively a lower investment and hence easier to achieve on a more limited budget than say upgrades to the speakers.

[Vincent Kars]

Quite confusing. They claim asynchronous communication but at the same time the use of the standard build-in win/mac/linux drivers and not dedicated drivers tailored to asynchronous communication. Up to my knowledge there are no standard asynchronous drivers available in either OS.

From the testing (using a Julian Dunn 1/4 fs test signal): All standard USB dacs and USB --> S/PDIF converters show notable 1 KHz intermodulation products from the USB 1 KHz sync data (the DAC conversion clock is in the end locked to that 1 kHz sync data). This is completely absent with real asynchronous DAC's that come with their own drivers.

Hi Pjotr.

I wonder if this correct.
First of all, USB comes standard with 3 different synchronization modes.
Synchronous, Adaptive and Asynchronous.
So async is simple part of the USB specs and all OS are in compliance.
Even the top USB DACs use native mode drivers (at the PC side) except for Win because Win doesn’t have a native mode USB audio class 2 driver.

[Pjotr]

Hello Vincent,

If asynchronous audio transfer is part of the USB standard, there would be standard chips for it and standard drivers for a long time. And no need for M2Tech, Musiland and others to implement their own FPGA's and drivers.

But maybe it is recently added and did I miss it? Can you point me to the applicable official documentation then?

[Vincent Kars]

Hi Pjotr
This is what I know about USB audio: http://thewelltemperedcomputer.com/KB/USB.html
This is the 1997 USB audio class 1 standard: http://www.usb.org/developers/devclass_docs/audio10.pdf
Check page 19
A nice one: http://www.beyondlogic.org/usbnutshell/usb1.shtml
Enjoy

[MerlinWerks]

Quite confusing. They claim asynchronous communication but at the same time the use of the standard build-in win/mac/linux drivers and not dedicated drivers tailored to asynchronous communication. Up to my knowledge there are no standard asynchronous drivers available in either OS.

It amazes me every time that many so claimed "Hig-end" (and accordingly priced) DAC's  simply put in a $1 PCM2704 BB chip as the USB receiver. Not a really bad chip but only capable of the default isosynchronous data transfer.

I believe the bulk of Gordon's R&D work was focused on writing custom firmware for the USB hardware side of things so it would be possible to use the native OS driver's in asynchronous mode. Gordon was one of first to bring to market a successful asynchronous dac, long before Musiland and HiFace and his technology is licensed by quite a few companies. He is the real deal, although I would agree that the prices for his company's gear are too steep for my wallet.

[pluto]

If asynchronous audio transfer is part of the USB standard, there would be standard chips for it and standard drivers for a long time. And no need for M2Tech, Musiland and others to implement their own FPGA's and drivers.

Windows' native drivers will support up to 96kHz sampling rates via USB. Those companies implement their own drivers because they choose to support (in M2Tech's case) up to 384kHz.

[Tolga]

And the "latency" issue is also overblown in my opinion.  You would have to have a ridiculous latency to interrupt the flow of bits to a sound device.  If the driver is well written and the software talking to it is also good, then there is no way that "latency" could cause a problem.   The power of a modern computer makes such issues a distant memory.  

With  years of MC usage and "fan-dom" experience, I started to believe the occasional hickups are still a infrequent but major problem. (one happened a sec ago). Happens more when the disk is not defragged enough etc. Low CPU for player usage is great, but I think playing module can be occasionally blocked by other operations like view updates, podcast download etc.

For using MC in live events, I worked out a solution that works great for me. I installed a separate portable MC; all features turned off, no tag updates, simple views, no podcast etc. I use a regular MC for song selection and the portable simplified MC as the player. I just move song links from one to the other for creating a playing now playlist.

There are some details how to do that successfully and keep both libs in sync (i.e. the player library accesses the main library as a readonly share). But it is OT, clearly, this kind of solution is not for everyone.

My main point is separating the player as a second process is way more reliable than having a single MC with presumably a separate thread for the player. I have no hard data on this but I have thousands of hour using MC regularly and hundreds of hours using MC as two separate processes in live events. The two process model is bullet-proof and if I don't do that, I can get hickups and I would loose sleep over problems that can occur in live events.

So, in my humble opinion, the team should strive for separating the bare bone player boundaries completely from the library.