R/E/P Community

Please login or register.

Login with username, password and session length
Advanced search  

Pages: 1 [2]  All   Go Down

Author Topic: Latency of Lavry Blue AD/DA  (Read 11008 times)

danlavry

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 997
Re: Latency of Lavry Blue AD/DA
« Reply #15 on: November 07, 2004, 08:54:35 PM »

I think I demonstrated it cost you more in processing power. I did not say that you need to have twice the word length. 2 more bits can be undesirable. A lot of people are arguing about the difference between a floating 24 bits wit 8 bits for mantissa vs. 26 bits with 6 bit mantissa.

The point is: going faster costs a lot more processing. Check around and see what happens to a system operating at say 48KH, 96KHz, 192KHz. Often, even with expansive accelerator cards, you lose as much as 1/2 the channels at 192KHz.

My point was: it is not the same computation faster. It is a lot more computation to start with, then on top of it it needs to be faster, and also with some penalty in word length. There are better examples for word length. Mine was just a quick one to demonstrate a point. I believe it did.

BR
Dan Lavry
Logged

Andy Peters

  • Hero Member
  • *****
  • Offline Offline
  • Posts: 1124
Re: Latency of Lavry Blue AD/DA
« Reply #16 on: November 08, 2004, 01:07:45 PM »

danlavry wrote on Sun, 07 November 2004 18:54

I did not say that you need to have twice the word length. 2 more bits can be undesirable. A lot of people are arguing about the difference between a floating 24 bits wit 8 bits for mantissa vs. 26 bits with 6 bit mantissa.


Understood, although I think the memory and processing-time requirements are more limiting than accumulator widths, as one can use any arbitrary width.  Of course, exceeding what's available in hardware is doable but ugly in terms of processing time and data access.  I mean, an 8-bit 8051 is perfectly capable of doing 32-bit floating-point arithmetic if you wanna wait that long.

Quote:

The point is: going faster costs a lot more processing.


I agree with you!  That's basically what I said in my 18 Oct post: double the sampling frequency and you double the storage requirements and halve the time available to do the processing for each sample.

But that was of course oversimplifed because as you correctly point out, in order to achieve the same filter response at the higher sampling frequency, you need more taps.

I guess all I was really asking is why you need wider words when moving to higher sampling frequencies.  Now I understand what you were saying.

-a

(Edit: fix typos and add conclusion!)
Logged
"On the Internet, nobody can hear you mix a band."
Pages: 1 [2]  All   Go Up
 

Site Hosted By Ashdown Technologies, Inc.

Page created in 0.035 seconds with 16 queries.