How well is an 8-bits audio?

at 10bit how does it sound?

what you can do is to interpolate the 8bit signal in the cortex to get a

10bit signal (since the DAC is 10bit). It should improve the quality a little bit.

Also you can try to reduce the sampling rate (from 44.1kHz to 22kHz) instead of reducing the resolution of the signal.

And is more or less useless to convert the audio on your computer and test how it sounds with good speakers. It makes much more sense to test the audio with the shitty speaker you want to connect to your system, so you will see (ehm hear) how reducing quality, sampling rate,... affect the sound that comes out from the speaker...

Bye Jack

--
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

Huh? Why convert back to 16 bits?

I'm sure.

I guess it depends on what you mean by "medium-quality".

If you're only using 8-bits, you're probably not going to be happy with a linear encoding. Have you tried something like mu-law or A-law encoding?

You'd probably also be far better off with 16 bits and 22KHz than you will with 8 bits and 44KHz.

But, since you're DAC is 10 bits, maybe you should think about using

10 bit samples?

--
Grant Edwards               grant.b.edwards        Yow! Are we THERE yet? 
                                  at               My MIND is a SUBMARINE!! 
                              gmail.com

What frequency response are you looking for? You can greatly reduce the bit rate by reducing the sample rate. High quality phone calls are just

64 kbps using uLaw or A-law. They use real voice compression to get bit rates of 16 kbps and lower with fairly good reproduction including non-voice signals.

--

Rick

Basically an audio signal requires a finer resolution in low amplitudes than in high amplitudes, therefore a constant step digitizer (as an ADC) is far from optimal. An A-law compressor is basically just a table-based log-shaped translator. The process is the following :

- Use a 16bit source (or a 16-bit ADC)

- Convert the 16 bits to 8 bits using a A-law compressor

- Transmit the 8 bits

- Uncompress the 8 bits to 16 bits

- and send the result to the loudspeaker.

Cheers, Robert Lacoste

In the experiment you cite below, are you driving the speaker with the same electronics in each case? I.e., are you sure the D/AC version isn't introducing distortions that the "original" is not? (How can you reproduce the 16b signal from your 10b D/AC? I.e., the signal path is probably *different* in these two cases)

I suspect the original file has a bit more dynamic range than your

10b (8b?) D/AC can accommodate.

As only *you* can determine what the "adequate' level of fidelity is for your application, start by determining what the "best" signal from your D/AC will be.

Start with a simple waveform that has no amplitude envelope -- something periodic (sine wave). Set the generator to produce a signal that will use almost *all* of your 10b available. See what this sounds like.

If acceptable, try more complex waveforms (varying amplitude envelopes) always seeking to utilize the full 10b available in your D/AC until the dynamic range in your signal introduces too much "crud" for your taste.

Then, try the same signal after running it through a compressor (which will change the character of the sound, to some extent). The goal always being to use the full range of outputs that your D/AC can provide.

If you can create a suitable set of sounds (in a previous post, you suggested you only needed a handful), your next issue will be to sort out how to get variable *gain* without losing bits in your D/AC (or, are you handling gain with a "volume control knob")?

Standard digital telephony uses 8 bit samples at 8 kHz sample rate. However, each 8 bit sample is in fact a floating point representation of 1 sign bit, 3 exponent bits and 4 bit mantissa with either A-law or

When converted to linear (integer) representation, 12 bit DACs are required, so your 10 bit DAC is not very good. Of course, you could oversample it to give 12 effective bits.

In the early days of digital telephony various diode/resistor networks

(1970's) approach was to use a low resolution DAC followed by an op-amp, in which the feedback resistor was switched in by an 8 input analog CMOS switch controlled by the 3 exponent bits of the sample.

These days with plenty of processing power, it would make more sense to store the samples as differential-PCM or some better compression method and use oversampling to get a few extra bits out of the 10 bit linear DAC.

Hi Robert !

I'm sorry but you can't :"Uncompress the 8bits to 16bits" because as

compression process from 16bits linear to 8bits is irreversible.

... Laws compression) are really good but nowadays the speex/opus codec outperforms these, even the G.729 standard.

Habib.

So round-trip the 8 bit file back to 16 bits and look at it.

When I convert a 1 kHZ tone from 16 to 8 and back in CoolEdit96, the noise floor is somewhat audible - on full-range "monitors" ( Tannoy Reveals ) . It's not obvious. It is very much there.

When I do this with dither, it's a lot harder to hear.

Dither randomizes the quantization noise.

It depends.

You may be able to dither it. Look to the options in sox. I think this is spelled "sox... dither ... " from Google searches.

--
Les Cargill

Better and acceptable.

I'll try.

Indeed I learned it's better to sacrifice higher frequencies instead of sample bits.

This is what I'm actually doing.

In order to test the conversion result on PC.

I know, but the 8-bits converted audio is unacceptable, in my opinion.

I will try.

Indeed this is what I've learned.

10 bits values are difficult to manage in a 32-bits MCU. I will waste always 16-bits for a sample. Maybe I can try to pack 10 bits samples together...

Byte 0: LSBits of sample 1 Byte 1: LSBits of sample 2 Byte 2: LSBits of sample 3 Byte 3: LSBits of sample 4 Byte 4: MSBits of samples 1-4 ...

uint16_t s1 = byte[0] + ((byte[4] & 0x03)

to 16-bits again. Of course, the result isn't identical to the source.

I can't afford a complex decoding algorithm on a Cortex-M3 device.

This is what I did and the result is bad. Too much noise.

I tried with dither, but the noise is audible, even if lower.

I think I don't need 12-bits resolution. 10-bits is sufficient for my application. 8-bits no, at least without other tricks (compression, oversampling, and so on).

The conversion is done on a desktop PC and the 8-bits result is played always on the same PC (this is why I convert back to 16-bits wav file).

I think so.

It's ok. The tone is clean and acceptable. No noise is audible. The volume is adequate. 10-bits or 8-bits are ok.

I tried with PowerOn.ogg that is a short dingle used on Samsung Android smartphones when the pone is powered on. You can find it on Internet.

If I convert to 10-bits, it's ok for my application. I also played it on my electronics and it's ok. The problem arises when I convert the audio stream to 8 bits.

I understand the file has a short peak (+/-512 at 10-bits resolution) somewhere in the middle and many other audio effects at a lower volume. This type of sound can't be reproduced well with 8-bits resolution.

Maybe I can try with mu/a-compression.

Which type of compressor? mu/A? Yes, I will try.

Consider trying NICAM - using 8 bits. Every 255 (or other multiple as you like) samples you embed a scaling factor so that there are no saturated samples in the block. Even a pic16 can handle it, because the heavy work is done in the encoding.

quantizer SNR for small signals ; the idea is simple after all. Nevertheless if the *implementation* is based on 14 linear segments tabulated then you can uncompress ... bad idea because the overall SNR will be very surprising ! Believe me.

with an equivalent 12Bits quantizer SNR. Not bad at all.

AAh ! Ok. A while ago I have successfully tested IMA/DVI (which is also a loosy codec) on AVR32 and then ported the code to a CortexM4.

OTH, Habib.

PS : I have no time at the moment but i'm quite sure (no so sure though) that a Cortex M4 can run a speex codec. We'll see.

So with CoolEdit96, I genned an 8 bit, 1kHZ tone @ 8k sampling rate. The noise floor is somewhere between -66dB and -72dB. You can hear it but it's not obnoxious.

That should be good enough. So I don't understand...

I don't think you'll get high fidelity out of a Coretex.

--
Les Cargill

I think the problem isn't with simple tone waveforms that use the full-scale everywhere. The bad effect raises when you use an audio waveform with different levels in different time. If it is simply normalized on the maximum level, most of the audio will be quantized with insufficient bits (less than 8 bits).

This is sure.

I found a simple audio coded, names DDPCM (Dynamic DPCM).

It compresses a 16-bits sequence of samples to 4-bits samples. If the sampling frequency is 8kHz, this means 32kbit/s. It is very simple to decode, because it is based only on lookup tables.

I will give it a try.

Nowadays I think the best audio compression is Opus, implemented in fixed-point. But I don't want to waste so much CPU cycles for audio decoding only in my application.