Voice receiver

On 27 Dec 2004 17:34:30 -0800, "derek" wroth:

Ethernet is not a "deterministic" transmission medium. You can assume that all the data you transmit over ethernet will eventually get to its destination, but you can't assume how long it will take.

I would design in a buffer area at the receiver so that the data can be transmitted a little faster than your 8K BPS and then clocked out to the decoder at a steady rate. Otherwise you may get a lot of "jitter" in the data rate.

Jim

Hi Jim, Hi Derek,

Agree. I suggest to look at how software such as RealPlayer works. It first buffers several seconds of data before releasing the audio path to pipe out in a FiFo manner. This takes care of Ethernet and web latencies. Probably you can get by with much less buffer space if the Ethernet isn't heavily loaded with other traffic.

This is probably not what you want to do but just in case: With balun transformers on both sides it is possible to send audio over the free pairs in a CAT-5 cable.

Regards, Joerg

Actually the ethernet is used in LAN but not internet. So I think the delay is small.

And today I have done an experiment to see whether my old device can afford how much data rate locing. I find that it is only about 8bps. I think this number is quite marginal. I will locate which is the bottleneck and fine tunes the device. The MCU is just 8 bits. :(

Hi Derek,

That's good. Just make sure to test under a worst case scenario, such as when someone else is shoving a huge database file across the LAN.

Maybe you could check out the MSP430? Internally these are 16 bitters. Some versions also have an on-board HW multiplier. There is an application note around somewhere where they used an MSP in a voice signal buffering and storage scheme. That could cut down your coding time. Another app note shows how to make a decent DAC using two timers, one for coarse conversion and the other for adding lots of LSB. That way you get enough bandwidth yet also a high resolution for best audio quality.

Regards, Joerg