Author Topic: (Request for Discussion) Bit Depth and Sampling Rate  (Read 2354 times)

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
(Request for Discussion) Bit Depth and Sampling Rate
« on: April 10, 2014, 05:41:13 PM »
Hi guys,

We are looking for several opinions on which should be the best Bit Depth and Sample Rate to sample the analog levels for the VCA faders and Ultimation on the SSLMixed Computer design. Please justify your reason / theory / math behind your opinion.

What we know is that the SSL used 12 bits for the bit depth and sample rate is unknown so far.

Currently we were thinking to increase the bit depth up to 13 bits to give it a little more detail so we can take advantage of nowadays circuit/chip capacities and low noise. On the other side we didn't want to risk it up to 16 bits afraid that might get the noise level up.

Regarding the sample rate, this is an ongoing doubt and debate. What could be the best sample rate for these types of applications?

Appreciate your help guys,

Artur



Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #1 on: April 11, 2014, 12:44:26 PM »
Hi

Regarding the bit depth, the VCA-only systems used 10 bit converters and the Ultimation systems used 12 bits.

Because of the difficulty in finding 13bit ADC chips we are now thinking on going to 12bits or 14bits chip.

We have a 10v range to deal with on the VCA send/returns:

VCA-Systems: 0-10v
Ultimation-Systems: -5v - 5V

If we use a 12 bits ADC here's the precision we get:

10V/2^12 = 0,00244V = 25 mV

If we use 14 bits ADC here's the precision we get:

10V/2^14 = 0,00061V =~ 0.6 mV

Does anyone knows or can measure what's the noise level of the VCAs? Also, does this noise increase greatly with more channels loaded?

Cheers,

Artur


waltzingbear

  • Full Member
  • ***
  • Posts: 236
  • Karma: +10/-0
    • Portland, Oregon
    • Waltzing Bear Audio
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #2 on: April 11, 2014, 05:34:10 PM »
that's the resolution of the control voltage. Most circuits I recall having seen have at least a low pass filter to dump the hf noise that may get in, You don't need or want anything greater than the fastest rate of change that the fade will change at, that is only potential garbage. Defining that number will give you a better handle on the potential sample rate as well. Zipper noise being the deadly outcome of the wrong choices.

Not sure what you are asking about regarding noise and loading.

Basic information is on the THAT datasheets for the 2151 for most of the circuits actually built by SSL, or 2181 for new revisions that can realistically be implemented.

Cheers,
Alan
Alan Garren
Waltzing Bear Audio

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #3 on: April 11, 2014, 07:27:44 PM »
So you think the best is to keep the 12 bit resolution (original Ultimation and +2 bits for non-ultimation)?

We're trying to get the best balance between accuracy and noise rejection.

Regarding the sampling time we were thinking on start by doing a 500 sample per second, which would cover a 250Hz frequency. This would also serve as a low pass filter around 250Hz.

This might seem to much, but how much detail do we need to cover the fastest fader move from bottom to top (or vice versa) and replicate accurately the move without degrading the VCA voltage curve so much that level changes would start to be heard (like stepped instead of linear).

Do you think it's exaggerated or too little?

Cheers,

Thanks.

Artur
« Last Edit: April 11, 2014, 07:30:33 PM by Artur D'Assumpção »

waltzingbear

  • Full Member
  • ***
  • Posts: 236
  • Karma: +10/-0
    • Portland, Oregon
    • Waltzing Bear Audio
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #4 on: April 12, 2014, 07:53:34 PM »
I don't think!  :-)

What I suggest is to do what used to be called a literature search on the topic. There is published information on these topics (don't reinvent the wheel). Then make sure the new system meets or exceeds these specs.

In other words, I don't know, but I think it is important to know!

Alan

Alan Garren
Waltzing Bear Audio

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #5 on: April 13, 2014, 10:02:46 AM »
Hi Alan,

Well, actually I've trying to look for info on what's the appropriate sample rate for these kinds of applications (faders/VCAs), but it's not easy to find something so specific.
 
I was yesterday discussing this topic with Steve (retrocores) and common sense says we are going over board even with 250 samples per second.

If we go to the visual word (which is really different than the audio), 25 frames per second is enough for our eye to see a linear/fluid flow of the image, instead of stepped. My gut feeling says we should be far from those values, maybe 50 samples per second. This would cover a max 25 Hz frequency on the fader movement, which is a lot if you think about it.

Anyways, since this is a voltage, in one case that drives a motor (ultimation) on the other only drives the VCA (non-ultimation), I think I will try to search some literature on what's the advisable sampling for voltages or analog motors or something.... that should give me an idea of what's the ball park we should be on.

Cheers,

Artur
« Last Edit: April 13, 2014, 10:40:53 AM by Artur D'Assumpção »

waltzingbear

  • Full Member
  • ***
  • Posts: 236
  • Karma: +10/-0
    • Portland, Oregon
    • Waltzing Bear Audio
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #6 on: April 13, 2014, 09:22:40 PM »
here are a few of the papers I found on the AES website.  moving faders is a good search term.  The ones below inclues Flying Faders, GML, Allison VCA, BBC  and one from Bruce Swedien.

there are other, less obvious resources out there, I think old RE/P's have good info in them, but not as seachable. A lot of the stuff you are looking for is from the 70's and 80's

joining AES reduces the online cost to $5 per paper. If you have a good technical college library available they can often be had thru interlibrary loan for free. 

Flying Faders: A Case Study in Product Development
http://www.aes.org/e-lib/browse.cfm?elib=5692

Design Considerations for an Economic Retrofitable VCA Fader Automation System
http://www.aes.org/e-lib/browse.cfm?elib=4765


The Design and Application of the Necam Computer Aided Mixdown System
http://www.aes.org/e-lib/browse.cfm?elib=3114


A Practical Approach to Recording Studio Automation
http://www.aes.org/e-lib/browse.cfm?elib=1753

Implementation and Evaluation of Autonomous Multi-Track Fader Control
http://www.aes.org/e-lib/browse.cfm?elib=16226

Ergonomic Aspects of Assisted Mixdown Systems
http://www.aes.org/e-lib/browse.cfm?elib=2231


The Evolution of Recording Studio Remix Automation
http://www.aes.org/e-lib/browse.cfm?elib=2231
Alan Garren
Waltzing Bear Audio

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #7 on: April 14, 2014, 12:05:38 AM »
Hi Alan,

I will dig into these articles!

I spend the afternoon reading about the anti-aliasing and reconstruction filters, to apply on the ADC/DAC circuits.

This will be a great addition to validate the design! Thanks so much!! ;)

Cheers,

Artur

waltzingbear

  • Full Member
  • ***
  • Posts: 236
  • Karma: +10/-0
    • Portland, Oregon
    • Waltzing Bear Audio
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #8 on: April 14, 2014, 01:02:12 AM »
as the Fs on this should be fairly low, the filtering could be kept simple and still attenuate things enough to keep from aliasing problems.

or the Fs can be higher and the analog HF pass band restricted enough that simple 2nd order filters would provide reconstruction with enough slew rate to make appropriate fades.

Hopefully the data in the articles noted will give you the time constants needed for good fades.
I think I have read most of those articles, but it was probably 30 years ago.

Cheers
Alan
Alan Garren
Waltzing Bear Audio

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #9 on: April 14, 2014, 10:35:04 AM »
Hi Alan,

Yeah, Steve (retrocores) is figuring out the best filter combination. What's curious is that on the SSL implementation they had a 13kHz lowpass filter, which is much higher than I expected. Makes me wonder why...

I doubt they would be sampling at higher rates, specially because they had only 1 ADC/DAC channel that they multiplexed for all channels.

I'm trying hard to find someone that has a subscription to AES Library so I can ask them to download the articles or if I could buy at the discounted rate. Currently I don't have any access to the articles.

Thanks for all the tips, they are invaluable for our work!

Cheers,

Artur

SSLtech

  • Newbie
  • *
  • Posts: 16
  • Karma: +6/-0
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #10 on: October 30, 2014, 12:45:43 PM »
Just joined, so I know this topic has sat idle for a while, and there may well have been a lot of forward movement..

But for the fader "sampling frequency", I can tell you that having worked pretty extensively on SSL's both sides of the Atlantic the SSL automation stored ONE sample per frame. This is how the automation data was stored, and the software therefore performed ONE fader position scan per frame. The computer had absolutely NO comprehension of any point in time which was between two frame edges, other than assigning it to one frame or the other.

You can demonstrate this easily by creating two sessions at two different frame rates (for maximum difference, I suggest 24fps film and 30fps SMPTE), and striping some tape with both codes. -If you move ALL faders slowly and continuously (so that ALL faders are ALWAYS recording a different value for every single frame) then the 30fps code automation file -for a given length of automation...say five minutes for example- be 25% LARGER than the 24fps session.

If you think about it, on playback, the code reader just sent out "now we're HERE..." messages every time it had clocked a complete frame through its register, and the computer then sent out changes to whichever fader positions it had different values stored for that timecode frame address... then the TC reader sends out its next "Now we're.... HERE!" message, and the computer does this.

So 25fps is all we ever had in the UK. 30fps (plus or minus 0.1%!) is all they ever had in the states, and if nobody ever seemed to complain about it, then it must not have been so slow as to hinder good work.

If you want to go for TC based automation, I would suggest that -since data storage costs are now laughably trivial in comparison- twice-every-frame storage should be more than fast enough to satisfy everyone, but not so large that it just vomits huge amounts of data every time a fader is even looked at by the engineer.

Keith

pascal.verdet

  • Guest
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #11 on: October 31, 2014, 06:10:25 PM »
Hi Keith,
Many thanks for your explanations.
Good

Cheers,
Pascal

Artur D'Assumpção

  • Moderator
  • Hero Member
  • *****
  • Posts: 647
  • Karma: +22/-0
  • Sintra, Portugal
Re: (Request for Discussion) Bit Depth and Sampling Rate
« Reply #12 on: November 04, 2014, 08:34:32 PM »
Hi Keith,

Fiirst of all let me thank you very much for the knowledge sharing. We are very appreciated, your input is very valuable to us. This is what SSLMixed community is all about. We are relying on everyone's help to achieve the best possible solution for this community project and in the end everyone will benefit from it.

Just to update you, it's true there's not much posts updates here in the forum. That's partially my fault because I'm trying to manage the community expectations. We've been working hard during these last 6 months and I believe we will start to be able to show our work soon. We have a private Mailing List and most of the weekly action goes there with many boring and complex detail the community does not want to hear about. We are currently prepping to send the first prototype design to manufacture. A lot of sweat have been put into this so we're crossing fingers to have a winner here! :D

You can see an October update of the project here: http://forum.sslmixed.com/index.php?topic=694.0

Some things have change in the meanwhile, such as box configuration, since now we are confident we'll be able to put 128 I/O in one box only.

We also got back to a modular configuration, but this is only for an internal configuration optimization. There is still no "slotted module" support, and there won't be for pricing reasons.

DISCLAIMER -Now this is going to start to get nerdy

But regarding this topic, thankfully the way we are designing it, both in hardware and software land we've been able to completely decouple the sampling rate issue from the SMPTE rate. This will allow us to mangle with both without having serious system compromise.

I will try to describe the entire process on how we are doing it on our system. To help I also did some diagrams:

On the hardware side we are currently planing to do the initial testings with at least double the max expected SMPTE rate (30fps), which means we will be sampling at least at 60Hz. This will guarantee that we can sample faithfully frequencies up to 30Hz, which i believe is more than suffice to sample fader movement. 

Like you said, if 30Hz where enough back in the days, 60Hz will be awesome. Anyways we can very easily mingle with this value since that this is only a software variable in the micro-controllers.

So the data is sampled by the micro-controller and then sent to the main (brain) computer in realtime through ethernet. - The hardware architecture is a bit more complex but for the sake of simplicity lets assume there's only 1 micro-controller - Actually the micro-controller maintains an internal fader status table so only changes will be effectively sent in an update style saving processing time and Ethernet bandwidth (you can also request full updates).

...when the data reaches the main computer that's where the fun begins:

This data is collected by the main computer and updates an internal fader status table. This table always has the latest known fader state and is updated at the rate that the micro-controller sends it. There's only one status per fader, which means new updates replace the older ones.

Here's a diagram explaining this process:



It's important to mention that at this stage there no SMPTE involvement whatsoever. This sampled data is not synced to SMPTE nor has any relation to it. So you could in fact be sampling at 60Hz and have a SMPTE TC input at 25 fps. 


Once the data is in the main computer it can be synced to the incoming SMPTE signal:

The way we are saving the data will indeed have much more precision than SMPTE gives it, since 40ms (at 25 fps) is not enough precision to accurately record fader movement nuances, specially if complex fader action occurs in between SMPTE frames. For this process we decided to greatly increase incoming SMPTE precision, by demuxing the frames.

Already in software land we are making "SMPTE" subframes/time divisions. We divide it up to 16 subframes giving us a 2.5ms of inter-frame precision (at 25fps). The frame #1 is always synced to the SMPTE frame, the other frames are internally interpolated by the internal computer clock at SMPTE HZ/16. We expect a bit of clock skew but it's marginal as this gets always re-synced on frame 1.

Here's a diagram explaining this process:



Now the way we internally sample the fader data and sync it to SMPTE is by taking a snapshot at each clock sync/tick of the fader status table, which has the most recent fader status the system has received so far. At each SYNC signal we take a full snapshot and each TICK we have an update-only snapshot (only differences are saved).

Here's a diagram explaining this:

[/URL]


With this process we've been able to effectively decouple the TC/SMPTE sync from the sampling frequency. This will allow us to change sampling rate (at the hardware side) and precision values (at the softwareside ) at anytime without having major system breakdowns and having to resort to weird sample conversions. One detail is still true, if you record data at a certain SMPTE rate, you can't play it later at a different rate.

This is all happening in a asynchronous way so it's very fast.


Would love to know your input about this process. Other members are also free to jump in and share their thoughts too since this is the first time I am posting this information! :D
 
Once more thank you very much for your support! :D

Cheers,

Artur