Memory requirements for a high amount of filters

Hi all,

I am working on the first part of the implementation of a 3D sound 
system in real time and I need to choose a DSP processor. So far I've 
checked that a 16 bit wordlength and fixed point meet my requirements. 
The situation is that I need to store almost 12000 fir filters, of 128th 
length each, as a program data (these filters correspond to head related 
impulse responses with a spatial resolution of 2 degree covering the 
whole sphere). Based on my calculations this needs around 6 MByte of 
memory which looks quite a lot and as far as I know the on-chip memory 
of a typical DSP processor is not that much. I would really appreciate 
some guidelines on how to do it in order to meet the memory requirements 
I need for this implementation.

thanks in advance.

Pablo F: Hoffmann wrote:
> Hi all,
> 
> I am working on the first part of the implementation of a 3D sound 
> system in real time and I need to choose a DSP processor. So far I've 
> checked that a 16 bit wordlength and fixed point meet my requirements. 
> The situation is that I need to store almost 12000 fir filters, of 128th 
> length each, as a program data (these filters correspond to head related 
> impulse responses with a spatial resolution of 2 degree covering the 
> whole sphere). Based on my calculations this needs around 6 MByte of 
> memory which looks quite a lot and as far as I know the on-chip memory 
> of a typical DSP processor is not that much. I would really appreciate 
> some guidelines on how to do it in order to meet the memory requirements 
> I need for this implementation.
> 
> thanks in advance.

ADI's TigerSharc has 24Mbits of on-chip memory, but that's only half of 
what you need (6MBytes*8bits/byte=48Mbits).  You could consider using 
more than one of them in a system.  You'd most likely want more than two 
though, because you'd need room for things other than fir coefs (like 
say... input data and program storage).

Is there a reason you can't use off-chip memory?  The penalty for using 
it isn't *that* heavy, and if you could entertain that idea, many, many 
solutions would be available to you.

-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com          (703) 779-7770
The secret to enjoying your job is to have a hobby that's even worse
   - Calvin's Dad

Pablo F: Hoffmann wrote:
> 
> Hi all,
> 
> I am working on the first part of the implementation of a 3D sound
> system in real time and I need to choose a DSP processor. So far I've
> checked that a 16 bit wordlength and fixed point meet my requirements.
> The situation is that I need to store almost 12000 fir filters, of 128th
> length each, 

Do you find that length 128 FIR's give an effective binaural
simulation?  I didn't.


Bob
-- 

"Things should be described as simply as possible, but no
simpler."

                                             A. Einstein

Pablo F: Hoffmann wrote:

> Hi all,
> 
> I am working on the first part of the implementation of a 3D sound 
> system in real time and I need to choose a DSP processor. So far I've 
> checked that a 16 bit wordlength and fixed point meet my requirements.

16bit fixed-point might be ok to represent an audio signal, but you
need to look at higher bit arithemtic if you want to sustain 16bit
quality.
 
> The situation is that I need to store almost 12000 fir filters, of 128th 
> length each, as a program data (these filters correspond to head related 
> impulse responses with a spatial resolution of 2 degree covering the 
> whole sphere). 

I'm busy with a similar project (memory wise): 25 FIRs with up to
300'000 taps.
The only possibility is to store the coefficients in SDRAM. While this
is a bottle neck, the system is designed to cope by using a large
number of DSPs.

To determine the proper DSP type and the number of DSPs required, you
need to also specify the number of audio streams to be filtered with
the FIRs and the sample rate.

Regards,
Andor

Pablo F: Hoffmann <pfh@acoustics.aau.dk> wrote in news:c083vr$7bt$1
@sunsite.dk:

> Hi all,
> 
> I am working on the first part of the implementation of a 3D sound 
> system in real time and I need to choose a DSP processor. So far I've 
> checked that a 16 bit wordlength and fixed point meet my requirements. 
> The situation is that I need to store almost 12000 fir filters, of 
128th 
> length each, as a program data (these filters correspond to head 
related 
> impulse responses with a spatial resolution of 2 degree covering the 
> whole sphere). Based on my calculations this needs around 6 MByte of 
> memory which looks quite a lot and as far as I know the on-chip memory 
> of a typical DSP processor is not that much. I would really appreciate 
> some guidelines on how to do it in order to meet the memory 
requirements 
> I need for this implementation.
> 
> thanks in advance.

Our dspstak 21161sx has a 2M x 32 bit SDRAM that would be suitable from a 
memory point of view. It is based on the Analog Devices ADSP-21161N DSP.


-- 
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com

Andor wrote:
> Pablo F: Hoffmann wrote:
> 
> 
>>Hi all,
>>
>>I am working on the first part of the implementation of a 3D sound 
>>system in real time and I need to choose a DSP processor. So far I've 
>>checked that a 16 bit wordlength and fixed point meet my requirements.
> 
> 
> 16bit fixed-point might be ok to represent an audio signal, but you
> need to look at higher bit arithemtic if you want to sustain 16bit
> quality.
>  
> 
>>The situation is that I need to store almost 12000 fir filters, of 128th 
>>length each, as a program data (these filters correspond to head related 
>>impulse responses with a spatial resolution of 2 degree covering the 
>>whole sphere). 
> 
> 
> I'm busy with a similar project (memory wise): 25 FIRs with up to
> 300'000 taps.
> The only possibility is to store the coefficients in SDRAM. While this
> is a bottle neck, the system is designed to cope by using a large
> number of DSPs.
> 
> To determine the proper DSP type and the number of DSPs required, you
> need to also specify the number of audio streams to be filtered with
> the FIRs and the sample rate.
> 
> Regards,
> Andor

Ok, Thanks for your comments. Actually what I have to do is filtering a 
single audio signal to a two channel filtered signal ( one for each ear) 
at a frequency rate of 48 kHz. I guess this means that I need to 
complete all the operations per sample at a rate higher than 96 kHz, is 
that right?. Finally the output signal must be delivered through 
headphones.

regards,

Pablo

Pablo F: Hoffmann wrote:
....
> Ok, Thanks for your comments. Actually what I have to do is filtering a 
> single audio signal to a two channel filtered signal ( one for each ear) 
> at a frequency rate of 48 kHz. I guess this means that I need to 
> complete all the operations per sample at a rate higher than 96 kHz, is 
> that right?. 

Yup. Generating two 48kHz output channels from one 48kHz input by
filtering the input with a 128 tap FIR per channel is a really low
processing load. I'm sure already the cheapest 16bit DSPs will
suffice.

Do you want to build your own hardware or are you looking for a DSP
development kit?

Regards,
Andor

Andor wrote:
> Pablo F: Hoffmann wrote:
> ....
> 
>>Ok, Thanks for your comments. Actually what I have to do is filtering a 
>>single audio signal to a two channel filtered signal ( one for each ear) 
>>at a frequency rate of 48 kHz. I guess this means that I need to 
>>complete all the operations per sample at a rate higher than 96 kHz, is 
>>that right?. 
> 
> 
> Yup. Generating two 48kHz output channels from one 48kHz input by
> filtering the input with a 128 tap FIR per channel is a really low
> processing load. I'm sure already the cheapest 16bit DSPs will
> suffice.
> 
> Do you want to build your own hardware or are you looking for a DSP
> development kit?
> 
> Regards,
> Andor
Thanks again for your comments.

My background is in Acoustics so I am not really into build my own 
hardware, I just wanna get a development kit that can satisfy my 
requirements, I was actually thinking something from the TMS320C5000 
DSPs. The thing is that i have to switch between filters depending on 
data received by a head tracker so I can simulate the relative position 
of a sound in space when the user moves his/her head.

regards,

If you change filters based on head rotation, then you will have all the
time in the world to reload a new filter. I would keep the two adjacent
filters (to the left and right) in internal memory, and the rest in some
cheap off-chip EPROM or similar.

Tomas


"Pablo F. Hoffmann" <pfh@acoustics.aau.dk> skrev i meddelandet
news:c0cuij$eff$1@sunsite.dk...
> Andor wrote:
> > Pablo F: Hoffmann wrote:
> > ....
> >
> >>Ok, Thanks for your comments. Actually what I have to do is filtering a
> >>single audio signal to a two channel filtered signal ( one for each ear)
> >>at a frequency rate of 48 kHz. I guess this means that I need to
> >>complete all the operations per sample at a rate higher than 96 kHz, is
> >>that right?.
> >
> >
> > Yup. Generating two 48kHz output channels from one 48kHz input by
> > filtering the input with a 128 tap FIR per channel is a really low
> > processing load. I'm sure already the cheapest 16bit DSPs will
> > suffice.
> >
> > Do you want to build your own hardware or are you looking for a DSP
> > development kit?
> >
> > Regards,
> > Andor
> Thanks again for your comments.
>
> My background is in Acoustics so I am not really into build my own
> hardware, I just wanna get a development kit that can satisfy my
> requirements, I was actually thinking something from the TMS320C5000
> DSPs. The thing is that i have to switch between filters depending on
> data received by a head tracker so I can simulate the relative position
> of a sound in space when the user moves his/her head.
>
> regards,

Tomas Ahrne wrote:
> If you change filters based on head rotation, then you will have all the
> time in the world to reload a new filter. I would keep the two adjacent
> filters (to the left and right) in internal memory, and the rest in some
> cheap off-chip EPROM or similar.

OTOH, if you have all the time in the world (and maybe you don't - I 
dunno), you could consider having the DSP calculate the FIR coefs on the 
fly.


-- 
Jim Thomas            Principal Applications Engineer  Bittware, Inc
jthomas@bittware.com  http://www.bittware.com          (703) 779-7770
I'm a man.  But I can change.  If I have to.  I guess.  - Red Green