Searching \ for '[PIC] 2 pin audio...' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/ios.htm?key=audio
Search entire site for: '2 pin audio...'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 2 pin audio...'
2006\07\06@010204 by Tony Harris

picon face
Hi all,

I know several years ago, I had stumbled on a site about using a pic, a few wires and an eprom module to make sound (2 bit sound w/ capacitors and such that did a decent job of reproducing the sound), but I can't seem to find the link anywhere, and I can't seem to come up with the proper search terms to find it via google.  If anyone has this link, I would really like to read the site again.

Any help would be most appreciated!!

-Tony

2006\07\06@011046 by scott larson

picon face
www.romanblack.com/picsound.htm

On 7/6/06, Tony Harris <spam_OUTkg4wfxTakeThisOuTspamyahoo.com> wrote:
> Hi all,
>
> I know several years ago, I had stumbled on a site about using a pic, a few wires and an eprom module to make sound (2 bit sound w/ capacitors and such that did a decent job of reproducing the sound), but I can't seem to find the link anywhere, and I can't seem to come up with the proper search terms to find it via google.  If anyone has this link, I would really like to read the site again.
>
> Any help would be most appreciated!!
>
> -Tony
> -

2006\07\06@090711 by Tony Harris

picon face
Thank you!!  That is it!!

-Tony
----- Original Message -----
From: "scott larson" <.....goldscottKILLspamspam@spam@gmail.com>
To: "Microcontroller discussion list - Public." <piclistspamKILLspammit.edu>
Sent: Thursday, July 06, 2006 12:10 AM
Subject: Re: [PIC] 2 pin audio...


{Quote hidden}

2006\07\06@103746 by Maarten Hofman

face picon face
2006/7/6, Tony Harris <EraseMEkg4wfxspam_OUTspamTakeThisOuTyahoo.com>:
>
> Thank you!!  That is it!!


As I am slowly playing with FPGA as well, I discovered that it is called a
"delta sigma" DAC there. There is an application note,
http://direct.xilinx.com/bvdocs/appnotes/xapp154.pdf that describes the
details. This is of course not something that is easily implemented in a
PICmicro, but some of the ideas could possibly be converted and used.
According to the document you can basically create the equivalent of an
n-bit DAC, based on speed at which you send out the data.

Greetings,
Maarten Hofman.

2006\07\06@161257 by Russell McMahon

face
flavicon
face
> As I am slowly playing with FPGA as well, I discovered that it is
> called a
> "delta sigma" DAC there. There is an application note,
> http://direct.xilinx.com/bvdocs/appnotes/xapp154.pdf that describes
> the
> details. This is of course not something that is easily implemented
> in a
> PICmicro, but some of the ideas could possibly be converted and
> used.
> According to the document you can basically create the equivalent of
> an
> n-bit DAC, based on speed at which you send out the data.

Sigma-Delta DACs and their companion the Delta Sigma ADC converter are
easy enough to implement with quite basic PICs.

A Sigma Delta ADC can be implemented with a surprisingly small amount
of code (without going and looking it up, under 10 lines?).
For 8 to 12 bit ADCs the PIC pin can be used as the comparator input
directly. Scott Datallo wrote a number of Sigma Delta routines using
1, 2 and I think 3 pin versions. They should be in the archives.



       Russell McMahon

2006\07\06@162424 by Mark Rages

face picon face
On 7/6/06, Russell McMahon <apptechspamspam_OUTparadise.net.nz> wrote:
{Quote hidden}

Don't forget the serial port...

http://vivara.net/blog/?p=24

Yes, I was bored when I did this.

The best intro tutorial I found is this one:
http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma.html

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\06@174333 by Maarten Hofman

face picon face
>
> Sigma-Delta DACs and their companion the Delta Sigma ADC converter are
> easy enough to implement with quite basic PICs.


You're right... A 14-bit delta-sigma DAC should be able to reach 80 kHz on a
4 MHz 16F. It is not as difficult as I thought.

Greetings,
Maarten Hofman.

2006\07\06@181521 by Gerhard Fiedler

picon face
Maarten Hofman wrote:

>> Sigma-Delta DACs and their companion the Delta Sigma ADC converter are
>> easy enough to implement with quite basic PICs.
>
> You're right... A 14-bit delta-sigma DAC should be able to reach 80 kHz on a
> 4 MHz 16F. It is not as difficult as I thought.

How do you get these numbers? 4 MHz clock gives 1 MHz instruction cycle. 10
instructions per loop (Russell: 10 "lines") gives ~80 kHz loop frequency.
If I see this correctly, that's one change in the output pin every 12.5 us,
which gives a max output frequency of 40 kHz.

But now the resolution... Those 40 kHz have basically a resolution of 1
bit: they are either on or off. If you want 14 bit resolution, the max.
frequency is much lower -- around 2.5 Hz. Or not?

Gerhard

2006\07\06@182802 by Mark Rages

face picon face
On 7/6/06, Gerhard Fiedler <@spam@listsKILLspamspamconnectionbrazil.com> wrote:
> How do you get these numbers? 4 MHz clock gives 1 MHz instruction cycle. 10
> instructions per loop (Russell: 10 "lines") gives ~80 kHz loop frequency.
> If I see this correctly, that's one change in the output pin every 12.5 us,
> which gives a max output frequency of 40 kHz.
>
> But now the resolution... Those 40 kHz have basically a resolution of 1
> bit: they are either on or off. If you want 14 bit resolution, the max.
> frequency is much lower -- around 2.5 Hz. Or not?
>
> Gerhard
>

It's more complex than that, because of the noise shaping.  The
resolution approaches infinity* at DC, and becomes worse at higher
frequencies.  For low frequency work, sigma-delta is better than PWM
at the same symbol rate (but more math intensive).

I posted this link already:
http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma.html

* Assuming infinite-precision math.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\06@204413 by Gerhard Fiedler

picon face
Mark Rages wrote:

> On 7/6/06, Gerhard Fiedler <KILLspamlistsKILLspamspamconnectionbrazil.com> wrote:
>> How do you get these numbers? 4 MHz clock gives 1 MHz instruction cycle. 10
>> instructions per loop (Russell: 10 "lines") gives ~80 kHz loop frequency.
>> If I see this correctly, that's one change in the output pin every 12.5 us,
>> which gives a max output frequency of 40 kHz.
>>
>> But now the resolution... Those 40 kHz have basically a resolution of 1
>> bit: they are either on or off. If you want 14 bit resolution, the max.
>> frequency is much lower -- around 2.5 Hz. Or not?
>
> It's more complex than that, because of the noise shaping.  The
> resolution approaches infinity* at DC,

Right... but only if the time approaches infinity.


> I posted this link already:
> http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma.html

Yup. But still... the original claim was:

>>> A 14-bit delta-sigma DAC should be able to reach 80 kHz on a 4 MHz 16F.

14 bit resolution means about 84 dB SNR. Given a 1st order converter
(remember the 10 instruction cycles), that means that the sampling
frequency has to be about 1000 times the Nyquist frequency of the signal.
With 100 kHz sampling frequency, the Nyquist frequency becomes 100 Hz, the
max. signal frequency 50 Hz. A bit off my guesstimate, but also quite a bit
off the claimed 80 kHz.

I haven't quite understood yet how a 0-order and a 1st order DAC differ...

Gerhard

2006\07\06@213535 by Mark Rages

face picon face
On 7/6/06, Gerhard Fiedler <RemoveMElistsTakeThisOuTspamconnectionbrazil.com> wrote:
> Mark Rages wrote:
>
> > On 7/6/06, Gerhard Fiedler <spamBeGonelistsspamBeGonespamconnectionbrazil.com> wrote:
> >> How do you get these numbers? 4 MHz clock gives 1 MHz instruction cycle. 10
> >> instructions per loop (Russell: 10 "lines") gives ~80 kHz loop frequency.
> >> If I see this correctly, that's one change in the output pin every 12.5 us,
> >> which gives a max output frequency of 40 kHz.
> >>
> >> But now the resolution... Those 40 kHz have basically a resolution of 1
> >> bit: they are either on or off. If you want 14 bit resolution, the max.
> >> frequency is much lower -- around 2.5 Hz. Or not?
> >
> > It's more complex than that, because of the noise shaping.  The
> > resolution approaches infinity* at DC,
>
> Right... but only if the time approaches infinity.

<curley> Time marches on! </curley>

{Quote hidden}

I took the 80 kHz to be the clock frequency, not the output bandwidth.
So with 80kHz clock freqency the max signal frequency for 14-bits is
.8*50= 40 Hz.  Compare this to a PWM with an 80 kHz clock.  To get
14-bits, you could set the output frequency to 80/(2^14) and vary the
pulse width from 0 clocks to 2^14 clocks.  Bandwidth is (80/(2^14))/2,
or 2.44 Hz.  This is the estimate you gave, so I was trying to explain
that DSM is a different bandwidth tradeoff than PWM.

> I haven't quite understood yet how a 0-order and a 1st order DAC differ...
>

You mean 1st and 2nd order DSM?  They're named after the number of
integrators.  I learned the difference when writing my RS232 audio
project I linked before.  The program I'm distributing is only 1st
order.  I rewrote it for 2nd order and it sounded much clearer, and
taught me a little bit about the two algorithms.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\06@221043 by Maarten Hofman

face picon face
>
> How do you get these numbers? 4 MHz clock gives 1 MHz instruction cycle.
> 10
> instructions per loop (Russell: 10 "lines") gives ~80 kHz loop frequency.
> If I see this correctly, that's one change in the output pin every 12.5us,
> which gives a max output frequency of 40 kHz.
>
> But now the resolution... Those 40 kHz have basically a resolution of 1
> bit: they are either on or off. If you want 14 bit resolution, the max.
> frequency is much lower -- around 2.5 Hz. Or not?


You are right... I made some miscalculations... My post was originally going
to say: "wait a minute! You're saying it is easy to implement a 10-bit audio
noise shaper in PICmicro, and I don't think it is really that easy". So I
wrote down the loop, needed, and managed to get it down to 24 instructions
for a 14-bit shaper (and I was calculating for the 16F688, which runs at 8
MHz, and wronly wrote down 4 MHz). But obviously you need to run that loop
at least 28 times to actually get the full 14-bit shape, so in reality it is
much slower. With 6-bit audio you "only" need 12 instructions, and only at
least 12 cycles through the loop, which means 144 instructions... So at 20
MHz that would leave 34 kHz. So I will stick to my 100 MHz FPGA for now to
get the >8-bit 44.1 kHz that I'm looking for (I should be able to squeeze
both additions into one cycle...)

Greetings,
Maarten Hofman.

2006\07\06@225729 by Gerhard Fiedler

picon face
Mark Rages wrote:

>> I haven't quite understood yet how a 0-order and a 1st order DAC differ...
>
> You mean 1st and 2nd order DSM?  

No, I meant 0-order. Look at figure 7 in the link you posted. It probably
means that there is no integrator... but somehow I have difficulties to
apply this to a DAC.

> I learned the difference when writing my RS232 audio project I linked
> before.  The program I'm distributing is only 1st order.  I rewrote it
> for 2nd order and it sounded much clearer, and taught me a little bit
> about the two algorithms.

I guess I'd need to really implement it... but since you did it, maybe you
can shed some light on this.

Gerhard

2006\07\07@001644 by Bob Axtell

face picon face
Mark Rages wrote:
{Quote hidden}

I spent too many hours on this several years ago, and I was very
disappointed. i even designed
a breadboard to research it. 2 bits is simply NOT enough resolution.

--Bob

2006\07\07@012916 by Mark Rages

face picon face
On 7/6/06, Bob Axtell <RemoveMEengineerspamTakeThisOuTcotse.net> wrote:
> >
> I spent too many hours on this several years ago, and I was very
> disappointed. i even designed
> a breadboard to research it. 2 bits is simply NOT enough resolution.
>

Did the actual performance not agree with the math?

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\07@033936 by Bob Axtell

face picon face
Mark Rages wrote:
> On 7/6/06, Bob Axtell <engineerEraseMEspam.....cotse.net> wrote:
>  
>> I spent too many hours on this several years ago, and I was very
>> disappointed. i even designed
>> a breadboard to research it. 2 bits is simply NOT enough resolution.
>>
>>    
>
> Did the actual performance not agree with the math?
>
> Regards,
> Mark
> markrages@gmail
>  
I don't remember doing the math, I just tried to implement the Black
algorithm as I understood it.

I have forgotten what the issues were. I had a disk failure between then
and now, and my notes
and code have been lost. It seemed that it could not follow the voice
closely enough (I was trying
to synthesize voices), not enough resolution, (needed to ramp quicker?).
The breadboard operated at 20M;
for a 5khz sampling rate (200uS tick interval).

My original plan was to be able to contain several voices, i.e. 'ONE',
TWO', 'THREE',...'EIGHT'
within a Microchip 32K SPI device for reading (I know writing was slow, but
writing was easy. I just needed to be able to read quickly, which the
standard EEPROM could do.)
I was trying to get each voice into 4K, with each sample needing 2
bits/sample, giving me data for
16K worth of samples (3.1sec voice length). The 32K device plus PIC
would have been a LOT
cheaper than the analog record/playback chip, which was costly even in
1000s.

The gig was speculative, and I had to decide if it was doable BEFORE I
committed to the gig. I
decided it was not. Perhaps had I tinkered with it more, it would have
worked.

In fact, I'd love to hear an audio recording of someone implementing the
2-bit algorithm successfully.

--Bob

2006\07\07@082939 by Gerhard Fiedler

picon face
Bob Axtell wrote:

> In fact, I'd love to hear an audio recording of someone implementing the
> 2-bit algorithm successfully.

I'm not sure what you mean by 2-bit algorithm. A delta sigma DAC with a
2-bit DAC? (They come with 1-bit to 5-bit, as far as I've found while
reading these days.)

According to the delta sigma modulator theory that seems to be working well
for others... Voice in phone quality needs something like 50 dB SNR, I
think. With a 1st order delta sigma converter, that means 64 times the
Nyquist frequency. With 4 kHz bandwidth, you're talking about 512 kHz
sampling frequency (using a 1-bit DAC).

AFAIK, when using a 2-bit DAC in the loop (if that is what you meant), you
can reduce the sampling frequency by a factor of 4 to 128 kHz.

If I understood you correctly, you were talking about a 5 kHz sampling rate
and a 2-bit DAC. I don't think that works for voice quality, if that is
really what you meant. You get either much too much noise, or a bandwidth
that is way too small. I'm not sure, but I think the minimum bandwidth is
around 3 or 4 kHz (with a minimum sample rate of 6 to 8 kHz) and the
minimum resolution around 6 bits. You can reduce the resolution, if you
increase the sample rate.

So I guess if you meant that 5 kHz sample rate and 2 bit resolution didn't
work for understanding voice, that was correct.

Gerhard

2006\07\07@131627 by Mark Rages

face picon face
On 7/7/06, Gerhard Fiedler <EraseMElistsspamconnectionbrazil.com> wrote:
> Bob Axtell wrote:
>
> > In fact, I'd love to hear an audio recording of someone implementing the
> > 2-bit algorithm successfully.
>
> I'm not sure what you mean by 2-bit algorithm. A delta sigma DAC with a
> 2-bit DAC? (They come with 1-bit to 5-bit, as far as I've found while
> reading these days.)
>

He's talking about the Roman Black modulator metioned earlier in the thread.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\07@164244 by Gerhard Fiedler

picon face
Mark Rages wrote:

>>> In fact, I'd love to hear an audio recording of someone implementing the
>>> 2-bit algorithm successfully.
>>
>> I'm not sure what you mean by 2-bit algorithm. A delta sigma DAC with a
>> 2-bit DAC? (They come with 1-bit to 5-bit, as far as I've found while
>> reading these days.)
>
> He's talking about the Roman Black modulator metioned earlier in the thread.

Roman's page at the link given earlier doesn't seem to talk about a 2-bit
algorithm, only 1-bit and what he calls 1.5-bit.

Anyway, this looks pretty much like a delta sigma modulator, slightly
modified. (Maybe that prediction thing he does increases the order by one?)
So the bandwidth analysis should still apply, or am I missing something?

Gerhard

2006\07\08@032438 by Bob Axtell

face picon face
Mark Rages wrote:
> On 7/7/06, Gerhard Fiedler <RemoveMElistsEraseMEspamEraseMEconnectionbrazil.com> wrote:
>  
>> Bob Axtell wrote:
>>
>>    
>>> In fact, I'd love to hear an audio recording of someone implementing the
>>> 2-bit algorithm successfully.
>>>      
>> I'm not sure what you mean by 2-bit algorithm. A delta sigma DAC with a
>> 2-bit DAC? (They come with 1-bit to 5-bit, as far as I've found while
>> reading these days.)
>>
>>    
>
> He's talking about the Roman Black modulator metioned earlier in the thread.
>
> Regards,
> Mark
> markrages@gmail
>  
Actually, It was Roman's "1.5 bit" algorithm. Which uses two bits (I
rounded up).

I've never found anyone who made that Roman Black scheme work. Anybody
get it to work?

--Bob

2006\07\08@051601 by Jinx

face picon face
part 1 3834 bytes content-type:text/plain; (decoded 7bit)

> I've never found anyone who made that Roman Black
> scheme work. Anybody get it to work ?

Well, apparently Roman did. Included in the .zip file he has
for download is the .txt file below. The included .wav files
sound not too bad at all. Attached is a comparison of about
the same 5ms of the 6kHz and 44kHz .wav files


------------------------------------------------
BTc Sound Encoder for PIC sound.
Roman Black 2001

See the latest version + tools online at:
centauri.ezy.net.au/~fastvid/picsound.htm
------------------------------------------------

This is a encoder for 1bit sound which can be added
to a PIC (or other embedded) micro.

encoder.exe is a freeware tool that can display your
sound wave (which must be 8bit mono signed) and then
encode it into 2 formats. The encoded waveform is
done by closed loop math modeling and the encoded
waveform is shown with the original wave to compare.
The closed loop encoding gives good 1bit sound,
or more specifically the BEST possible bitstream
to reproduce the waveform.

Different encoding factors can be adjusted to give
the best result. The final sound bitstream data
is 8 times smaller than the original and can be
played back on any chip with a digital output
and a simple RC filter. The encoder even shows the
RC filter and gives you the R and C values so
your playback hardware will match the performance
of the encoder math model.

The encoder theory and algorithm is shown on my
web page:
http://centauri.ezy.net.au/~fastvid/picsound.htm

My BTc encoding algorithm is VERY fast and suitable
for real-time record/encode (as well as playback
obviously) on a PIC or any other small micro,
and will allow recording and playing back on a
20MHz PIC at any rate up to 156 kbit/sec!

I have supplied some .wav sound files, different
speed versions of the same file which has speech and
some background music. Windows should play these
files ok. The files are all 8bit mono signed:

dick06.wav 6kHz
dick09.wav 9.766kHz   (10MHz PIC)
dick15.wav 15.625kHz  (16MHz PIC)
cannon16.wav 16kHz
dick19.wav 19.531kHz  (20MHz PIC)
dick22.wav 22.05kHz
dick44.wav 44.1kHz

sound.wav is the file the encoder works with,
so copy any sound file to that name and it will
appear in the encoder. Size limit is 60000 bytes
max at the moment.

The encoder will export data as raw bitstream data
file called sound.bit which is 8bits per byte,
the bits played from left to right, ie ms_bit is
first.

It will also export the sound bitstream data as
a PIC .asm file as a "retlw" table, allowing it
to be cut and pasted into any PIC .asm code.

You can get great speech playback with this system
provided you try to maximise the volume on
recording, and use bitrates of above 10kHz.
Even low bitrates will give acceptable results
if you do some extra filtering of the output
wave via a second RC filter.

NEW!! Christian Dorner has sent me code for a PIC
chip and I2C serial eeprom. This allows playback of a
LOT of sound, with a 24LC256 eeprom of 32k bytes you
can get 17 seconds of sound at 15625Hz. He gave me 3
new files which I have added to the .ZIP file you have
here. They are:
 * PS_I2C.ASM    PIC assembler code
 * PS_I2C.INC    (serial eeprom routines, needed by above code)
 * PS_I2C.GIF    .GIF of the circuit using PIC 16F84 and 24C65 eeprom
I have not had time yet to test his code, and any
feedback is appreciated.

The web page and software are a bit rushed, I
threw them together in a few days just before
christmas. Hopefully I'll get time soon to add
inprovements like the abilty to attach an RC filter
to your PC parallel port and playback the encoded
bitstream in real time when encoding so you will
be able to hear the result with the same actual
hardware and bitrate you are going to use in your
product.
-Roman



part 2 9173 bytes content-type:image/gif; (decode)


part 3 35 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

2006\07\08@094117 by Timothy Weber

face picon face
Jinx wrote:
>> I've never found anyone who made that Roman Black
>> scheme work. Anybody get it to work ?
>
> Well, apparently Roman did. Included in the .zip file he has
> for download is the .txt file below. The included .wav files
> sound not too bad at all. Attached is a comparison of about
> the same 5ms of the 6kHz and 44kHz .wav files

I tried encoding speech using his software and could never get it to be
even remotely intelligible even at the higher quality levels, with a
moderate degree of experimentation with source sample rates and
prefiltering.  FWIW.
--
Timothy J. Weber
http://timothyweber.org

2006\07\08@111857 by Bob Axtell

face picon face
Jinx wrote:
{Quote hidden}

Thanks for the info, Jinx. I think this is some of what I lost.

--Bob

2006\07\08@112705 by Bob Axtell

face picon face
Timothy Weber wrote:
> Jinx wrote:
>  
>>> I've never found anyone who made that Roman Black
>>> scheme work. Anybody get it to work ?
>>>      
>> Well, apparently Roman did. Included in the .zip file he has
>> for download is the .txt file below. The included .wav files
>> sound not too bad at all. Attached is a comparison of about
>> the same 5ms of the 6kHz and 44kHz .wav files
>>    
>
> I tried encoding speech using his software and could never get it to be
> even remotely intelligible even at the higher quality levels, with a
> moderate degree of experimentation with source sample rates and
> prefiltering.  FWIW.
>  
ditto. I was hoping someone else had good results besides RB. At the
time I was trying my tests,
there were 2-3 others trying as well. Nobody was able to get it to work
as described.

But another possible application has popped up. Sometimes I hate this
stuff. In my next life, I will
be a doctor or dentist.

--Bob


2006\07\08@192845 by Jinx

face picon face
> ditto. I was hoping someone else had good results besides RB. At
> the time I was trying my tests, there were 2-3 others trying as well.
> Nobody was able to get it to work as described

Roman certainly knew his stuff. I'm sure if he said it worked for
him, it did. Likewise I'm sure everyone who's tried it and not got
the expected performance also knows what they're doing. Roman
obviously has great confidence in his method, so why results haven't
been replicated is a mystery


2006\07\09@052757 by Bob Axtell

face picon face
Jinx wrote:
>> ditto. I was hoping someone else had good results besides RB. At
>> the time I was trying my tests, there were 2-3 others trying as well.
>> Nobody was able to get it to work as described
>>    
>
> Roman certainly knew his stuff. I'm sure if he said it worked for
> him, it did. Likewise I'm sure everyone who's tried it and not got
> the expected performance also knows what they're doing. Roman
> obviously has great confidence in his method, so why results haven't
> been replicated is a mystery
>
>
>  
Yes.

I think that's why people keep trying. But nobody seems to be getting
results even remotely
approaching his. It would be nice if he might come in from the cold to
clarify things.

It would seem to me that by now, this technique would be used everywhere
commercially.
Not an insinuatiion, just an observation. Because if it could be made to
work, it would put
14-bit DACs into the realm of the dinosaur.

--Bob

2006\07\09@101840 by Timothy Weber

face picon face
Bob Axtell wrote:
> I think that's why people keep trying. But nobody seems to be getting
> results even remotely
> approaching his. It would be nice if he might come in from the cold to
> clarify things.
>
> It would seem to me that by now, this technique would be used everywhere
> commercially.
> Not an insinuatiion, just an observation. Because if it could be made to
> work, it would put
> 14-bit DACs into the realm of the dinosaur.

That's pretty much my thinking... not that it can't work, but if *I*
can't make it work, I may as well move on to other options, like a
dedicated DAC.
--
Timothy J. Weber
http://timothyweber.org

2006\07\09@172216 by Bob Axtell

face picon face
Timothy Weber wrote:
> Bob Axtell wrote:
>  
>> I think that's why people keep trying. But nobody seems to be getting
>> results even remotely
>> approaching his. It would be nice if he might come in from the cold to
>> clarify things.
>>
>> It would seem to me that by now, this technique would be used everywhere
>> commercially.
>> Not an insinuatiion, just an observation. Because if it could be made to
>> work, it would put
>> 14-bit DACs into the realm of the dinosaur.
>>    
>
> That's pretty much my thinking... not that it can't work, but if *I*
> can't make it work, I may as well move on to other options, like a
> dedicated DAC.
>  
Exactly. If _I_ can't make it work, it is as useful as windshield wipers
on a submarine.

--Bob

2006\07\09@191122 by Gerhard Fiedler

picon face
Bob Axtell wrote:

>> Roman certainly knew his stuff. I'm sure if he said it worked for
>> him, it did. Likewise I'm sure everyone who's tried it and not got
>> the expected performance also knows what they're doing. Roman
>> obviously has great confidence in his method, so why results haven't
>> been replicated is a mystery

> It would seem to me that by now, this technique would be used everywhere
> commercially. Not an insinuatiion, just an observation. Because if it
> could be made to work, it would put 14-bit DACs into the realm of the
> dinosaur.

Roman seems to base his tests mostly on a sample rate of 19.5 kHz. (At
least that's how I interpret the graphics on that page.) I think what he
calls his "predictive" encoding might simply be a 2nd order delta sigma
DAC: the prediction of the single pole low pass adds an integration level
to the algorithm, which is what increasing the sigma delta modulator order
also does. I haven't done the math, but it looks to me like that. So he's
using a 19.5 kHz delta sigma DAC of 2nd order, with 1 or "1.5" bits (let's
just say 2 bits, to be able to apply more common math).

Since with delta sigma DACs the bitrate alone doesn't determine neither the
bandwidth nor the resolution but only the combination of the two, it's the
combination of lowpass and bitrate that determines the bandwidth
resolution.

It seems his BTc8 constant assumes a lowpass time constant of 8 times the
sample time. That gives a cutoff frequency of 390 Hz (for a sample
frequency of 19.5 kHz). That doesn't sound quite enough for voice
communication. But anyway, this is equivalent to an oversampling by a
factor of 25. With a delta sigma DAC 1st order, that's about 35 dB or some
6 bits resolution; with a delta sigma DAC 2nd order, that's about 55 dB or
around 9 bits.

Using a different filter, say 3.2 kHz, the oversampling is only by a factor
of 3, which gives pretty low resolutions in the 2 to 3 bit range. For a
2-bit DAC, it gets more interesting: the oversampling is now equivalent to
a factor of 12, and with a 2nd order DAC that's 40 dB or 7 bits -- good
enough for voice, as is the bandwidth of 3+ kHz.

So that seems to be the configuration that might work for simple voice: a
2-bit delta sigma DAC 2nd order, with a sampling rate around 20 kHz and a
lowpass filter around 3.2 kHz.

I'm not sure this is exactly what Roman is proposing, but it seems to be
close. His design is basically a delta sigma DAC of something between 1 and
2 bits, I think that his prediction algorithm is in essence creating a 2nd
order delta sigma modulation, and he seems to work with a sampling rate of
19.5 kHz. Just the filter cutoff is a bit odd, but I may have simply
misunderstood what he's writing about. And this is of course not a really
sharp filter, so the best (audible) result may not have the theoretical
cutoff frequency.

However, I don't think it would work with the 5+ kSamples/s that you were
trying. I also see only the 19.5 kSamples/s pictures at Roman's page, no
mention of lower sample rates. Given that the 19.5 kHz sample rate is
already a border case with 3 kHz bandwidth and 7 bit resolution, I don't
think that 5 kHz sample rate gives an intelligible result with a 2-bit
delta sigma DAC of 2nd order.

Gerhard

2006\07\10@135140 by Mark Rages

face picon face
On 7/9/06, Bob Axtell <RemoveMEengineerspam_OUTspamKILLspamcotse.net> wrote:
>
> I think that's why people keep trying. But nobody seems to be getting
> results even remotely
> approaching his. It would be nice if he might come in from the cold to
> clarify things.
>
> It would seem to me that by now, this technique would be used everywhere
> commercially.
> Not an insinuatiion, just an observation. Because if it could be made to
> work, it would put
> 14-bit DACs into the realm of the dinosaur.
>
> --Bob

You'd have a hard time buying a piece of digital audio gear that
*doesn't* have a sigma-delta converter in it.  But Roman Black
modulation is not sigma-delta.  I'll write another post about that.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\10@143524 by Bob Axtell

face picon face
Gerhard Fiedler wrote:
> Bob Axtell wrote:
>
>  
>>> Roman certainly knew his stuff. I'm sure if he said it worked for
>>> him, it did. Likewise I'm sure everyone who's tried it and not got
>>> the expected performance also knows what they're doing. Roman
>>> obviously has great confidence in his method, so why results haven't
>>> been replicated is a mystery
>>>      
>
>  
>> It would seem to me that by now, this technique would be used everywhere
>> commercially. Not an insinuatiion, just an observation. Because if it
>> could be made to work, it would put 14-bit DACs into the realm of the
>> dinosaur.
>>    
>
> Roman seems to base his tests mostly on a sample rate of 19.5 kHz.
<snip to keep Russell happy. 'course, now nobody understands anything>

> However, I don't think it would work with the 5+ kSamples/s that you were
> trying. I also see only the 19.5 kSamples/s pictures at Roman's page, no
> mention of lower sample rates. Given that the 19.5 kHz sample rate is
> already a border case with 3 kHz bandwidth and 7 bit resolution, I don't
> think that 5 kHz sample rate gives an intelligible result with a 2-bit
> delta sigma DAC of 2nd order.
>  
<maybe that was enough. I'm trying>

Well, Grerhard, you made a very good point. I wish RB'd never created
that diagram at 6Khz, it really
confused everyone.

A 5Khz sample rate occurs every 200uS (20M). A 10Khz rate has 100uS. A
20khz rate has 50uS,
not much time for a PIC16, but might be fine for a 40M PIC18. I don't
think a PIC16F can squeeze
a bit-banged I2C at 50uS interval, but MAYBE an SPI memory might do it.
I might try it on an SX,
too, that would work... but then you no longer have the cost advantage
of a cheap PIC, do we?

As Rosanne Roseanna Dana used to say, "there's always somethin'!"

--Bob

2006\07\10@144802 by Mark Rages

face picon face
On 7/9/06, Gerhard Fiedler <RemoveMElistsTakeThisOuTspamspamconnectionbrazil.com> wrote:
> Roman seems to base his tests mostly on a sample rate of 19.5 kHz. (At
> least that's how I interpret the graphics on that page.) I think what he
> calls his "predictive" encoding might simply be a 2nd order delta sigma
> DAC: the prediction of the single pole low pass adds an integration level
> to the algorithm, which is what increasing the sigma delta modulator order
> also does. I haven't done the math, but it looks to me like that. So he's
> using a 19.5 kHz delta sigma DAC of 2nd order, with 1 or "1.5" bits (let's
> just say 2 bits, to be able to apply more common math).

I think the algorithm is clever, but it isn't sigma delta.  A sigma
delta modulator integrates the error, but the Roman Black modulator
just integrates the output.   Integrating the error term removes
steady-state error.  Consider the case of a DC input of 40% full
scale.  The SDM will output a 40% duty cycle:   1 0 1 0 0 ... , but
the RBM will output a 0% duty cycle: 0 0 0 0 0 ...  The RBM
demonstrates much more error, and much less noise.  I think this
reasoning could be extrapolated to other low frequency material.

> ...

> It seems his BTc8 constant assumes a lowpass time constant of 8 times the
> sample time. That gives a cutoff frequency of 390 Hz (for a sample
> frequency of 19.5 kHz). That doesn't sound quite enough for voice
> communication. But anyway, this is equivalent to an oversampling by a
> factor of 25. With a delta sigma DAC 1st order, that's about 35 dB or some
> 6 bits resolution; with a delta sigma DAC 2nd order, that's about 55 dB or
> around 9 bits.

Voice communication is usually considered about 300-3kHz bandwidth.
This is part of the cleverness of the RBM: Using
analysis-by-synthesis, it precompensates for the effect of the output
filter.  Compare to the SDM, which uses an integrator (cutoff
frequency of 0 Hz).

I'm curious now.  I'll try to write a simluator for at least RBM and
1st and 2nd order SDM.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\10@145346 by Mark Rages

face picon face
On 7/10/06, Mark Rages <EraseMEmarkragesspamspamspamBeGonegmail.com> wrote:
>
> I think the algorithm is clever, but it isn't sigma delta.  A sigma
> delta modulator integrates the error, but the Roman Black modulator
> just integrates the output.   Integrating the error term removes
> steady-state error.  Consider the case of a DC input of 40% full
> scale.  The SDM will output a 40% duty cycle:   1 0 1 0 0 ... , but
> the RBM will output a 0% duty cycle: 0 0 0 0 0 ...  The RBM
> demonstrates much more error, and much less noise.  I think this
> reasoning could be extrapolated to other low frequency material.
>

My description of RBM is incorrect here; sorry.

I'm working on a simulator.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\10@150058 by Maarten Hofman

face picon face
>
> not much time for a PIC16, but might be fine for a 40M PIC18. I don't
> think a PIC16F can squeeze
> a bit-banged I2C at 50uS interval, but MAYBE an SPI memory might do it.


You need one bit to come out of I2C every 50us? That should be fairly
simple. It takes about 8-9 instructions to retrieve one bit, including
copying it to the relevant output. Of course, every eight bits you need an
additional 7-8 instructions to make sure the acknowledge is handled
correctly.

Greetings,
Maarten Hofman.

2006\07\10@161535 by Bob Axtell

face picon face
Maarten Hofman wrote:
>> not much time for a PIC16, but might be fine for a 40M PIC18. I don't
>> think a PIC16F can squeeze
>> a bit-banged I2C at 50uS interval, but MAYBE an SPI memory might do it.
>>    
>
>
> You need one bit to come out of I2C every 50us? That should be fairly
> simple. It takes about 8-9 instructions to retrieve one bit, including
> copying it to the relevant output. Of course, every eight bits you need an
> additional 7-8 instructions to make sure the acknowledge is handled
> correctly.
>  
I was planning on  cycling  one _byte_ out at a time so the ACK was
handled before halting and allowing
a simple tick interrupt to occur, So the one byte would handle  4 sample
intervals using the 1.5bit (2-bit)
method. That was the original idea. However, I was hoping to do it at
5Khz or 10Khz so that the PIC
could do other simple stuff, like draining a swamp..

BTW, lt me make it clear re what is driving this: A simple 20M PIC + a
simple MC25256 or MC25512
plus a RBM setup is about $1.5 in qty, beating those voice
record/playback chips by at least $7. That's
all this is about. It looks tailormade for an SX but I have no certainty
that these guys will stay in business.

--Bob

> Greetings,
> Maarten Hofman.
>  

2006\07\10@164245 by Maarten Hofman

face picon face
>
> I was planning on  cycling  one _byte_ out at a time so the ACK was
> handled before halting and allowing
> a simple tick interrupt to occur, So the one byte would handle  4 sample
> intervals using the 1.5bit (2-bit)
> method. That was the original idea. However, I was hoping to do it at
> 5Khz or 10Khz so that the PIC
> could do other simple stuff, like draining a swamp..


Well, your musings have started me thinking... What if you connect the I2C
dataline directly to the capacitor? Because of the pull up resistor it would
actually go the other way (towards 1, instead of 0) but you could easily
have 1-bit RB audio coming out of the EEPROM. I've played a lot with the
24... series of EEPROMs, and they are all quite lenient towards the speed
(I've used speeds from 10kHz to 1MHz on a 400 kHz rated EEPROM, and it all
worked well) and duty cycle (you could have the the data signal come out of
the EEPROM for most of the cycle, having the clock go the other way for less
than 2 us). Not entirely within the I2C specification, and you might not
want to do this (there are bound to be some EEPROM that won't like it) but
as said, I was just thinking. The problem is of course the ACK bit which
will disturb the signal, but as the sound wave is precalculated, you can
have those ACK bits included in that calculation, and just increase the
frequency a bit.

If you have a PIC with PWM you could use that to control the I2C clock line,
only requiring you to make sure you send the ACK bit at the appropriate
moments, leaving a lot of time for whatever other application you might wish
to run.

Greetings,
Maarten Hofman.

2006\07\10@165656 by Maarten Hofman

face picon face
>
>  Well, your musings have started me thinking... What if you connect the
> I2C dataline directly to the capacitor? Because of the pull up resistor it
> would actually
>

Pretty stupid idea, after rethinking... It would at least need some form of
latch between the data line and the output, otherwise the ACK would never be
transmitted correctly.

2006\07\10@171111 by Gerhard Fiedler

picon face
Maarten Hofman wrote:

>> However, I was hoping to do it at 5Khz or 10Khz so that the PIC could do
>> other simple stuff, like draining a swamp..
>
> Well, your musings have started me thinking... What if you connect the I2C
> dataline directly to the capacitor?

That's probably /the/ way to go.

> Not entirely within the I2C specification, and you might not
> want to do this (there are bound to be some EEPROM that won't like it)

If you use SPI, there's no problem at all. Just run the data line to the
PIC and also through a gate to the lowpass. The PIC enables the gate only
when there's sound data streaming. Oh, and that might work with I2C also :)

Gerhard

2006\07\10@171618 by Gerhard Fiedler

picon face
Mark Rages wrote:

>> I think the algorithm is clever, but it isn't sigma delta.  A sigma
>> delta modulator integrates the error, but the Roman Black modulator
>> just integrates the output.   Integrating the error term removes
>> steady-state error.  Consider the case of a DC input of 40% full scale.
>>  The SDM will output a 40% duty cycle:   1 0 1 0 0 ... , but the RBM
>> will output a 0% duty cycle: 0 0 0 0 0 ...  The RBM demonstrates much
>> more error, and much less noise.  I think this reasoning could be
>> extrapolated to other low frequency material.
>
> My description of RBM is incorrect here; sorry.

Yes, I thought so. I still think it's a delta sigma converter, but I
haven't done the math.

> I'm working on a simulator.

Make sure you let us know :)

Gerhard

2006\07\10@173318 by Gerhard Fiedler

picon face
Bob Axtell wrote:

>> Roman seems to base his tests mostly on a sample rate of 19.5 kHz.

> Well, Grerhard, you made a very good point. I wish RB'd never created
> that diagram at 6Khz, it really confused everyone.

Including me... you keep confusing me with those references to 5 and 6 kHz
:)  

At least on the page that was mentioned earlier in this thread, I couldn't
find any mention of sample rates that low. Here's what I found regarding
sample rates:

- "giving the ability to playback AND RECORD in real time even on a PIC,
even with high rates up to 150+ kbit/sec."
Way up.

- "Now using prescaler=0 the timer0 interrupt occurs at 15625 Hz. That is
an ideal rate for our sound playback on a PIC."
This sample rate he used in several other places also.

- "This is the BTc8 1bit algorithm on a 19.5kHz sound. 19.5kHz = 20MHz PIC
interrupted every 256 instructions."
This seems to be the sample rate used in all the diagrams.

- "If the total operation is kept to under 64 PIC instructions we can
record and encode sound as a bitstream at 78 kbit/sec on a 20MHz PIC, I
believe it can be done within 32 PIC instructions, which would be 156
kbit/sec."
Here he goes up (from the 15 or 19 kHz used elsewhere), not down.

- "remember at 156 kbit/sec the PIC could happily record and encode CD
quality sound in real time."
This one I didn't get. CD audio is 44.1 kHz sample rate with 16 bit
resolution... No way to do that with 156 kb/s; at least I don't know any
lossless compression algorithm that could do that. Much less on a PIC :)

- "Christian Dorner has sent me code for a PIC chip and I2C serial eeprom.
This allows playback of a LOT of sound, with a 24LC256 eeprom of 32k bytes
you can get 17 seconds of sound at 15625Hz."
Here again the 15625 Hz sample rate. (The 17 seconds are based on a 1-bit
DAC implementation. You possibly may want to go up with the sample rate.)


So where did you see a 6 kHz sample rate?

Gerhard

2006\07\10@173540 by Bob Axtell

face picon face
Maarten Hofman wrote:
{Quote hidden}

What a GREAT idea! How about the SPI device MC25256? No ACK bit!

No wonder that they pay you the big money, Maarten!

--Bob
> If you have a PIC with PWM you could use that to control the I2C clock line,
> only requiring you to make sure you send the ACK bit at the appropriate
> moments, leaving a lot of time for whatever other application you might wish
> to run.
>
> Greetings,
> Maarten Hofman.
>  

2006\07\10@175310 by Bob Axtell

face picon face
Gerhard Fiedler wrote:
{Quote hidden}

I'm beginning to think this might be doable. There is enough talent on
the Piclist to make this work without
any assistance from RB. The application would be a normal 20Mhz PIC
connected by a wire to the 20M
low-end DAC-PIC which does nothing but voice at 20Khz interval.

The wire sends a serial command to the DAC-PIC when then pumps out the
selected sound. After it is finished,
it simply waits for another "selection" via the serial command. That
allows the MC25512 SPI to pump out the
serial bit stream without interpretation (bit-banged, since this cheap
PIC won't have an MSSP). Maybe an F88 for
development (so the ICD2 can be used) but in production, a 16F54, for
the DAC-PIC? At 20Mhz, it takes 8K
for the 1-bit scheme to store a 3-second voice..

Gee, this is looking better and better. I need to layout a PCB that can
be used to develop the DAC-PICcode
on. I can do it and get some PCB's made by Olimex, maybe..? Anybody else
want one?

--Bob

2006\07\10@181718 by Mark Rages

face picon face
On 7/10/06, Gerhard Fiedler <RemoveMElistsKILLspamspamconnectionbrazil.com> wrote:
>
> > I'm working on a simulator.
>
> Make sure you let us know :)
>
> Gerhard
>

Initial results are here:
http://vivara.net/modulator_test/

"in.wav": my input file
"out_sd1.wav" : Sigma-delta first-order
"out_sd2.wav" : Sigma-delta second-order
"out_rb1.wav" : Roman Black 1-pin
"out_rb2.wav" : Roman Black 1.5-pin

A note about all of these files:  No attempt to simulate the output
filter has been done, except the output resampling filter, which is a
windowed sinc filter at about 3200 Hz.  This puts the 1.5-pin result
at a disadvantage, since it's encoded for a decoding that isn't taking
place.

I'll publish the source code as soon as I get a UI on it.  It should
be simple to modify to make it write assembler include files, or
whatever.

I'm impressed by the Roman Black 1-pin.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\10@181921 by Mark Rages

face picon face
On 7/10/06, Mark Rages <markragesSTOPspamspamspam_OUTgmail.com> wrote:
> Initial results are here:
> http://vivara.net/modulator_test/

I forgot to say, these are all modulated at 19200 bits per second.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\10@185147 by Bob Axtell

face picon face
Gerhard Fiedler wrote:
{Quote hidden}

Jinx posted it on the very beginning of this thread.

--Bob

2006\07\10@194205 by Gerhard Fiedler

picon face
Mark Rages wrote:

> Initial results are here:
> http://vivara.net/modulator_test/
>
> "in.wav": my input file
> "out_sd1.wav" : Sigma-delta first-order
> "out_sd2.wav" : Sigma-delta second-order
> "out_rb1.wav" : Roman Black 1-pin
> "out_rb2.wav" : Roman Black 1.5-pin
>
> A note about all of these files:  No attempt to simulate the output
> filter has been done, except the output resampling filter, which is a
> windowed sinc filter at about 3200 Hz.  This puts the 1.5-pin result
> at a disadvantage, since it's encoded for a decoding that isn't taking
> place.

I'm not sure I understood what you did here. The way I think this works is:

- You have an audio signal, sampled at 8000 Hz (125 us steps) with a high
resolution.
- Since you said that the delta sigma sample rate is 19200 Hz (52.1 us),
you probably treated the input either as steps, or interpolated.
- For every delta sigma sample step, you applied one of the four
algorithms. (Which Tc did you choose for Roman's algorithms?)
- The output here is a bitstream (or in the case of Roman's 1.5 bit
algorithm a double-bit stream) with a sample rate of 19200 Hz.

(BTW, three of the bitstreams you created are 19.2 kb/s, while the 1.5 bit
algorithm at this point is a bitstream of 38.4 kb/s. Not quite a fair
comparison -- no wonder you were impressed :)

This bitstream would be what would have to go into the embedded storage.
Now that needs to be converted back into a wave file for listening,
simulating what would happen in the embedded system. So:

- Transform the bitstream into a pulse signal with two (or three, for the
1.5 bit algorithm) levels at a sample rate of 19200 Hz.
- Run this pulse signal through a single pole lowpass according to the
chosen Tc for Roman's algorithms, and through a lowpass of your choice for
the delta sigma algorithms.

Is this what you did?

What seems to be odd is that your 2nd order DS signal is the worst -- when
everybody seems to say that increasing the order improves things. You're
sure there's nothing that can/should be tuned? Integration rates maybe?

Thanks,
Gerhard

2006\07\10@200717 by Mark Rages

face picon face
On 7/10/06, Gerhard Fiedler <spamBeGonelistsSTOPspamspamEraseMEconnectionbrazil.com> wrote:
> - You have an audio signal, sampled at 8000 Hz (125 us steps) with a high
> resolution.

Yes, that's the test file I had lying around.

> - Since you said that the delta sigma sample rate is 19200 Hz (52.1 us),
> you probably treated the input either as steps, or interpolated.

Interpolated, to avoid aliasing.

> - For every delta sigma sample step, you applied one of the four
> algorithms. (Which Tc did you choose for Roman's algorithms?)

I used 1/8.

> - The output here is a bitstream (or in the case of Roman's 1.5 bit
> algorithm a double-bit stream) with a sample rate of 19200 Hz.

The output of the 1.5 bit is also a single-bit bitstream.

> (BTW, three of the bitstreams you created are 19.2 kb/s, while the 1.5 bit
> algorithm at this point is a bitstream of 38.4 kb/s. Not quite a fair
> comparison -- no wonder you were impressed :)

No, read Roman's description.  The *same* stream is used for both bits.

>
> This bitstream would be what would have to go into the embedded storage.

Right.  I haven't written this routine yet.

> Now that needs to be converted back into a wave file for listening,
> simulating what would happen in the embedded system. So:
>
> - Transform the bitstream into a pulse signal with two (or three, for the
> 1.5 bit algorithm) levels at a sample rate of 19200 Hz.

Right.  Well, the 1.5 bit algorithm is not just another level.
Because the series resistance changes, it can't be modeled as a
Thevinin source.  I re-used simulation the analysis-by-synthesis code
does.

> - Run this pulse signal through a single pole lowpass according to the
> chosen Tc for Roman's algorithms, and through a lowpass of your choice for
> the delta sigma algorithms.

Yes.  But I don't add a lowpass myself, except when I resampled the
output to 8000 Hz (before resampling, an ~3200Hz antialiasing filter
is applied).   A more accurate approach is to output at something like
48000 Hz, then add your own lowpass in an audio editor.

>
> Is this what you did?

Yes.  Source is here:  http://vivara.net/software

>
> What seems to be odd is that your 2nd order DS signal is the worst -- when
> everybody seems to say that increasing the order improves things. You're
> sure there's nothing that can/should be tuned? Integration rates maybe?

I'm sure there's a lot that could be tuned.  I just used the diagram
from  http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma.html.  With
unity gain at both integrators, stability is right on the edge.

More comments in the README of the source code.

Regards,
Mark
markrages@gmail
--
You think that it is a secret, but it never has been one.
 - fortune cookie

2006\07\10@211652 by Kevin

picon face
Is anyone using Roman's sound encoder software ?  I actually
have both versions. His webpage has the old dos version, but
he sent me a windows version that was never released to the
public. The original was encoder.exe from 12/20/01. He sent
me BTc.exe from 10/4/02.
BTc.exe gives you an option to select the algorithm 1bit or
1.5bit. Also, the fineness from BTc4 to BTc32. It also
allows you to play the original sound and the BTc sound to
compare the quality. As well as giving you the values for R
and C for the output filter model.
If I have time tomorrow I will put together the circuit sent
to him by Christian Dorner. To compare the sound from
BTc.exe to the actual pic circuit.
If anyone wants the Btc.exe I can send it to them, it's a
360KB zip file.

~Kevin


2006\07\10@214548 by Bob Axtell

face picon face
Kevin wrote:
> Is anyone using Roman's sound encoder software ?  I actually
> have both versions. His webpage has the old dos version, but
> he sent me a windows version that was never released to the
> public. The original was encoder.exe from 12/20/01. He sent
> me BTc.exe from 10/4/02.
> BTc.exe gives you an option to select the algorithm 1bit or
> 1.5bit. Also, the fineness from BTc4 to BTc32. It also
> allows you to play the original sound and the BTc sound to
> compare the quality. As well as giving you the values for R
> and C for the output filter model.
> If I have time tomorrow I will put together the circuit sent
> to him by Christian Dorner. To compare the sound from
> BTc.exe to the actual pic circuit.
> If anyone wants the Btc.exe I can send it to them, it's a
> 360KB zip file.
>
> ~Kevin
>
>
>  
Yes, I'd like a copy.

--Bob

2006\07\11@014119 by scott larson

picon face
I would like to have BTc.exe, if you wouldn't mind.

KILLspamgoldscottspamBeGonespamgmail.com

Thanks,
Scott

On 7/10/06, Kevin <EraseMEkbenspamEraseMEdca.net> wrote:
{Quote hidden}

> -

2006\07\11@021947 by Kevin

picon face
I got a few requests, so I put it up here

members.dca.net/kben/btc_wzip.z**

Just change the z** to zip. Some mail programs don't like
the latter. :)

This is V1.0 for windows the one at RomanBlack.com has more
files, but this is the exe for Windows.

Enjoy,
Kevin

{Quote hidden}

2006\07\11@082912 by Gerhard Fiedler

picon face
Bob Axtell wrote:

>> So where did you see a 6 kHz sample rate?
>
> Jinx posted it on the very beginning of this thread.

Ah... I missed that. I can't get access to those pages, either. I based
everything I said about Roman's algorithm on
http://www.romanblack.com/picsound.htm.

Gerhard

2006\07\11@084952 by Gerhard Fiedler

picon face
Mark Rages wrote:

> Yes.  Source is here:  http://vivara.net/software

Thanks a lot!

>> What seems to be odd is that your 2nd order DS signal is the worst --
>> when everybody seems to say that increasing the order improves things.
>> You're sure there's nothing that can/should be tuned? Integration rates
>> maybe?
>
> I'm sure there's a lot that could be tuned.  I just used the diagram
> from  http://www.beis.de/Elektronik/DeltaSigma/DeltaSigma.html.  With
> unity gain at both integrators, stability is right on the edge.

I don't have time to play with that right now, but I'll let you know when I
get to it. It seems that there's a bit more to creating delta sigma
converters than that page shows; it seems to be more about understanding
the principle, rather than actually implementing them.

Gerhard

2006\07\11@121223 by Scott Dattalo

face
flavicon
face
On Mon, 2006-07-10 at 17:17 -0500, Mark Rages wrote:

> Initial results are here:
> http://vivara.net/modulator_test/

Hi Mark,

I probably should've chimed in earlier, but I also wrote code to simulate
Roman's algorithm.

http://www.dattalo.com/swsd.m

BTW, the only difference between Roman's algorithm and a filtered stream
of PCM pulses is that Roman attempts to take the output filter into
account. This is accomplished with a software filter that approximates the
response of the output RC filter. To the degree the approximation matches
the real thing, the quality of the synthesized signal can be quite good
(from at least an RMS error point of view).

If you view the RC filter as an approximation to an integrator, then
you'll see that Roman's algorithm is really just a Sigma Delta algorithm.
The important difference (besides the LPF approximating the integrator) is
that the error signal in the delta portion of the SDM is synthesized.

Scott

2006\07\11@121223 by Scott Dattalo

face
flavicon
face
On Mon, 2006-07-10 at 17:17 -0500, Mark Rages wrote:

> Initial results are here:
> http://vivara.net/modulator_test/

Hi Mark,

I probably should've chimed in earlier, but I also wrote code to simulate
Roman's algorithm.

http://www.dattalo.com/swsd.m

BTW, the only difference between Roman's algorithm and a filtered stream
of PCM pulses is that Roman attempts to take the output filter into
account. This is accomplished with a software filter that approximates the
response of the output RC filter. To the degree the approximation matches
the real thing, the quality of the synthesized signal can be quite good
(from at least an RMS error point of view).

If you view the RC filter as an approximation to an integrator, then
you'll see that Roman's algorithm is really just a Sigma Delta algorithm.
The important difference (besides the LPF approximating the integrator) is
that the error signal in the delta portion of the SDM is synthesized.

Scott

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...