darrylfunk
Banned
keith,
i'm not sure that is the idea of asio drivers....coming from where they do!!!
i'm not sure that is the idea of asio drivers....coming from where they do!!!
MDAC first listen thread
- Thread starter Interzone
- Start date
- Status
darrylfunk
Banned
cheers,
doesn't asio do more than just bypass the kernel though....surely it must have some other functions....?!
i use steinberg gear in my studio setup at home and have done for years so i am conversant in the asio driver setup.
Not really, no. It achieves its primary goal of low latency by simplifying what it does, not adding to it! There's quite a good piece on Wikipedia.
darrylfunk
Banned
does it deal with sample rate conversion like the kernel mixer?
darrylfunk
Banned
how does it play different simultaneous bitstreams of varying bitdepth and carrier freq?
also if it is bi directional how does it send the data to keep everything together?....cheers if you can give me any info....
also if it is bi directional how does it send the data to keep everything together?....cheers if you can give me any info....
Any processing required to play streams of differing parameters would be handled internally within the application in use. ASIO itself is quite simplistic. It is bidirectional insofar as you can use audio inputs and outputs simultaneously, provided the application (and audio hardware) support such a thing.
If you can provide more insight into exactly what you mean by "keeping everything together" I will attempt to explain, as far as i am able.
Paul R
pfm Member
Mixing and sample rate conversion is delegated to the application.
Input and output are synchronous. The driver calls the application to say 'buffer swap' and this applies to all open channels, whether input or output. The driver supplies a method to determine latency, which an application can use to synchronise recordings.
The API is protected by a form of NDA, although you can agree to it online. Source code cannot be 'open'.
I wrote a small app to do stereo 'raw' recordings, it's a better choice for many cards since the ASIO drivers are rather more stable than the interfaces exposed to Windows. And my TASCAM USB interface has no Windows drivers for recording.
Paul
Input and output are synchronous. The driver calls the application to say 'buffer swap' and this applies to all open channels, whether input or output. The driver supplies a method to determine latency, which an application can use to synchronise recordings.
The API is protected by a form of NDA, although you can agree to it online. Source code cannot be 'open'.
I wrote a small app to do stereo 'raw' recordings, it's a better choice for many cards since the ASIO drivers are rather more stable than the interfaces exposed to Windows. And my TASCAM USB interface has no Windows drivers for recording.
Paul
darrylfunk
Banned
i'm just wondering how usb can be so criticised by some as properly set up i can do bit perfect recordings with asio drivers!!! how much in jitter results can asynchronous improve on a system that can make bit perfect recordings.
still curious, cheers.
paul , what tascam are you using? i had terrible driver problems with one of their usb interfaces....got rid in the end....
still curious, cheers.
paul , what tascam are you using? i had terrible driver problems with one of their usb interfaces....got rid in the end....
The problem with 'normal' USB for playback is that, like SPDIF, the receiver must attempt to synchronize its clock to that of the sender in order to avoid long term over or under-runs. As USB data arrives in packets that bear no resemblance to the originating clock rate, this can be a singularly tricky task.
Recording via USB is simpler as the recording device acts, in effect, like a huge buffer - thus eliminating all source jitter at the expense of massive latency!
Recording via USB is simpler as the recording device acts, in effect, like a huge buffer - thus eliminating all source jitter at the expense of massive latency!
darrylfunk
Banned
plutox, did you read the clock tests from sound on sound magazine?
darrylfunk
Banned
i'll find the link for you it's fascinating.
clocks , clocks and more clocks.....
here you go.....
http://www.soundonsound.com/sos/jun10/articles/masterclocks.htm
clocks , clocks and more clocks.....
here you go.....
http://www.soundonsound.com/sos/jun10/articles/masterclocks.htm
Most domestic installations do not require a dedicated clock. The internal clock within the MDAC seems fine to me, and the whole point of feeding such a device via asynchronous USB is that you allow that decent clock to do what it does best, without the need to bend to the will of some dubious source clock.
It's interesting to note that in that SoS test, most of the devices performed better on their internal clocks. Clock locking is NOT normally something you ought to get involved in unless you really HAVE to - i.e. you have the need to lock MANY different devices together. The mere need to connect one device to another does not justify the need to clock lock anything, in my view.
It's interesting to note that in that SoS test, most of the devices performed better on their internal clocks. Clock locking is NOT normally something you ought to get involved in unless you really HAVE to - i.e. you have the need to lock MANY different devices together. The mere need to connect one device to another does not justify the need to clock lock anything, in my view.
Cereal Killer
432
SPDIF is just fine. USB will be surpassed by the next big thing - IMHO 
ASIO/bit perfect are about sample resolution/the value within each data word, and ensuring that the digital values are not being adjusted by any process/software between the raw data source (eg. flac file, cd) and output device (eg. usb or spdif)
Jitter is about timing variations between samples/words and not about the value of the sample/word. Async usb is about controlling timing ie. jitter
ASIO/bit perfect and jitter are not the same thing
Master clocks in the record process (A->D) don't necessarily have the same effect/control as a master clock on replay (DAC).
Using a master clock in replay (DAC) we only really care about the lack of jitter within the final DAC. The source device can have jitter, because we're no longer reliant on the precise timing of each (bit (or word)) clock edge. We read the data when it's known to be stable thus removing the artefacts of jitter in the source data stream, and leaving only any jitter present within the DAC itself.
...and that's the problem with a master clock in the ADC process.
Although the master clock itself may be precise and stable, there may still be sources of jitter (noise which produces timing errors) between the external clock input and the clock as seen by the ADC chip. There may also be amplitude errors in the converted ADC value as a result of noise/distortion within the ADC - these amplitude variations cannot be rectified/improved by a master clock.
Jitter is about timing variations between samples/words and not about the value of the sample/word. Async usb is about controlling timing ie. jitter
ASIO/bit perfect and jitter are not the same thing
Master clocks in the record process (A->D) don't necessarily have the same effect/control as a master clock on replay (DAC).
Using a master clock in replay (DAC) we only really care about the lack of jitter within the final DAC. The source device can have jitter, because we're no longer reliant on the precise timing of each (bit (or word)) clock edge. We read the data when it's known to be stable thus removing the artefacts of jitter in the source data stream, and leaving only any jitter present within the DAC itself.
...and that's the problem with a master clock in the ADC process.
Although the master clock itself may be precise and stable, there may still be sources of jitter (noise which produces timing errors) between the external clock input and the clock as seen by the ADC chip. There may also be amplitude errors in the converted ADC value as a result of noise/distortion within the ADC - these amplitude variations cannot be rectified/improved by a master clock.
darrylfunk
Banned
good explanation....i still feel that jitter is not the holy grail of good digital as i have heard some nasty sounding digital gear with ultra low jitter so it can't be the only unique selling point even if people would want it to be.....
darrylfunk
Banned
i agree, i'm still a bit suspicious of people fixating on low jitter.
saying that john's dacs have always been good sounding devices.....
Paul R
pfm Member
The issue with isochronous USB is that the data rate is locked to the USB frame clock, I think this is at 8kHz. For 44100 this obviously requires frames of differing lengths. Anyway a DAC has to run at a rate closely locked to the frame rate of the particular USB bus it is attached to.
Acquiring from an ADC or S/PDIF input is much easier, everytime the bus polls the ADC it sends what data it has collected since the last poll, there is no lock between the computer bus and the sample clock.
It's a USB-144/2. Seems pretty stable, but I have to use ASIO to record from it at 96k/24.
Paul
- Status