Post by thread:[PIC] 2 pin audio...

Thank you!! That is it!! -Tony ----- Original Message ----- From: "scott larson" <.....goldscottKILLspam@spam@gmail.com> To: "Microcontroller discussion list - Public." <piclistKILLspammit.edu> Sent: Thursday, July 06, 2006 12:10 AM Subject: Re: [PIC] 2 pin audio... {Quote hidden}> http://www.romanblack.com/picsound.htm > > On 7/6/06, Tony Harris <.....kg4wfxKILLspam.....yahoo.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 >> --

> 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

On 7/6/06, Russell McMahon <apptechspam_OUTparadise.net.nz> wrote: {Quote hidden}> > 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. 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

On 7/6/06, Gerhard Fiedler <@spam@listsKILLspamconnectionbrazil.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

Mark Rages wrote: > On 7/6/06, Gerhard Fiedler <KILLspamlistsKILLspamconnectionbrazil.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

On 7/6/06, Gerhard Fiedler <RemoveMElistsTakeThisOuTconnectionbrazil.com> wrote: > Mark Rages wrote: > > > On 7/6/06, Gerhard Fiedler <spamBeGonelistsspamBeGoneconnectionbrazil.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}> 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 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

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

Mark Rages wrote: {Quote hidden}> On 7/6/06, Gerhard Fiedler <TakeThisOuTlistsEraseMEspam_OUTconnectionbrazil.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 > 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

Mark Rages wrote: > On 7/6/06, Bob Axtell <engineerEraseME.....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

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

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)

Jinx wrote: {Quote hidden}>> 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 > > Thanks for the info, Jinx. I think this is some of what I lost. --Bob

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

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

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

On 7/9/06, Bob Axtell <RemoveMEengineerspam_OUTKILLspamcotse.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

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

On 7/9/06, Gerhard Fiedler <RemoveMElistsTakeThisOuTspamconnectionbrazil.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

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

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

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

Maarten Hofman wrote: {Quote hidden}>> 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. > > 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. >

Gerhard Fiedler wrote: {Quote hidden}> 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 > > 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

On 7/10/06, Gerhard Fiedler <RemoveMElistsKILLspamconnectionbrazil.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

Gerhard Fiedler wrote: {Quote hidden}> 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 > > Jinx posted it on the very beginning of this thread. --Bob

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

On 7/10/06, Gerhard Fiedler <spamBeGonelistsSTOPspamEraseMEconnectionbrazil.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

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

I would like to have BTc.exe, if you wouldn't mind. KILLspamgoldscottspamBeGonegmail.com Thanks, Scott On 7/10/06, Kevin <EraseMEkbenEraseMEdca.net> wrote: {Quote hidden}> 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 > > > -

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}> On 7/10/06, Kevin <@spam@kben@spam@spam_OUTdca.net> 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

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