Audio sampling and compression

human

I've been playing with the 'Microphone to Headphones' object recently. (http://obex.parallax.com/object/79)

I'm trying to take 8000 samples per second, compress and decompress them again using A-law, and play back the audio.
The A-lawed audio sounds pretty noisy. I'm pretty sure that my A-law implementation is working as intended. To double-check, I've piped the raw audio samples to my laptop in order to compress and decompress them using 'sox'. The result of this sounds noisy, too.

As my understanding of electronics is very limited, I'm wondering what exactly the 'Microphone to Headphones' object does.
Does it return straight PCM samples? Are they suited to being used as input to A-law without further processing?

Thank you!

Mike Green

The Propeller was not designed to work as a high resolution / high quality ADC. You didn't say what board you're using, but I don't think any of them were optimized for that usage. Ideally, you want to use I/O pins that are not adjacent for the ADC otherwise there can be some coupling between them. I don't remember the other suggestions made in the past. For a microphone to headphone demo, you won't notice the noise. Add a compressor and it becomes obvious. Best solution would be to use a high quality external ADC and careful PCB design around the audio input circuitry.

If you want to use just the Propeller, don't use adjacent I/O pins for the ADC function (you'll have to modify the program to match).

The was a thread long ago on an open-source guitar special effects box using the Propeller. Some of these issues came up there and were addressed in the design.

The "Microphone to Headphones" object / demo repeatedly digitizes the signal from the board's microphone ... at a fixed rate ... and leaves the digital value where another cog can convert that back to analog using PWM (and an analog filter).

human

Thanks for your reply Mike.

I'm using the Propeller Demo Board, so the pins are identical to those used in the microphone to headphones object (8,9).

Mike Green wrote: »

For a microphone to headphone demo, you won't notice the noise. Add a compressor and it becomes obvious.

So if I understood correctly, you're saying it's normal behavior that on the Demo Board, the microphone to headphone object (that just plays back the audio signal it just digitized) sounds fine, while compressing and decompressing the audio signal in between recording and playing back necessarily leads to significant noise?

The code I'm writing is a proof-of-concept, so a little noise is probably acceptable. I just want to make sure it's caused by the hardware so it's not the software's fault.

T Chap

Using compression inherently increases noise. You can consider some methods to duck/reduce/gate the noise during the time there is no audio present which will mean the time where there is the highest levels of noise. Although you cannot use the Prop to manage high quality audio and simultaneously attempt to modify the stream, you could easily add compression on the front end before the AD and use the counters in PASM to using a DA to control the levels of the VCA. You might miss some very fast transients but for many applications ie vocals it would work fine.

http://www.thatcorp.com/2181-series_Trimmable_Blackmer_IC_Voltage-Controlled_Amplifiers.shtml

Mike Green

What I'm saying is that there's some digitization noise in the analog to digital conversion process that's essentially inaudible when converted back to sound through headphones. Some of this noise is due to the lack of optimization in the Propeller's design and in the Demo Board's design for this use. The amount of crosstalk between adjacent Propeller I/O pins, both on chip and in the packaging was not appreciated until well after the design was done. It can be avoided by careful design.

There's a little noise inherent in the successive approximation ADC technique used and in the use of filtered PWM for the DAC technique. If this is a problem after dealing with the above crosstalk, you can always use an external ADC. For the DAC, you can switch to a resistor ladder like what's used for video and VGA or an external DAC.

Phil Pilgrim (PhiPi)

What does the noise sound like? Static? Hum? High-pitched whistles? Under the right circumstances, some noise can be filtered out with either a notch filter or band-pass filter. This filtering can be done in software.

-Phil

Mark_T

Compression does not _inherently_ increase noise, some compression schemes reduce noise
(indeed noise contains a lot of information and compression seeks to throw away information,
throwing away noise is a great way to reduce information content.

Anyway back to the A-law thing - are you converting sample-by-sample without carrying
an error term forwards? It usually better to carry the error forward from sample to sample, as
this leads to more accuracy at low-frequencies.

frank freedman

human wrote: »

I've been playing with the 'Microphone to Headphones' object recently. (http://obex.parallax.com/object/79)

I'm trying to take 8000 samples per second, compress and decompress them again using A-law, and play back the audio.
The A-lawed audio sounds pretty noisy. I'm pretty sure that my A-law implementation is working as intended. To double-check, I've piped the raw audio samples to my laptop in order to compress and decompress them using 'sox'. The result of this sounds noisy, too.

As my understanding of electronics is very limited, I'm wondering what exactly the 'Microphone to Headphones' object does.
Does it return straight PCM samples? Are they suited to being used as input to A-law without further processing?

Thank you!

It may be worth taking your digitized samples and putting them right back out again to see what it sounds like so that you have an idea of the noise level in the raw sample stream. DAC chips can be pricey, but it is easy enough to construct a 12 bit R2R DAC with a good handful of resistors and an op amp. Currently I have a LTC8043 on the breadboard, but I actually liked the results I got a while back with the DIY R2R.

You mentioned your sample rate, but did not say if you had any type of filters on your input. Given the rate of 8ksps, you should have the input filtered to limit at 4khz otherwise if there are any signals of a higher frequency than that, they will be aliased down to below 4khz and will present as additional noise. Also...............

If you are pretty new to this and have limited electronics background, a good book to read on this and more would be "Real Time Programming - Neglected Topics" by Caxton C Foster, copyright 1981. This book offers a good 40k foot overview of sampling and other topics with a few looks below the clouds, and serves as a great guide to where you want to go next in these areas.