Print

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

[Speed Daemon]

I can't imagine anything is done in a floating point CPU.  The CPU coordinates activity between the DSP's.

I don't know where floating-point came into the discussion, but I'm old enough to remember when the FPU was an option to most computer CPUs. If you're talking about DSP as a noun and not a verb, the DSP unit is just a specialized CPU. A DSP unit may be able to do more complex functions per clock cycle (with the internal bus clock not being the same as the sample rate), but it's still a computer of sorts. The thing that interests me is that some vendors are hard-coding certain algorithms into FPGAs, thus eliminating CPU/DSP cycles.

I would not be surprised if some day you see console software abstracted from the I/O later.  Imagine picking out your dynamics from Waves or another vendor, your favorite I/O box and a human interface of your choice.  To me this is the future.

That seems to be the state of the art now. I read an article on ProSoundWeb about a FOH mixer who's using a pair of WAVES servers to be a virtual effects rack.  After working in IT for some 20 years, I'm not sure how I feel about that from a "points of failure" standpoint, but people are doing it.  There's even a video HOWTO for doing it with an M32.

The interesting thing about the Digico is some folks have written about it's interface being a little latent. Perhaps the presentation layer is underpowered even though it has some awesome DSP horsepower.

That's the nature of the beast. I have some TiVo DVRs that can record 6 channels simultaneously, but the thing I really miss is that instant feedback when I press a button. They could have done a number of things to make the UI the priority, but if it means a dropped frame or a price tag I couldn't afford, then what's the point. I hear the S21 has a bit of UI lag, but look at the price.

I want to again restate that the first vendor who makes the input board some type of removable box so the console can be traditional or use it with a digital connection will have a huge win.  Behringer/Midas, Digico...you listening?

Ever since I tried (and failed) to build a programmable effects box out of a 68000-based computer, I've been having my own pie-in-the-sky dreams about how a digital PA should work. I figured that doing all the processing on-stage and making the "mixer" just a control surface was ideal. I'm seeing that happen now. But when it comes to modularity I'm disappointed. I would like to be able to choose my own mic preamp/input module, and be able to use it with any processing module. And every powered speaker with DSP should take a digital feed. At the very least every brand of digital snake should at least have a card to enable to use it with any other brand of digital mixer. Time will tell.

[Tim McCulloch]

That's my understanding too.  So it only follows that if you give a DSP more samples per second, that increases the load on the DSP, not decreases. Thanks!

The CPU operates at speeds much greater than the sampling rate, as does any off-CPU DSP.  At some point there is an output buffer and final D/A conversion (at the sampling rate).

While we're measuring i/o sampling in kHz, the CPU and DSP are running in the mHz.  DSP can be paralleled to reduce processing latency, but it is generally correct that more processing increases the DSP latency (think:  dynamics, EQ or harmonics processing, from shorter to longer).  Processing creates the *variables* in amount of latency; the amount of latency caused solely by the i/o sample rate is fixed.

Getting stuff in, through and out faster is important mostly for singers using IEMs (the comb filtering resulting from bone conductivity and a digitally mixed IEM signal) and for percussionists and others that are time-sensitive.  Lower total latency helps both types of users; for singers it raises the frequency at which the combing begins.

[Scott Holtzman]

I don't know where floating-point came into the discussion, but I'm old enough to remember when the FPU was an option to most computer CPUs. If you're talking about DSP as a noun and not a verb, the DSP unit is just a specialized CPU. A DSP unit may be able to do more complex functions per clock cycle (with the internal bus clock not being the same as the sample rate), but it's still a computer of sorts. The thing that interests me is that some vendors are hard-coding certain algorithms into FPGAs, thus eliminating CPU/DSP cycles.

When I use the term Floating Point I am talking about doing processing in code on a general purpose CPU that would make use of the floating point instructions but in reality I am referring to the CPU intensive processing in the way recording software works on a PC.  For all intents and purposes the FPU is part of the ALU (arithmatic logic unit) in any modern processing design.

An FPGA is functioning as a dedicated DSP when it is programmed for that function. 

As Tim pointed out insertion of dynamics, eq and effects all have an effect on latency.

For the record I am old enough to have started on 8 bit CPU's and I remember my first audio processing code to decode DTMF in a generic Z-80 simply by sampling the data on a port at regular intervals.  Tone generation same deal.  You used interrupts to service the decoder/generator.  Even on an 8 bit 4Mhz CPU there was still a ton of cycles in between polling the port to take care of other tasks.

[Speed Daemon]

When I use the term Floating Point I am talking about doing processing in code on a general purpose CPU that would make use of the floating point instructions but in reality I am referring to the CPU intensive processing in the way recording software works on a PC.  For all intents and purposes the FPU is part of the ALU (arithmatic logic unit) in any modern processing design.

An FPGA is functioning as a dedicated DSP when it is programmed for that function. 

As Tim pointed out insertion of dynamics, eq and effects all have an effect on latency.

For the record I am old enough to have started on 8 bit CPU's and I remember my first audio processing code to decode DTMF in a generic Z-80 simply by sampling the data on a port at regular intervals.  Tone generation same deal.  You used interrupts to service the decoder/generator.  Even on an 8 bit 4Mhz CPU there was still a ton of cycles in between polling the port to take care of other tasks.

The sad irony is that I can't escape computer science, even in my leisure activities. I'm trying to do this for fun.

One thing that I've noticed about embedded processors in just about every application is that the bean counters always have them using the cheapest crap that they can get away with. That's not a bad thing when you can get so much functionality from a $2000 mixer (I can't remember what my first Soundcraft Series 1 cost, but it had to be more than that). It does make me wonder if this too will pass, or if featuritis will gobble up processing power as it has done elsewhere.

[George Dougherty]

Latency is not really related to sampling rate. Latency is the time taken for the signal to be processed by the DSP. The DSP takes a number of sample rate cycles to do its processing, but its speed is determined by its clock, which is running much faster than the sample rate, typically 10s of MHz.

Actually, unless DSP based hardware works drastically different from computer audio processing, samples are collected into buffer sets rather than individual samples.  The speed of the DSP determines the amount of work that can be done on a sample buffer set, but the size of the set and the number of sets held in memory during processing and routing determines the latency. 
The speed of the DSP will also impact how small that buffer size can be, but it still comes down to a finite set of samples that represent fractions of a second. 96K with modern DSP allows for lower latency times because the fraction of a second being represented is half that of 48K.  You can still make the two equal though.  Sixteen 48K samples are equal to thirty two 96K samples.

[George Dougherty]

That's my understanding, that the processing is what drives latency.  We can put garbage in and out at any given rate as long as it's not processed.  But start doing math on it, and that's where latency happens, is it not?

Any time it's handled and passed off digitally you add latency.  There's latency in the chips that take an input stream and pass it off to another step, such as throwing it onto a network audio stream like DANTE, or sending it out an AES/EBU port.  It's a bit of a combination on the math side though and yes it takes time to do latency and the time you need to complete it will determine how many samples you can work on at one time.  All things being equal though, 96K gives you smaller slices of time to work with and thus the potential for lower latency since in many cases the number of samples dealt with is fixed.  Many pieces of audio hardware have lower latency at higher sample rates because n samples at 96K is half the time of n samples at 48K.

[George Dougherty]

If you want to look at a possible modular type approach, something like AMP might make that a reality.  The mixer logic is handled in a computer and there's now a Dante PCIe based option where you can utilize whatever Preamps you'd like.  Apparently the Yamaha TIO boxes are now usable in channel counts up to 128 (not being limited by the TF console hardware) and AMP will remote control the preamps.

ampmix.net is the home of the project.  Similar concept to SAC but much better implemented.

[Speed Daemon]

Any time it's handled and passed off digitally you add latency.  There's latency in the chips that take an input stream and pass it off to another step, such as throwing it onto a network audio stream like DANTE, or sending it out an AES/EBU port.  It's a bit of a combination on the math side though and yes it takes time to do latency and the time you need to complete it will determine how many samples you can work on at one time.  All things being equal though, 96K gives you smaller slices of time to work with and thus the potential for lower latency since in many cases the number of samples dealt with is fixed.

The problem there is that the number of samples is not fixed, it's doubled compared to 48 kHz.  All things being equal, that means twice the work for the processing engine, not half.

The latency here is not the time between samples, it's the time it takes to perform all of the mathematical functions on all of the inputs, and put it back out. This is one reason why early digital PA consoles don't all operate at 192 kHz by 24 bits, because more input means more work, and more work adds latency and/or cost.

Eventually technology will progress to the point that Hi-Rez sample rates will be commonplace even for live sound mixing, but it will be to brag about having bigger numbers, not some imagined technical benefit. If you're doing a FOH mix and sending your inputs to a recorder, then Hi-Rez is desirable. But if you're just doing a FOH mix, you gain nothing by upping the sample rate above 48 kHz.

[Jeff Simpson]

The problem there is that the number of samples is not fixed, it's doubled compared to 48 kHz.  All things being equal, that means twice the work for the processing engine, not half.

When using dedicated DSP (as opposed to an x86 type platform that I don't know much about), no matter how many channels or what the sampling rate, any particular processing block must complete in one sample period. If this was not the case, the processing block would end up with a bigger and bigger backlog of samples to process, with no chance of ever catching up. You could try to implement some sort of interleaved processing, where two DSPs would alternate taking two sample periods to process every alternate sample. However, since this would involve doubling the number of DSPs, it is much easier to deploy this extra hardware by halving the number of channels each DSP has to deal with, and going back to having everything take one sample period. For example, let's say my DSP can cope with processing 4 input channels at 48 kHz; if I want to move to 96 kHz, the easiest approach is to add another DSP, and have each process only 2 channels.

With this in mind, I have a hard time imagining a system where doubling the sample rate does not halve the time taken by a processing element. My experience is that system latency is dominated by conversion time, and by moving audio between things, be it between DSPs and other chips, or between units connected via a digital snake.

[Speed Daemon]

With this in mind, I have a hard time imagining a system where doubling the sample rate does not halve the time taken by a processing element.

Yes, this seems to be a prevalent misunderstanding, thinking that the output of a digital mixer is isosynchronous with the input, just like with analog. While that would be very nice indeed, there are a variety of technical realities that prevent that from ever happening with serialized pulse code data.

When it comes to sample rates, it's simple: all else being the same, doubling the sample rate does double the rate of "garbage in" and therefore doubles the load to the part that processes the input to produce an output.  Double is always double and never half.  (If we want to get into the finer points of A/D conversion we could have quite an argument, but none of the consoles mentioned aren't doing anything unusual there.)

Yes, you can throw more processing hardware at the doubled bit rate, be it a microcontroller system or hard-wired logic. But the result is that the buyer is paying more for the hardware needed to handle more input. If cost is no object, we all would have the state of the art, of course.  But in the spirit of the original question, I still don't see any real-world benefit in doubling the sample rate for sound reinforcement.

I'd expect the golden eared crowd to claim sonic advantages of higher sample rates, but this is the first time I've ever seen someone say that more samples means less latency. That does not compute. Again, if I'm missing something, please help me out.

[ProSoundWeb Community]