using fpga for sampling audio

The planned architecture: telephone line -> ADCs (8k samples pre second)-> FPGA (samples into ram) -> AXIS controller (with Ethernet)

The goal is to tap several (about 8) telephone channels and convert them into TCP/IP stream. TCP server will run on Axis controller. I consider to use FPGA for polling ADCs and storing samples into Block RAM. When FPGA buffers are say 50% full, the FPGA would interrupt the controller. AXIS runs at 100MHz. The interrupted controller would address FPGA by address bus and reads all samples from FPGA memory. I think 1 kbyte sample buffer would be enaught for an audio channel.

I'm new to this filed and want to ask whether the architecture choosen is feasible? Which FPGA families suit better for the task?

AXIS is a risk processor; I'm thinking to implement addressing scheme where there is an address for each audio channel. That is, any two sequential reads from the same address would read two sequential samples from FPGA. It it normal solution?

Thanks, any references are highly appretiated!

Reply to
valentin tihomirov
Loading thread data ...

OK, what about control signal bits? Are you using CAS or CCS? Signalling? R2? What does your far-end look like? What type of telephone network do you want to connect to? You may need CCS if your far past the PSTN and in a private network . Is your box going to appear as an FXS and FXO? If so the context of the signal bits are different. Your going to need a ring generator and voltage sources for talk and ring, do you also need cadence control?

I would strongly suggest you look at some of the third generation codec/audio processors out there.

Another issue, regarding buffering is echo - the depth of your buffer affects the impulse response time in an FIR filter. There are Bell Pub. specs for this. Do you want ADPCM?

I developed an FXS and FXO cards with no processor for a drop/insert T1/E1 box as well as a broadband wireless network , with just a Spartan XC2S200, so if you want to go on the cheap (processors take up board space and silicon) let me know. I can tell you that your going to have to clarify you requirements a great deal more.

Reply to
fabbl

I've never designed telephone stuff, but considering the speeds and speech quality requirements I think you can get away with a single A/D and an analog mux at the input. There are some A/D chips with the mux onboard.

runs

and

The things will be a little easier if you use a FIFO structure for storing your data. Perhaps that's what you actually meant.

If what you describe is the only task for this FPGA, then you can use pretty much any FPGA, which has enough RAM. I would probably use something like XC2S50E. On the other hand you could choose Virtex-II Pro and run your TCP stack on the embedded PowerPC...

/Mikhail

--
To reply directly:
matusov at square peg ca
 Click to see the full signature
Reply to
MM

Some references...

Scott Keagy, Integrating Voice and data Networks, Cisco Press, 2000

ANSII / EIA/TIA-464-B-1996, Requirements for Private Branch Exchange (PBX) Switching Equipment.

AT&T PUB 43801, Digital Channel Bank Requirements and Objectives, 1982

R2 Signalling, in case you're interested:

ITU Q.400, Specifications of Signaling System R2: Definitions and Functions of Signals - Forward Line Signaling Equipment, 1993

ITU Q.421, Specifications of Signaling System R2 Line Signaling, Digital

Version - Digital Line Signaling Code, 1993

ITU Q.422, Specifications of Signaling System R2 Line Signaling, Digital Version - Clauses for Exchange Line Signaling Equipment, 1993

ITU Q.440, Specifications of Signaling System R2 Inter-register Signaling - General, 1993

ITU Q.441, Specifications of Signaling System R2 Inter-register Signaling - Signaling Code, 1993

Reply to
fabbl

I'm not sure whether "telephone line" means "globally compliant POTS line" or "something that will connect to a phone across the office".

If it is the former meaning, it is a requirement to support a number of different complex termination impedances. This may be done by changing analog components in the line hybrid, or it may be synthesised digitally (by feeding a filtered version of the ADC signal back to the DAC) with different filter taps for each market. The latency of the ADC & DAC matters a lot! This may rule out a multiplexed approach, and will almost certainly rule out standard "PC" type codecs (which have large latency).

Note that some customers may expect to be able to connect V.90 type modems to what is nominally an audio line. IIRC, this requires at least 14 bits of accuracy prior to mu/A law companding.

There's a large market for phone line connection devices, so it's not all that hard to find codecs designed for the task, e.g. AD73322L

Regards, Allan.

Reply to
Allan Herriman

Nice to see someone trying to use an ETRAX. I had a look at your (employers?) web site and the project looks interesting. Nice move to use the ETRAX MCM. Should make for a small footprint.

For you others reading this it might be somewhat interesting to have a look at

formatting link
to see the ETRAX. And no, I do not work for Axis. (anymore:)

/Ulf Andersson

Reply to
Ulf Andersson

Telephone line is that one where you connect your phone at home and office. FPGAs require an EEPROM; may be CPLD + dual-port RAM buffer is better for the 100MHz interface than one FPGA?

Reply to
valentin tihomirov

What is analog front-end? The datasheet gives idea, this is ADC/DAC device with capability of mixing input and output audio. Datasheet states it can be used in telephony applications indeed. Does it mean the chip can be used as hybrid function (DAA) directly connecting to telephone line Tip and Ring wires? Do we still need PLD to tranfer data to a powerful system for storing or TCP/IP conversion? Thanks.

Reply to
valentin tihomirov

You have 2Mbyte of Flash on the AXIS controller (if it's the one I think it is), and that can be used to hold a compressed FPGA image along with your software. I expect the solution involving the FPGA will be cheaper than the one involving the CPLD.

Regards, Allan.

Reply to
Allan Herriman

Does this mean that you are trying to mimic a telephone, or a telephone exchange? The requirements are very different.

You mention DAA, which implies that you are trying to mimic a telephone, but I suspect that you really meant SLIC, which is the interface to a phone line inside a phone exchange (or PABX, etc.).

BTW, all of this is off-topic for comp.arch.fpga

Regards, Allan.

Reply to
Allan Herriman

I don't know what is SLIC and data protocols between PABX . The requirement is usual telephone line you have at home. DAAs are used to connect to the lines (can be replaced with a transformer). Analogue telephone interface is really off-topic but high-speed capabilities of PLDs are not.

Reply to
valentin tihomirov

requirement

is

Your going to have a hell of a time with this.

PS: A DAA (Data Access Arragment) is *not* a SLIC Subscriber Line Interface Circuit).

Reply to
fabbl

Is this for research, or a product. If product, is cost a concern? Is your heart set on using an FPGA, or would you consider cheaper alternatives even if it means you don't get to play with those neat FPGAs?

Is this for a VoIP system? If so, 512 samples at 8kHz will add 64 mS of latency. I.e., lag would make conversation quality suffer.

If this is for record only/lawful intercept only, it wouldn't matter.

You could probably use 8 dual ported FIFOs and the AXIS reads from these FIFOs could be decoded. E.g., base+0 for ch 0, base+1 for ch 1, etc.

Reply to
William Wallace

This should be a product; thus cost makes sense.

This is not a problem for a recording system.

I was asked for expediency of doing this looking for an efficient way of reading streams from perephriental. Thanks for approving.

Reply to
valentin tihomirov

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.