Scope D/A A/D build

A place to talk about whatever Scope music/gear related stuff you want.

Moderators: valis, garyb

Post Reply
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Scope D/A A/D build

Post by Music Manic »

Could someone tell me more about the PCI soundcard and the A16 and what type of digital conversion process and crystal is used for the clock?
Is it Sigma/Delta?

Also how are DSPs compared to CPUs with regard to processing. I always find Scope has some great sounding outs and the VDat has something different to DAW recordings.
mk_vip
Posts: 39
Joined: Fri Jun 15, 2007 11:09 pm

Re: Scope D/A A/D build

Post by mk_vip »

All 2nd Generation Creamw@re products (Luna2/Pulsar2/Scope + the latest Scope cards + Noah (EX) + A16Ultra and Luna box) feature the ASAHI KASEI AK4524VF stereo codec for both AD and DA conversion.
The clock - X'tal Oscillating circuit.
There is NO difference between DSP and CPU when converting sound with a codec since at this stage DSP/CPU are not involved in this.
There IS a difference in the further processing of sound by algorithms.
VDAT is the best because it is direct recorder (bypassing the ASIO driver).
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Re: Scope D/A A/D build

Post by Music Manic »

mk_vip wrote: Mon Mar 01, 2021 12:24 am All 2nd Generation Creamw@re products (Luna2/Pulsar2/Scope + the latest Scope cards + Noah (EX) + A16Ultra and Luna box) feature the ASAHI KASEI AK4524VF stereo codec for both AD and DA conversion.
The clock - X'tal Oscillating circuit.
There is NO difference between DSP and CPU when converting sound with a codec since at this stage DSP/CPU are not involved in this.
There IS a difference in the further processing of sound by algorithms.
VDAT is the best because it is direct recorder (bypassing the ASIO driver).
Ah great info thanks. So VDat is a type of hard disk recorder. What does ASIO do to the recording process?
User avatar
astroman
Posts: 8406
Joined: Fri Feb 08, 2002 4:00 pm
Location: Germany

Re: Scope D/A A/D build

Post by astroman »

It just shifts digital data between CPU, memory and storage - nothing different from Scope/VDAT.
But it does some numerical scaling and it‘s controlled by the OS...

I also like the older AKM converters of the Pulsar One and in particular those 18/16 bit chips of the blue A16. :)
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Re: Scope D/A A/D build

Post by Music Manic »

astroman wrote: Tue Mar 02, 2021 7:48 pm It just shifts digital data between CPU, memory and storage - nothing different from Scope/VDAT.
But it does some numerical scaling and it‘s controlled by the OS...

I also like the older AKM converters of the Pulsar One and in particular those 18/16 bit chips of the blue A16. :)
So there is a difference in processing audio which gives VDat that special sound.
User avatar
astroman
Posts: 8406
Joined: Fri Feb 08, 2002 4:00 pm
Location: Germany

Re: Scope D/A A/D build

Post by astroman »

I have no idea... just some observation and reasoning. If both systems run perfect, there is no difference.

VDAT is very simple because it operates on pre-allocated files and then simply shifts data to disk.
It‘s the only system (according to my humble experience) that gives the exact same representation of monitored versus final mix output.
Whenever a DAW rendering was part of the process, there was some tiny deviation, but that might well be a level thing.
(0.5 dB difference is a perceivable figure)
With some native plugins I have a significant difference between monitor and rendered audio even on a single track.
In my case it‘s the Zynaptiq plugins (huge CPU/buffer burners), that possibly operate at reduced resolution „live“.

Whatever an Asio host does, is tied much closer to the main OS and since audio isn‘t a realtime task many things might happen on the way.
But I lack any details about it‘s implementation(s) that may vary with host, too.
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Re: Scope D/A A/D build

Post by Music Manic »

I think things must be better now with DAWs but processing definitely can affect things if done incorrectly.
User avatar
valis
Posts: 7306
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: Scope D/A A/D build

Post by valis »

The deviation in the DAW is two fold, first DAWs process in floating point format (aside from saw SAW studio). This means when floating point data is passed to the ASIO driver it will be converted to an integer format, which will vary depending on the ASIO driver used in Scope (Scope specifically has several on offer, check the manual for more information). Most of us use the ASIO2 which is typically going to be 24bit INT.

So, when a 16 or 24bit WAV/AIFF is loaded into a track in your daw, that data is now going to be 32FLT (or 64FLT in Studio1 and Logic and other DAWs that are now processing at this level of precision). When summed into the master bus or to an output, this is also done at the same precision. Then when it is passed to the ASIO driver, unless you're specifically using tools to dither & truncate what is passed is going to be a bit-depth conversion based on truncating the extra precision, based on what Scope ASIO driver you're using.

Some years ago we had many discussions about using the 32bit FLT ASIO driver, but if memory serves Scope still moves data around in many cases in Integer formats (devices are floating point internally but may pass audio data as 32bit INT---again if memory serves. fra77x2 or etc feel free to correct me here).

The other concern with ASIO drivers is of course the fact that you can have buffer underruns, and these can occur for a variety of reasons (PCI bandwidth for Scope PCI cards, the host trying to do too much at once, the host being unable to read disk data due to a busy drive and so on).

In any case, VDAT sidestepped all of this, in an era when people were not yet trusting computers for handling audio data in realtime. By preallocating the area of disk to be written to, you avoid errors in writing audio data to disk (this was mentioned either above here or elsewhere in how efficient this turned out to be). And by staying entirely within Scope, you don't have the DAW's host process competing with other system processes for enough of a time-slice to complete processing, avoiding ASIO errors and host buffer underruns.

"Things" are generally better with DAWs indeed, but conversions still occur and this is not 'bit-transparent' as VDAT was. I don't think that alone is a major issue, and it's worth noting that Scope has dither at various points in its internal processing, TPDF gets added in many plugins on the native side, and so on.
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Re: Scope D/A A/D build

Post by Music Manic »

valis wrote: Wed Mar 03, 2021 8:05 am
So, when a 16 or 24bit WAV/AIFF is loaded into a track in your daw, that data is now going to be 32FLT (or 64FLT in Studio1 and Logic and other DAWs that are now processing at this level of precision). When summed into the master bus or to an output, this is also done at the same precision. Then when it is passed to the ASIO driver, unless you're specifically using tools to dither & truncate what is passed is going to be a bit-depth conversion based on truncating the extra precision, based on what Scope ASIO driver you're using.
The 24 Bit file will only become 32FLT if it’s processed Valis otherwise it will stay 24 Bit.
Also if you use a 16 bit asio driver, will the DAW will truncate the signal at the master out (or asio channels if you use more than 2). That’s important to know.
valis wrote: Wed Mar 03, 2021 8:05 am
Some years ago we had many discussions about using the 32bit FLT ASIO driver, but if memory serves Scope still moves data around in many cases in Integer formats (devices are floating point internally but may pass audio data as 32bit INT---again if memory serves. fra77x2 or etc feel free to correct me here).

The other concern with ASIO drivers is of course the fact that you can have buffer underruns, and these can occur for a variety of reasons (PCI bandwidth for Scope PCI cards, the host trying to do too much at once, the host being unable to read disk data due to a busy drive and so on).

In any case, VDAT sidestepped all of this, in an era when people were not yet trusting computers for handling audio data in realtime. By preallocating the area of disk to be written to, you avoid errors in writing audio data to disk (this was mentioned either above here or elsewhere in how efficient this turned out to be). And by staying entirely within Scope, you don't have the DAW's host process competing with other system processes for enough of a time-slice to complete processing, avoiding ASIO errors and host buffer underruns.
Could you expand on the transfer from DAW to Scope with regards to the signal? Is it just a discrete sample transfer?
Could SSD improve buffer under runs or are they just problems with the O/S?
valis wrote: Wed Mar 03, 2021 8:05 am "Things" are generally better with DAWs indeed, but conversions still occur and this is not 'bit-transparent' as VDAT was. I don't think that alone is a major issue, and it's worth noting that Scope has dither at various points in its internal processing, TPDF gets added in many plugins on the native side, and so on.
I always record stems to VDat before I’m down.
User avatar
valis
Posts: 7306
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: Scope D/A A/D build

Post by valis »

Music Manic wrote: Wed Mar 03, 2021 5:09 pm The 24 Bit file will only become 32FLT if it’s processed Valis otherwise it will stay 24 Bit.
Also if you use a 16 bit asio driver, will the DAW will truncate the signal at the master out (or asio channels if you use more than 2). That’s important to know.
This wasn't true then, many DAWs and soundcard mixers were tested for being bit-transparent. Meaning if everything is left nominal, then does it pass unaltered. RME's fpga implementation was specifically built with this in mind, for instance. When I last checked, Logic introduced minor discontinuities. Now how important that is at ~-140dBf...well go back and read the threads here, on gearslutz and hydrogenadio. :wink: I never concerned myself with 32bit FLT ASIO personally, but it was a big discussion at the time and many people insisted it made huge differences in their output (so do dedicated 'audiphile quality' USB cables for some, it seems).
Music Manic wrote: Wed Mar 03, 2021 5:09 pm Could you expand on the transfer from DAW to Scope with regards to the signal? Is it just a discrete sample transfer?
Could SSD improve buffer under runs or are they just problems with the O/S?
Each DAW is different in how things are implemented, but basically you have your audio buffer which is typically either equal to the ASIO buffersize or some multiple thereof, and then a disk buffer. Let's call the ASIO buffer the 'process' buffer to use Logic's terminology, and then of course the disk buffer. Some time ago it was decided that OSX was better at managing the disk buffer than Logic, and similarly Window's disk subsystems are used on windows. Now I use Logic as a comparison, because it also has a 'mix' buffer, which is considerably larger. This increases efficiency because data can stay on-die and in-cache longer, rather than frequent round trips to feed everything. Steinberg has now added the 'ASIO safety buffer' or whatever they call it, and Samplitude & Sequoia actually had the process/mix buffer before Logic if I recall (very late 90's). I might be wrong on that, but I recall them touting it quite clearly in their marketing while Emagic had a considerably more arcane set of preferences to manage that basically meant the same thing.

Buffers are just memory buckets, as I'm sure you know. Read i/o & disk data in...process...write to the output buffer. If you try to process too much and the buffer can't be fed in time, an ASIO overflow occurs. If you can't read the data in time, again the same thing. A disk buffer may or may not be handled as a critical event, there was a time in Logic when I could simply tell it to keep playing on buffer underrun in the settings, but then you hear awful errors over your speakers.

As for your second question, let's deal with the 'problems with the O/S' part first. The OS tends to be the higher level of resource scheduling, so we can say making sure that all of our drivers and OS tuning being in order attends to this part of the equation, as much as possible at least. Disable background crap that might interrupt processing when resources are critically low, resolve drivers hogging CPU time and so on. You know this from our discussions here and from elsewhere, I'm sure.

But SSD's aren't always faster than spinning hard drives, especially SATA ones. The SATA bus doesn't have the bandwidth for any of these companies to necessitate adding additional controller lanes to those devices, so with limited lanes you have a limited number of chips that can be addressed effectively as well. This is somewhat improved by having very dense NAND now, but the chips that pack a lot on-die also do so by moving well beyond MLC & TLC, to the point where the number of layers in QLC's actual build are now commonly 64L and even 96L. These chips are slooooow. The approach of apportioning out some of the NAND area as 'faster' TLC & MLC (using fewer signalling levels so that the data written to that area is not only more 'robust' but also is faster to write due to the lower precision needed in voltage levels) helps, but that only helps until that area is exhausted to the point where it also needs to go through cleaning cycles before it can be written again. This is of course for writes, but this is where VDAT was mentioned to shine by preallocating, and I'm not sure if an SSD actually improves that (the area you're writing to may have nothing to do with the preallocated blocks on the SSD, as I'm not sure VDAT has been updated to consider any of this?)

In any case, low end SSD's also tend to eschew using any RAM buffer, which further affects performance under sustained conditions. It's not uncommon to find some of the SATA SSD's writing slower than a modern HD when it comes to sustained sequential writes, especially as the queue depth increases. Meaning, many tracks at once from a main DAW process that is running channels as concurrent threads.

NVME drives that are large enough and use good controllers can help, but again depending on the chipset being used you might find dedicated PCIe lanes a challenge. AMD has pushed Intel to relax this somewhat on their consumer chipsets, but both companies still try to push you to the HEDT chipsets if you want to run multiple NVME drives AND many other PCIe lane hogging devices (multiple gpu's and so on).

Anyway NVMe certainly isn't needed for audio users, but it's at least an improvement enough that I can't see building a new machine without using that for the operating system and associated program files etc. In my case a boot NVMe drive backed up by two SSD's tends to work fine, and I use better models (but not necessarily Samsung "Pro" models) for my project folders. And similarly, I have one dedicated to my Library files (kontakt stuff and other large libraries that will be read on the fly). Things are still massively easier than the days when I was managing multiple partitions on SCSI drives to apportion high performance areas versus longterm storage and so on, so I think if you stick with the better models an SSD is just fine.

Best SSDs: February 2021
nebelfuerst
Posts: 478
Joined: Tue Jun 23, 2009 10:55 am

Re: Scope D/A A/D build

Post by nebelfuerst »

Just to add to valis explanation:
I did some benchmarks on SSD concerning writes. The higher the integration of bit (TLC,QLC), the more drop on writes occurs after the "SLC-Cache" is filled. With NVME you see extreme values on short write, which drop to 20MB/sec after 20G written data.
A classic HDD can keep up writing 150MB/sec forever, so a raid with a few of them will outperform most NVME/SSD on large writes.
All my machines use SSD for operation system, but the data is streamed via network to a server with HDD in raid.
There are other reasons for this setup, as my audio never generated data rates, which would reach the order of 10MB/sec.
\\\ *** l 0 v e | X I T E *** ///
User avatar
Bud Weiser
Posts: 2684
Joined: Tue Sep 14, 2010 5:29 am
Location: nowhere land

Re: Scope D/A A/D build

Post by Bud Weiser »

I prefer SATA SSD for OS, NVMe x4 for NI Komplete UCE (and other samples) and standard SATA HDD (WD VelocyRaptor) for audio recording.
I never trusted SSD for tracking !

:)

Bud
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Re: Scope D/A A/D build

Post by Music Manic »

O/S on SSD makes things run faster here. There’s a visible delay on SATA
User avatar
Bud Weiser
Posts: 2684
Joined: Tue Sep 14, 2010 5:29 am
Location: nowhere land

Re: Scope D/A A/D build

Post by Bud Weiser »

Music Manic wrote: Fri Mar 05, 2021 6:07 am O/S on SSD makes things run faster here. There’s a visible delay on SATA
What do you mean ?

There are SSDs w/ SATA600 interface and M.2 NVMe x4 (PCIe interface).

SATA SSD is fast enough for OS and doesn´t hog PCIe bus like M.2 NVMe when used for OS.
I prefer Samsung Pro for OS and Samsung 970 EVO Plus M.2 for sample streaming
I need the fastest for streaming (NI Kontakt p.ex.).
In addition I use another Samsung 850 EVO and Patriot NVMe x2 for data/samples which simply load to RAM (no streaming!)

SATA HDD (10K rpm) is for recording audio tracks.

It´s a very good combination, at least for me,- and I won´t build anything new until I´m urgently forced to use Win10 and newer hardware.
I HATE Win10 for a DAW incl. SCOPE/XITE and see no disadvantage w/ Win7 Pro,- except I cannot use the "latest-greatest" always !

:)

Bud
Music Manic
Posts: 1739
Joined: Wed May 15, 2002 4:00 pm
Contact:

Re: Scope D/A A/D build

Post by Music Manic »

I have two O?S setups. One is on a SATA HDD and the other a SATA SSD. Because I have a few SATA HDD’s I get an Ataport.sys latency due to the read/writes I suppose. I’ll switch off most drives and use just one of the SSD/HDD to compare.
User avatar
valis
Posts: 7306
Joined: Sun Sep 23, 2001 4:00 pm
Location: West Coast USA
Contact:

Re: Scope D/A A/D build

Post by valis »

Everyone has different usage scenarios.

For me however OS loading is important on my graphical workstations. Adobe & Autodesk take ages to load. My aging Mac Pro is still using SATA600 SSD's on SATA2 ports, and things are peachy there. I would get no benefit to sample libraries from NVMe as I make quick work of things when I load them and...turn them into more samples, basically.

When I do video work, even NVMe drives are awful. I still have a machine that has fast & large HD's that are used for heavy writing (as an array), and then I render things down to ProRes on an SSD for realtime editing & color work. This is due to the NVMe running out of spare buffer space, I've found that even though the Pro stuff from Samsung holds up considerably better, it just has more inconsistent performance than a good ole HD array striped & spanned properly.

Anyway, we're talking AD/DA here, not video post work or 3d animation. :)
Post Reply