On Sat, 23 May 2015 08:28:49 +0200, pozz <pozzugno@gmail.com> wrote:

>
>> But, since you're DAC is 10 bits, maybe you should think about using
>> 10 bit samples?
>
>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) << 8);
>uint16_t s2 = byte[1] + ((byte[4] & 0x0C) << 6);
>uint16_t s3 = byte[2] + ((byte[4] & 0x30) << 4);
>uint16_t s4 = byte[3] + ((byte[4] & 0xC0) << 2);
>...

Put three 10 bit samples into a 32 bit word with just 2 bits lost for
every three samples. 

You could even use the two spare bits as a primitive NICAM as a common
range multiplier for the three samples :-)

In article <mjngg9$74h$1@dont-email.me>, pozzugno@gmail.com says...
> As I stated in a previous post, I'm trying to use an embedded 10-bits 
> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a 
> simple 8-ohm speaker.
> 
> In order to reduce the audio memory space (it must be saved in internal 
> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad 
> results.
> 
> I used sox application to make the conversion of poweron.ogg file (it's 
> a simple audio installed in Samsung Android phones).
> 
>    sox poweron.ogg -b8 -r 44100 poweron_b8.u8
> 
> Now I converted back to 16 bits:
> 
>    sox -b 8 -r 44100 poweron_b8.u8 poweron.wav
> 
> There are a big difference in quality between the original file and the 
> converted file. I can hear a clear background noise.
> 
> I think it's the quantization noise. So my conclusion is: 8-bits audio 
> waveforms can't be used for medium-quality (not hi-fi) music. Do you 
> agree with me?
> 
> Is there something I can do to improve the conversion from 16- to 8-bits?
> 
Use one of the many ADPCM routines.
If you use the 4 bit version, you can pack 2 12 bit samples into one 8 
bit memory location, obviously there are other routines that leave you 
with various bit depth return values, but the one I have used for years 
is a 12 bit result, so I'm a bit partial to it.

pozz wrote:
> Il 23/05/2015 20:52, Les Cargill ha scritto:
>> pozz wrote:
>>> Il 23/05/2015 04:01, Les Cargill ha scritto:
>>>> pozz wrote:
>>>>> As I stated in a previous post, I'm trying to use an embedded 10-bits
>>>>> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a
>>>>> simple 8-ohm speaker.
>>>>>
>>>>> In order to reduce the audio memory space (it must be saved in
>>>>> internal
>>>>> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad
>>>>> results.
>>>>>
>>>>> I used sox application to make the conversion of poweron.ogg file
>>>>> (it's
>>>>> a simple audio installed in Samsung Android phones).
>>>>>
>>>>>    sox poweron.ogg -b8 -r 44100 poweron_b8.u8
>>>>>
>>>>> Now I converted back to 16 bits:
>>>>>
>>>>>    sox -b 8 -r 44100 poweron_b8.u8 poweron.wav
>>>>>
>>>>> There are a big difference in quality between the original file and
>>>>> the
>>>>> converted file. I can hear a clear background noise.
>>>>>
>>>>
>>>> So round-trip the 8 bit file back to 16 bits and look at it.
>>>
>>> This is what I did and the result is bad. Too much noise.
>>>
>>>
>>>> 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.
>>>>
>>>>> I think it's the quantization noise. So my conclusion is: 8-bits audio
>>>>> waveforms can't be used for medium-quality (not hi-fi) music. Do you
>>>>> agree with me?
>>>>>
>>>>
>>>> It depends.
>>>>
>>>>> Is there something I can do to improve the conversion from 16- to
>>>>> 8-bits?
>>>>
>>>> You may be able to dither it. Look to the options in sox. I think this
>>>> is spelled "sox... dither ... " from Google searches.
>>>>
>>>
>>> I tried with dither, but the noise is audible, even if lower.
>>
>> 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 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).
>

I am not sure I believe that :) Singe tones should
show up noise artifacts better. IMO, -66dB should be just fine
for the alleged application.

Let's presume you're using it in a busy pubic space. Room
tone plus the hum of activity should be more than
50-60dB. If you make the beeps 90dB, then the noise
is -20 relative to room tone.

That is not enough to be completely masked, but it's close.

>
>> I don't think you'll get high fidelity out of a Coretex.
>
> This is sure.
>
>

-- 
Les Cargill

Il 22/05/2015 22:18, upsidedown@downunder.com ha scritto:
> On Fri, 22 May 2015 17:04:48 +0200, pozz <pozzugno@gmail.com> wrote:
>
>> As I stated in a previous post, I'm trying to use an embedded 10-bits
>> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a
>> simple 8-ohm speaker.
>>
>> In order to reduce the audio memory space (it must be saved in internal
>> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad
>> results.
>
> 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
> &#4294967295;-law conversion.
>
> 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
> were used to create the A or &#4294967295;-law companding curve. A more modern
> (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.

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

http://www.bitsnbites.eu/?p=170

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.

Il 23/05/2015 20:52, Les Cargill ha scritto:
> pozz wrote:
>> Il 23/05/2015 04:01, Les Cargill ha scritto:
>>> pozz wrote:
>>>> As I stated in a previous post, I'm trying to use an embedded 10-bits
>>>> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a
>>>> simple 8-ohm speaker.
>>>>
>>>> In order to reduce the audio memory space (it must be saved in internal
>>>> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad
>>>> results.
>>>>
>>>> I used sox application to make the conversion of poweron.ogg file (it's
>>>> a simple audio installed in Samsung Android phones).
>>>>
>>>>    sox poweron.ogg -b8 -r 44100 poweron_b8.u8
>>>>
>>>> Now I converted back to 16 bits:
>>>>
>>>>    sox -b 8 -r 44100 poweron_b8.u8 poweron.wav
>>>>
>>>> There are a big difference in quality between the original file and the
>>>> converted file. I can hear a clear background noise.
>>>>
>>>
>>> So round-trip the 8 bit file back to 16 bits and look at it.
>>
>> This is what I did and the result is bad. Too much noise.
>>
>>
>>> 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.
>>>
>>>> I think it's the quantization noise. So my conclusion is: 8-bits audio
>>>> waveforms can't be used for medium-quality (not hi-fi) music. Do you
>>>> agree with me?
>>>>
>>>
>>> It depends.
>>>
>>>> Is there something I can do to improve the conversion from 16- to
>>>> 8-bits?
>>>
>>> You may be able to dither it. Look to the options in sox. I think this
>>> is spelled "sox... dither ... " from Google searches.
>>>
>>
>> I tried with dither, but the noise is audible, even if lower.
>
> 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 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).


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

This is sure.

pozz wrote:
> Il 23/05/2015 04:01, Les Cargill ha scritto:
>> pozz wrote:
>>> As I stated in a previous post, I'm trying to use an embedded 10-bits
>>> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a
>>> simple 8-ohm speaker.
>>>
>>> In order to reduce the audio memory space (it must be saved in internal
>>> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad
>>> results.
>>>
>>> I used sox application to make the conversion of poweron.ogg file (it's
>>> a simple audio installed in Samsung Android phones).
>>>
>>>    sox poweron.ogg -b8 -r 44100 poweron_b8.u8
>>>
>>> Now I converted back to 16 bits:
>>>
>>>    sox -b 8 -r 44100 poweron_b8.u8 poweron.wav
>>>
>>> There are a big difference in quality between the original file and the
>>> converted file. I can hear a clear background noise.
>>>
>>
>> So round-trip the 8 bit file back to 16 bits and look at it.
>
> This is what I did and the result is bad. Too much noise.
>
>
>> 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.
>>
>>> I think it's the quantization noise. So my conclusion is: 8-bits audio
>>> waveforms can't be used for medium-quality (not hi-fi) music. Do you
>>> agree with me?
>>>
>>
>> It depends.
>>
>>> Is there something I can do to improve the conversion from 16- to
>>> 8-bits?
>>
>> You may be able to dither it. Look to the options in sox. I think this
>> is spelled "sox... dither ... " from Google searches.
>>
>
> I tried with dither, but the noise is audible, even if lower.

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

On 23/05/2015 08:33, pozz wrote:
> Il 22/05/2015 23:27, Habib Bouaziz-Viallet ha scritto:
>> On 22/05/2015 18:27, Robert Lacoste wrote:
>>> - 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.
>>
>>
>> Hi Robert !
>>
>> I'm sorry but you can't :"Uncompress the 8bits to 16bits" because as
>> many voice codecs the �/A laws compression is destructive. I mean the
>> compression process from 16bits linear to 8bits is irreversible.
>
> I think �/A compression is lossy, but you can uncompress it and go back
> to 16-bits again. Of course, the result isn't identical to the source.
In math point of view you can't do uncompressing �/A datas to retrieve 
the original signal. The �/A laws are log based in order to improve the 
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.

The original �/A law Coder "transform" a 14Bits linear signal to a 8Bits 
with an equivalent 12Bits quantizer SNR. Not bad at all.
>
>
>> Aside from this you're right the venerable G.711 ... G.726 (A/�, ADPCM
>> .... Laws compression) are really good but nowadays the speex/opus codec
>> outperforms these, even the G.729 standard.
>
> I can't afford a complex decoding algorithm on a Cortex-M3 device.
>
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.

On Saturday, May 23, 2015 at 8:36:07 AM UTC+2, pozz wrote:
> Il 23/05/2015 04:01, Les Cargill ha scritto:
> > pozz wrote:
> >> As I stated in a previous post, I'm trying to use an embedded 10-bits
> >> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a
> >> simple 8-ohm speaker.
> >>
> >> In order to reduce the audio memory space (it must be saved in internal
> >> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad
> >> results.
> >>
> >> I used sox application to make the conversion of poweron.ogg file (it's
> >> a simple audio installed in Samsung Android phones).
> >>
> >>    sox poweron.ogg -b8 -r 44100 poweron_b8.u8
> >>
> >> Now I converted back to 16 bits:
> >>
> >>    sox -b 8 -r 44100 poweron_b8.u8 poweron.wav
> >>
> >> There are a big difference in quality between the original file and the
> >> converted file. I can hear a clear background noise.
> >>
> >
> > So round-trip the 8 bit file back to 16 bits and look at it.
> 
> This is what I did and the result is bad. Too much noise.
> 
> 
> > 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.
> >
> >> I think it's the quantization noise. So my conclusion is: 8-bits audio
> >> waveforms can't be used for medium-quality (not hi-fi) music. Do you
> >> agree with me?
> >>
> >
> > It depends.
> >
> >> Is there something I can do to improve the conversion from 16- to 8-bits?
> >
> > You may be able to dither it. Look to the options in sox. I think this
> > is spelled "sox... dither ... " from Google searches.
> >
> 
> I tried with dither, but the noise is audible, even if lower.

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.

Il 22/05/2015 19:11, Don Y ha scritto:
> On 5/22/2015 8:04 AM, pozz wrote:
>> As I stated in a previous post, I'm trying to use an embedded 10-bits DAC
>> peripheral of a Cortex-M3 MCU to generate some good audio on a simple
>> 8-ohm
>> speaker.
>
> 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)

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).


>> In order to reduce the audio memory space (it must be saved in
>> internal Flash
>> of MCU), I tried to reduce the bit-depth to 8-bits and I had bad results.
>>
>> I used sox application to make the conversion of poweron.ogg file (it's a
>> simple audio installed in Samsung Android phones).
>>
>>    sox poweron.ogg -b8 -r 44100 poweron_b8.u8
>>
>> Now I converted back to 16 bits:
>>
>>    sox -b 8 -r 44100 poweron_b8.u8 poweron.wav
>>
>> There are a big difference in quality between the original file and the
>> converted file. I can hear a clear background noise.
>
> I suspect the original file has a bit more dynamic range than your
> 10b (8b?) D/AC can accommodate.

I think so.


>> I think it's the quantization noise. So my conclusion is: 8-bits audio
>> waveforms can't be used for medium-quality (not hi-fi) music. Do you
>> agree with
>> me?
>>
>> Is there something I can do to improve the conversion from 16- to 8-bits?
>
> 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.

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


> 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.

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.


> 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.

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


> 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")?

Il 22/05/2015 22:18, upsidedown@downunder.com ha scritto:
> On Fri, 22 May 2015 17:04:48 +0200, pozz <pozzugno@gmail.com> wrote:
>
>> As I stated in a previous post, I'm trying to use an embedded 10-bits
>> DAC peripheral of a Cortex-M3 MCU to generate some good audio on a
>> simple 8-ohm speaker.
>>
>> In order to reduce the audio memory space (it must be saved in internal
>> Flash of MCU), I tried to reduce the bit-depth to 8-bits and I had bad
>> results.
>
> 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
> &#4294967295;-law conversion.
>
> 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
> were used to create the A or &#4294967295;-law companding curve. A more modern
> (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.

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).