Post by thread:[EE] [PIC] ultra low cost audio out from a microco

Exact match. Not showing close matches.
PICList Thread
'[EE] [PIC] ultra low cost audio out from a microco'
2007\02\28@152210 by rolf

Hi Folks! I am looking for a way to produce simple "lo-fi" audio from a microcontroller pin, in a way that is very low cost. In that sense, I am looking for a simple circuit, but don't mind if there's some complexity in the software to drive it. Think "toy" quality, not anything more. The circuit I am considering is simple: just a small speaker (8 ohm) connected to a microcontroller pin through a series resistor (100 ohm). There is also a small cap (e.g. 0.1uF) in series with the speaker to create a crude low-pass filter. This is pretty good at generating raspy-sounding square waves. But, I am hoping that with some software tricks, I could do better, and possibly play some digitized sounds (simple speech, etc.). The microcontroller is of the $2-3 variety, and does not have a D/A. Anyone have a cool hardware/software hack for doing audio on the cheap? Thanks! (this is my first post.. yikes) -rolf

2007\02\28@153908 by Dario Greggio

rolf wrote: > I am looking for a way to produce simple "lo-fi" audio > from a microcontroller pin, in a way that is very low cost. > In that sense, I am looking for a simple circuit, but don't > mind if there's some complexity in the software to drive it. > Think "toy" quality, not anything more. Hi Rolf, IMO the main problem is that the limited amount of ROM on such MPUs will limit the duration of sound/samples you can store. For a minimal Sound Quality, I'd stay on some 4 bit ADPCM or alike, with some minimum 8KHz sampling (though I know that some tooys do have lower quality... and in fact sound very bad ;-) ) Ok, actually there should be some even better algorhitms, maybe. Then, I'd go with a PWM, to do the D/A conversion. PS: a "series capacitor" is a "high pass" filter, not a "low" :-) -- Ciao, Dario

2007\02\28@154618 by William Couture

On 2/28/07, rolf <spam_OUTrolfvwTakeThisOuTpizzicato.com> wrote: > I am looking for a way to produce simple "lo-fi" audio > from a microcontroller pin, in a way that is very low cost. > In that sense, I am looking for a simple circuit, but don't > mind if there's some complexity in the software to drive it. > Think "toy" quality, not anything more. > > The circuit I am considering is simple: just a small speaker (8 ohm) connected > to a microcontroller pin through a series resistor (100 ohm). > There is also a small cap (e.g. 0.1uF) in series with the speaker to create > a crude low-pass filter. > This is pretty good at generating raspy-sounding square waves. > But, I am hoping that with some software tricks, I could do better, > and possibly play some digitized sounds (simple speech, etc.). > The microcontroller is of the $2-3 variety, and does not have a D/A. > > Anyone have a cool hardware/software hack for doing audio on the cheap? Roman Black's "picsound" is what you're looking for: http://www.romanblack.com/picsound.htm There is an even better version that uses 2 output pins: http://www.romanblack.com/btc_alg.htm Bill -- Psst... Hey, you... Buddy... Want a kitten? straycatblues.petfinder.org

2007\02\28@154710 by Marcel Birthelmer

Rolf, I'd suggest using a PWM pin. You can get a pretty high PWM frequency depending on which PIC/processor you're using (and how fast you're running it), and you can approximate a decent sine wave with an LPF. Your duty cycle should be proportional to the value of the sample you're playing, and you need to time it properly so that you update the duty cycle after each sample time. The LPF would then take out all the high frequencies so that it averages out to the sample value. - Marcel

2007\02\28@155915 by Jan-Erik S�derholm

www.romanblack.com/picsound.htm This is the one that often comes up when simple sound from a PIC is discussed... Regards, Jan-Erik. rolf skrev: {Quote hidden}> Hi Folks! > > I am looking for a way to produce simple "lo-fi" audio > from a microcontroller pin, in a way that is very low cost. > In that sense, I am looking for a simple circuit, but don't > mind if there's some complexity in the software to drive it. > Think "toy" quality, not anything more. > > The circuit I am considering is simple: just a small speaker (8 ohm) connected > to > a microcontroller pin through a series resistor (100 ohm). > There is also a small cap (e.g. 0.1uF) in series with the speaker to create > a crude low-pass filter. > This is pretty good at generating raspy-sounding square waves. > But, I am hoping that with some software tricks, I could do better, > and possibly play some digitized sounds (simple speech, etc.). > The microcontroller is of the $2-3 variety, and does not have a D/A. > > Anyone have a cool hardware/software hack for doing audio on the cheap? > > Thanks! (this is my first post.. yikes) > > -rolf

2007\02\28@161753 by Jinx

Olin Lathrop has a sound generator http://www.embedinc.com/pic/hal.htm As for Roman Black's software, look up the thread [PIC] 2 pin audio... from July 2006. A lot of posts about digital sound, comments on Roman's method, worth reading

'[EE] [PIC] ultra low cost audio out from a microco'
2007\03\01@040834 by Alan B. Pearce

>I am looking for a way to produce simple "lo-fi" audio >from a microcontroller pin, in a way that is very low cost. >In that sense, I am looking for a simple circuit, but don't >mind if there's some complexity in the software to drive it. >Think "toy" quality, not anything more. ... >Anyone have a cool hardware/software hack for doing audio on the cheap? Have a look at Olins HAL project, which was a small project he did to produce Halloween sounds from a PIC chip using the PWM hardware. He also has a program to convert *.wav files on a PC into a suitable format for use with this sound generation method. See http://www.embedinc.com/pic/ to download his development environment and projects.

2007\03\01@041123 by Michael Rigby-Jones

>-----Original Message----- >From: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.edu] >On Behalf Of Jan-Erik Söderholm >Sent: 28 February 2007 20:59 >To: Microcontroller discussion list - Public. >Subject: Re: [EE] [PIC] ultra low cost audio out from a >microcontroller? > > >http://www.romanblack.com/picsound.htm > >This is the one that often comes up when simple >sound from a PIC is discussed... > >Regards, >Jan-Erik. But note that this is not capable of drivering a speaker directly, you will need an external amp. However, this is very easy to achieve with either a simple discrete solution (just a complementry pair of transistors may suffice) or a small integrated power amp such as the ultra cheap LM386 which requires just a few external components. Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. =======================================================================

2007\03\01@145559 by rolf

Thanks PICLIST for the excellent suggestions... Roman Black's binary time constant algorithm seems like it might be the right thing for me. I will also look up the old posts about it. Also, thanks to the one that pointed out that a small amp is needed with Roman Black's trick. I am trying to keep this super-cheap, and to run it on a 3V coin battery. Anyway, I will look into that too. Cheers everyone! -rolf

2007\03\01@161730 by engineer

Warning: more than a few of us have tried this BTC idea without any success. My research seemed to indicate that at least 3 bits are needed to cover the dynamic range needed for almost any viable sound. So good luck. Keep us informed of your progress. --Bob Quoting rolf <.....rolfvwKILLspam.....pizzicato.com>: {Quote hidden}> > > Thanks PICLIST for the excellent suggestions... > > Roman Black's binary time constant algorithm seems like > it might be the right thing for me. > I will also look up the old posts about it. > > Also, thanks to the one that pointed out that a small > amp is needed with Roman Black's trick. > I am trying to keep this super-cheap, and to run it on a 3V coin battery. > Anyway, I will look into that too. > > Cheers everyone! > > -rolf > -

2007\03\01@164326 by Mark Rages

On 3/1/07, EraseMEengineerspam_OUTTakeThisOuTneomailbox.com <engineerspam_OUTneomailbox.com> wrote: > Warning: > > more than a few of us have tried this BTC idea without any success. My > research seemed to indicate that at least 3 bits are needed to cover > the dynamic range needed for almost any viable sound. > > So good luck. Keep us informed of your progress. > > --Bob > Last time this came up, I wrote a simulator that lets you judge the sound without building any circuit. Here it is: http://vivara.net/software/modulation_test/ There was a lot of good discussion last time. Here's a link to that thread: http://thread.gmane.org/gmane.comp.hardware.microcontrollers.pic/93686 Regards, Mark markrages@gmail -- You think that it is a secret, but it never has been one. - fortune cookie

2007\03\01@170932 by Gustavo Aguayo

You could use the ISD2560 /75/90/120 Single-Chip Record/Playback Device controlled by any PIC. These ICs are cheap, they can record and playback an audio signal of up to 60, 75, 90 or 120 seconds, and they can drive a speaker directly. Of course if you need a louder signal you may use a LM386 a the output... Regards, Gustavo Aguayo --------------------------------- Want to start your own business? Learn how on Yahoo! Small Business.

2007\03\01@195556 by Hector Martin

engineer@neomailbox.com wrote: > more than a few of us have tried this BTC idea without any success. My > research seemed to indicate that at least 3 bits are needed to cover > the dynamic range needed for almost any viable sound. I've built it (1.5bit version), runs fine. The sound quality isn't awesome, but it's good enough to be intelligible without any problems. You do need an amp, and it does help if you tweak the filter circuit. -- Hector Martin (@spam@hectorKILLspammarcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc

2007\03\01@202255 by John La Rooy

There were guys that did amazing things with the speaker in the Apple II which is driven by a single on/off output. They called it softdac back then http://www.ffd2.com/fridge/chacking/c=hacking21.txt -- Hi! I found your page as I was searching for something else 6502-related, and was very interested. Although I have always been aware of the C64, I have never really been a user--I have used Apple II's since 1980. I was particularly interested in the article on playing "digis" on the C64. I became interested in playing digitized sounds on the Apple II in 1993, after hearing a 3-bit, 11.025 KHz PWM player. At 3 bits, you can imagine how noisy speech samples were, but the overall effect for a 1 MHz machine with a 1-bit speaker "toggle" was amazing. It made me wonder how far this PWM technique could be pushed on a stock, 1 MHz Apple II (not the somewhat faster, 65816-based IIgs). The short answer is, much farther than I expected! Robin and Stephen accurately describe the theoretical PWM limit as 6 bit samples at about 16 KHz for a stock 1 MHz machine, but, as they point out, that is not practically realizable for a number of reasons, unless the play loop is completely unrolled! Furthermore, in the Apple II world, sampled sounds have acquired a few standardized sampling rates--mostly as a result of Mac influence, which was in turn influenced by CD's. The most common rate in the Apple II world is 11.025 KHz, or one-fourth of the audio CD sampling rate. This is commonly considered to be "AM radio quality", with a Nyquist bandwidth of about 5.5 KHz and a practical bandwidth of 4+ KHz, given practical anti-aliasing filters (at the sampling end, not the playback end). A frequency of 11.025 KHz is, though high, still painfully audible to people whose ears are not zonked--a piercing "squeal" running through every sound. So even though it is possible to write a practical 6-bit 11.025 KHz PWM player (usually called a SoftDAC in the Apple II world), the resulting listening experience is disappointing. So I went to work on a way to do 2x oversampling, and built a 5-bit 22.050 KHz PWM player. It was sad to lose a bit, but the absence of any audible "carrier" more than compensated for it! If you have access to an 8-bit Apple II (preferably with lower case, like a //e), and also preferably with a way of attaching an external speaker or headphones in place of the miserable 2.75" internal speaker, then you can easily give it a try and judge for yourself. I'm pretty proud of the novel design of the code, which I would characterize as "vectored" unrolled loops, one for every two pulse duty cycles, which I wrote a BASIC program to write for me--much less painful for counting cycles! The package is available on the web at: http://members.aol.com/MJMahon/index.html and is called <A HREF="http://members.aol.com/MJMahon/sound22.shk">Sound Editor v2.2</A>, since I had to "dress up" the player into something fun to play with. ;-) An earlier version of Sound Editor was published on SoftDisk in 1994, IIRC, but this one is a little more evolved. It also introduced 2:1 ADPCM compression of 8-bit sampled sounds, to save disk space. It is a lossy compression, but not very noticeably. The editor package also includes those routines, in 6502 assembly code. All of this should be trivially adaptable to the stock, 1 MHz C64, with very good results. By using the filters, you could probably filter out the 11.025 KHz carrier and return to 6-bit accuracy! I should note that in the Apple world, sampled sounds are usually represented as "excess-128" codes, which means that the sign bit is inverted. This actually simplifies things, since the sample value is within a few shifts of being the pulse width in cycles. Let me know what you think! -michael --

2007\03\01@203905 by Bob Axtell

Hector Martin wrote: > KILLspamengineerKILLspamneomailbox.com wrote: > >> more than a few of us have tried this BTC idea without any success. My >> research seemed to indicate that at least 3 bits are needed to cover >> the dynamic range needed for almost any viable sound. >> > > I've built it (1.5bit version), runs fine. The sound quality isn't > awesome, but it's good enough to be intelligible without any problems. > You do need an amp, and it does help if you tweak the filter circuit. > > You are held in awe, sir. Can you flesh out some details? --Bob

2007\03\01@220009 by John Chung

Hector, Any possible way to improve the sound to a better quality*like phone quality*? I don mind changing the MCU. DSP does better? John --- Hector Martin <RemoveMEhectorTakeThisOuTmarcansoft.com> wrote: {Quote hidden}> spamBeGoneengineerspamBeGoneneomailbox.com wrote: > > more than a few of us have tried this BTC idea > without any success. My > > research seemed to indicate that at least 3 bits > are needed to cover > > the dynamic range needed for almost any viable > sound. > > I've built it (1.5bit version), runs fine. The sound > quality isn't > awesome, but it's good enough to be intelligible > without any problems. > You do need an amp, and it does help if you tweak > the filter circuit. > > -- > Hector Martin (TakeThisOuThectorEraseMEspam_OUTmarcansoft.com) > Public Key: http://www.marcansoft.com/marcan.asc > > --

2007\03\01@222545 by Hector Martin

Bob Axtell wrote: > Hector Martin wrote: >> I've built it (1.5bit version), runs fine. The sound quality isn't >> awesome, but it's good enough to be intelligible without any problems. >> You do need an amp, and it does help if you tweak the filter circuit. >> >> > You are held in awe, sir. Can you flesh out some details? I'd need to rebuild it to check all the different bits and pieces, but it was pretty much as described. This was a one-off hack, which I took apart once I was done using it. I used an audio amp from my junkbox (a little PCB from a dead overhead data display). The PIC was a 18F4550 (just because that's what I had lying around), and I used a 1mbit I2C EEPROM (24AA1025). If my math is correct, sample rate was 46875Hz. I have the playback program lying around, although I forget what exact encoding settings I used. The program also contained code to allow programming of the EEPROM via serial port (basically a very simple serial protocol to allow control of the I2C hardware - then a PC program did the actual writing sequence). The data was stored packed into bytes, with two bits per byte for control data (so I could include, say, text or other data with the sound, and signal starts and stops). Also - I'm not sure where the old BTc page is, but I can't find it now. It used to have more details. Specifically, I remember that when the bits on both outputs differ (when adjacent bits in the bitstream are not the same), the second output is switched into high impedance to produce "half a bit" (half the effect of both outputs being turned on or off). I believe there's some info in the helpfile of the encoder software. -- Hector Martin (RemoveMEhectorTakeThisOuTmarcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc

2007\03\02@004135 by William Chops Westfield

>> My research seemed to indicate that at least 3 bits are needed >> to cover the dynamic range needed for almost any viable sound. Back in the IBM PC/XT days, there were some programs that produced intelligible speech from the built-in speaker (which had a 1-bit connection to something.) Mind you, it sounded pretty awful, but it WAS recognizable. IIRC, it modulated a relatively high frequency carrier wave. (eg, send 40KHz to a cheap 8ohm speaker, and it will probably successfully mechanically integrate that to a voltage around V+/2; increase the widths of the lows or the highs, and you can get the code to move forward or back. Do it fast enough, and you get full control of the output waveform.) BillW

2007\03\02@022428 by peter green

> >> My research seemed to indicate that at least 3 bits are needed > >> to cover the dynamic range needed for almost any viable sound. > > Back in the IBM PC/XT days, there were some programs that produced > intelligible speech from the built-in speaker (which had a 1-bit > connection to something.) Mind you, it sounded pretty awful, but > it WAS recognizable. i also have vauge reccolections of an unofficial driver to divert windows audio output to the PC speaker.

2007\03\02@120940 by Paul Hutchinson

> -----Original Message----- > From: piclist-bouncesEraseME.....mit.edu On Behalf Of peter green > Sent: Friday, March 02, 2007 2:23 AM > > > Back in the IBM PC/XT days, there were some programs that produced > > intelligible speech from the built-in speaker (which had a 1-bit > > connection to something.) Mind you, it sounded pretty awful, but > > it WAS recognizable. > > i also have vauge reccolections of an unofficial driver to > divert windows audio output to the PC speaker. You can still get the PC Speaker driver from Microsoft's web site: http://support.microsoft.com/kb/q138857/ It sounds OK for a Trek Whistle wave file but is pretty bad with most sounds. It does not work with NT/XP. Paul

2007\03\02@124506 by Scott Dattalo

Mark Rages wrote: > Last time this came up, I wrote a simulator that lets you judge the > sound without building any circuit. > > Here it is: > http://vivara.net/software/modulation_test/ > > There was a lot of good discussion last time. Here's a link to that thread: > thread.gmane.org/gmane.comp.hardware.microcontrollers.pic/93686 > It's only been 8 months for this thread to repeat! Last time Mark mentioned his sound simulator, I pointed out my octave/Matlab script: http://www.dattalo.com/swsd.m What I neglected to point out last time are some screen shots of the simulation results: http://www.dattalo.com/p2.png http://www.dattalo.com/p3.png http://www.dattalo.com/p4.png These illustrate the simulated synthesized audio output. In addition, the script can plot the error output (i.e. the error between the desired and actual outputs). It may be useful to use this script just to get an idea where some of the trade offs are. Scott

2007\03\27@015850 by rolf

Hi Folks, Well, I took the sage advice from the list and implemented the Roman Black algorithm on my microcontroller. The results were mixed. Roman Black provides a nice little windows app, which simulates his algorithm. But, I found that to always sound better than my implementation. The difference seems to be the noise created by the sampling frequency. Obviously, that should be filtered out, but when you are using a 1-bit algorithm, that noise is quite strong. That led me to up the sampling rate to about 44khz, at which point the result finally sounded passable (and quite similar to the simulation). But, I was running through the limited memory of the micro rather quickly. The RB algorithm needed an amplifier to function properly, but that was easy using a part like the LM386. I did not have a chance to try an obvious alternative: a lower sampling rate combined with a 4-bit DAC (e.g. one made from resistors). That would also require an amp. In conclusion, I found it quite a challenge to improve upon the basic "speaker connected to an output pin, via a resistor" at a very low cost. In addition, even very low quality digitized sound takes up more memory than I expected. Thanks in particular to Mark Rages. Your code was quite helpful. -rolf

2007\03\27@174231 by Scott Dattalo

rolf wrote: > Well, I took the sage advice from the list and implemented > the Roman Black algorithm on my microcontroller. > > The results were mixed. > When you say that it seems like the noise in your implementation is due to the sampling frequency, do you mean that the sampling frequency was too low or that your sampling frequency was not stable? For this approach to work, it's absolutely necessary that the output samples are generated at a rate that exactly matches the pseudo analog node. The easy way to achieve this is by running the sampler at a constant rate and predicting how the output voltage will change given the current filtered output voltage, the next pulse, the duration of the pulse, and the filter's frequency response. BTW, I have not built this type of D/A before - so my insight lacks any practical backing. But here are a couple of suggestions that might help. First, the RC summing junction is the one that the algorithm attempts to model. As you note, to drive any kind of load an amplifier like the LM386 is needed. If you make the LM386 a low pass filter whose cutoff is above the RC but below the output sample rate, and at the same time allow it to have gain, then you might improve the sound quality. Second, do you have access to an audio-bandwidth spectrum analyzer? If so you may try synthesizing a sine wave (e.g. 500Hz) and measure its spectral purity. It would be interesting to see how narrow the 500Hz spike is, how low the noise floor it, what the harmonics look like, etc. Also, it'd be interesting to see how strong the output sampling frequency is in the spectrum. Third, I'm not sure how you structured your code, but if you want to get some tips on obscure single-cycle resolution isochronous timing generation, then check out: http://www.dattalo.com/technical/software/pic/pwm256.txt Fourth, not a suggestion, but a question; did you experiment with different RC time constants? Scott

2007\03\29@211819 by rolf

Hi Scott, Thanks for your message. Responses below. {Quote hidden}> From: Scott Dattalo <EraseMEscottdattalo.com> > Subject: Re: [EE] [PIC] ultra low cost audio out from a > microcontroller (an update) > To: "Microcontroller discussion list - Public." <RemoveMEpiclistEraseMEEraseMEmit.edu> > > rolf wrote: > > Well, I took the sage advice from the list and implemented > > the Roman Black algorithm on my microcontroller. > > > > The results were mixed. > > > > When you say that it seems like the noise in your implementation is due > to the sampling frequency, do you mean that the sampling frequency was > too low or that your sampling frequency was not stable? I meant the sampling frequency itself was audible. That was obvious when the rate was around 11khz. But, even at 44.1khz, there are components of lower frequencies that appear. For example, if you are trying to represent a DC level of 0v the 1 bit stream is 01010101... Well, at 44.1khz sample rate, that appears like a 22.05khz wave. That isn't really audible to me, but if it was a bit lower, it might be. So, it shows how you are forced to use quite a high sample rate with 1-bit algorithms. The part that you can hear is what I was referring to. > > For this approach to work, it's absolutely necessary that the output > samples are generated at a rate that exactly matches the pseudo analog > node. The easy way to achieve this is by running the sampler at a > constant rate and predicting how the output voltage will change given > the current filtered output voltage, the next pulse, the duration of the > pulse, and the filter's frequency response. I may have had a bit of this problem too. I was using an interrupt service routine to output each sample. {Quote hidden}> > BTW, I have not built this type of D/A before - so my insight lacks any > practical backing. But here are a couple of suggestions that might help. > > First, the RC summing junction is the one that the algorithm attempts to > model. As you note, to drive any kind of load an amplifier like the > LM386 is needed. If you make the LM386 a low pass filter whose cutoff is > above the RC but below the output sample rate, and at the same time > > Second, do you have access to an audio-bandwidth spectrum analyzer? If > so you may try synthesizing a sine wave (e.g. 500Hz) and measure its > spectral purity. It would be interesting to see how narrow the 500Hz > spike is, how low the noise floor it, what the harmonics look like, etc. > Also, it'd be interesting to see how strong the output sampling > frequency is in the spectrum. Oh, that would be nice, but no I don't have that. I have a 2 channel scope though. > > Third, I'm not sure how you structured your code, but if you want to get > some tips on obscure single-cycle resolution isochronous timing > generation, then check out: > www.dattalo.com/technical/software/pic/pwm256.txt > > Fourth, not a suggestion, but a question; did you experiment with > different RC time constants? I did tinker with the RC values suggested by the Roman Black simulator. I found that some variation (Like 50% off) didn't really make a huge difference. Keep in mind that the sound quality is very crude! On the other hand, no RC filter truly sounded terrible. > > Scott

2007\03\29@214519 by David VanHorn

> > > the 1 bit stream is 01010101... > Well, at 44.1khz sample rate, that appears like a 22.05khz wave. > That isn't really audible to me, but if it was a bit lower, it might be. > So, it shows how you are forced to use quite a high sample rate with 1-bit > algorithms. The part that you can hear is what I was referring to. A low pass filter, with a -3dB point of about 3kHz would help a lot here. Also very little point in encoding anything below 300 Hz. It's amazing what a difference a little proper bandpass filtering makes.

2007\03\29@225229 by Richard Prosser

Couldn't you use a PC sound card based spectrum analyser for this? There are plenty "out there" to choose from. RP On 30/03/07, rolf <RemoveMErolfvwspam_OUTKILLspampizzicato.com> wrote: {Quote hidden}> > Hi Scott, > > Thanks for your message. > Responses below. > > > From: Scott Dattalo <RemoveMEscottTakeThisOuTspamdattalo.com> > > Subject: Re: [EE] [PIC] ultra low cost audio out from a > > microcontroller (an update) > > To: "Microcontroller discussion list - Public." <EraseMEpiclistspamspamBeGonemit.edu> > > > > rolf wrote: > > > Well, I took the sage advice from the list and implemented > > > the Roman Black algorithm on my microcontroller. > > > > > > The results were mixed. > > > > > > > When you say that it seems like the noise in your implementation is due > > to the sampling frequency, do you mean that the sampling frequency was > > too low or that your sampling frequency was not stable? > > I meant the sampling frequency itself was audible. > That was obvious when the rate was around 11khz. > But, even at 44.1khz, there are components of lower frequencies that > appear. For example, if you are trying to represent a DC level of 0v > the 1 bit stream is 01010101... > Well, at 44.1khz sample rate, that appears like a 22.05khz wave. > That isn't really audible to me, but if it was a bit lower, it might be. > So, it shows how you are forced to use quite a high sample rate with 1-bit > algorithms. The part that you can hear is what I was referring to. > > > > > For this approach to work, it's absolutely necessary that the output > > samples are generated at a rate that exactly matches the pseudo analog > > node. The easy way to achieve this is by running the sampler at a > > constant rate and predicting how the output voltage will change given > > the current filtered output voltage, the next pulse, the duration of the > > pulse, and the filter's frequency response. > > I may have had a bit of this problem too. > I was using an interrupt service routine to output each sample. > > > > > BTW, I have not built this type of D/A before - so my insight lacks any > > practical backing. But here are a couple of suggestions that might help. > > > > First, the RC summing junction is the one that the algorithm attempts to > > model. As you note, to drive any kind of load an amplifier like the > > LM386 is needed. If you make the LM386 a low pass filter whose cutoff is > > above the RC but below the output sample rate, and at the same time > > > > Second, do you have access to an audio-bandwidth spectrum analyzer? If > > so you may try synthesizing a sine wave (e.g. 500Hz) and measure its > > spectral purity. It would be interesting to see how narrow the 500Hz > > spike is, how low the noise floor it, what the harmonics look like, etc. > > Also, it'd be interesting to see how strong the output sampling > > frequency is in the spectrum. > > Oh, that would be nice, but no I don't have that. > I have a 2 channel scope though. > > > > > Third, I'm not sure how you structured your code, but if you want to get > > some tips on obscure single-cycle resolution isochronous timing > > generation, then check out: > > www.dattalo.com/technical/software/pic/pwm256.txt > > > > Fourth, not a suggestion, but a question; did you experiment with > > different RC time constants? > > I did tinker with the RC values suggested by the Roman Black simulator. > I found that some variation (Like 50% off) didn't really make a huge > difference. Keep in mind that the sound quality is very crude! > On the other hand, no RC filter truly sounded terrible. > > > > > Scott > -

2007\03\29@232905 by David VanHorn

On 3/29/07, Richard Prosser <RemoveMErhprosserKILLspamgmail.com> wrote: > > Couldn't you use a PC sound card based spectrum analyser for this? > There are plenty "out there" to choose from. Maybe.. If they sample really fast, and if you can trust them to be anything like flat. Doubtful proposition. OK for the voice band though, 300-3000 Hz

2007\03\29@233659 by Richard Prosser

Isn't that the band he was looking at? RP On 30/03/07, David VanHorn <dvanhornSTOPspamspam_OUTmicrobrix.com> wrote: {Quote hidden}> On 3/29/07, Richard Prosser <spamBeGonerhprosserSTOPspamEraseMEgmail.com> wrote: > > > > Couldn't you use a PC sound card based spectrum analyser for this? > > There are plenty "out there" to choose from. > > > Maybe.. If they sample really fast, and if you can trust them to be anything > like flat. > Doubtful proposition. > > OK for the voice band though, 300-3000 Hz > -

2007\03\29@234803 by Mark Rages

On 3/29/07, David VanHorn <KILLspamdvanhornspamBeGonemicrobrix.com> wrote: > On 3/29/07, Richard Prosser <EraseMErhprosserEraseMEgmail.com> wrote: > > > > Couldn't you use a PC sound card based spectrum analyser for this? > > There are plenty "out there" to choose from. > > > Maybe.. If they sample really fast, and if you can trust them to be anything > like flat. > Doubtful proposition. > > OK for the voice band though, 300-3000 Hz Now really. PC sound cards are fine for the whole audio band. I wouldn't expect the full 16-bits dynamic range, but the frequency response should be pretty flat up to 20kHz or so. Regards, Mark markrages@gmail -- Most of the time, for most of the world, no matter how hard people work at it, nothing of any significance happens. -- Weinberg's Law

2007\03\29@235915 by Herbert Graf

On Thu, 2007-03-29 at 22:48 -0500, Mark Rages wrote: > Now really. > > PC sound cards are fine for the whole audio band. > > I wouldn't expect the full 16-bits dynamic range, but the frequency > response should be pretty flat up to 20kHz or so. Not all of them. Assuming you are talking about an upper level sound card you can expect a relatively flat response up to around 15 or 16kHz. Some cards WILL have a very flat response up to 20kHz, but usually those are the cards that support higher sample rates (i.e. 96kHz). Cheap sounds cards can be very horrible, I've seen reviews where some cards really start diving in response anywhere above 10kHz, or worse. http://www.anandtech.com sometimes reviews sound cards and publishes their response curves. An example is: http://www.anandtech.com/showdoc.aspx?i=2518&p=1 TTYL

2007\03\30@014827 by Scott Dattalo

On Thu, 2007-03-29 at 18:18 -0800, rolf wrote: > From: Scott Dattalo <@spam@scott@spam@spam_OUTdattalo.com> > > > > When you say that it seems like the noise in your implementation is due > > to the sampling frequency, do you mean that the sampling frequency was > > too low or that your sampling frequency was not stable? > > I meant the sampling frequency itself was audible. <snip> > For this approach to work, it's absolutely necessary that the output > > samples are generated at a rate that exactly matches the pseudo analog > > node. The easy way to achieve this is by running the sampler at a > > constant rate and predicting how the output voltage will change given > > the current filtered output voltage, the next pulse, the duration of the > > pulse, and the filter's frequency response. > > I may have had a bit of this problem too. > I was using an interrupt service routine to output each sample. Any jitter in the high frequency output sampler has the potential of producing low frequencies. For example, suppose you're updating the outputs at 10kHz and have a filter that sufficiently removes this carry (which in fact you do). However, suppose every 4'th sample happens a little sooner than the others. This error occurs at a 10kHz/4 = 2.5 kHz rate and is not filtered. It certainly will be attenuated (relative to everything else) but it will still be present and your ears are very good at discerning this effect. A spectrum analyzer will illustrate the effect too. (I'm not familiar with the "sound card" spectrum analyzers, but I doubt they have enough dynamic range - I did a quick search and found one that claimed 190dB dynamic range! Since that's obviously a joke, I can't really trust the specs I see for these things. However, I'd be surprised if you could achieve 60dB dynamic range. SRS makes a low frequency "FFT" spectrum analyzer that has 90dB of dynamic range. Your ears (but not mine) have way more dynamic range.) I don't know if you've given up on this project or not, but I'd suggest going back and simplifying things. Would it be possible to create a version of code that looks something like this (assuming midranged PIC, for the 16bit devices there are several optimizations that can be made.): initialization.... SoundLoop: call getNextBit ; Takes exactly N-cycles, C==next bit skpc goto driveLow ; 2-cycles for the goto nop ; 1-cycle delay bsf port,bit goto SoundLoop driveLow: bcf port,bit goto SoundLoop This loop will write to the I/O port at the same rate, regardless if a 1 or 0 is the next bit. The 'getNextBit' routine takes exactly N-cycles -- regardless of which path is taken in the code. For example, maybe every 8-th bit you have to look a new value from ROM. The other 7 calls need to insert a delay that equals this ROM lookup overhead. BTW, I'm also assuming the bit stream already has been preprocessed to take advantage of output filter's shaping. The above loop is for a 1-bit encoding. If you have the so called 1.5 bit encoding (or more properly, the tertiary encoding), then you could add the Port tri-stating like this: initialize... MOVLW TRISB ; Get address of the TRIS register MOVWF FSR ; Use indirect accesses to toggle TRIS. SoundLoop: call getNextBit ; Takes exactly N-cycles C==1-bit, ; Z=Pin direction ; output changes states in exactly 9 cycles from now. skpnz goto triState ; We're going to drive a 1 or a 0 ; what did we drive last time? btfss INDF,pin ; goto outputIsDriving ; Last time must have been a tristate SKPC bcf port,pin SKPNC bsf port,pin bcf INDF,pin ; drive the output goto SoundLoop outputIsDriving: skpc goto driveLow ; 2-cycles for the goto nop ; 1-cycle delay bsf port,bit goto SoundLoop driveLow: bcf port,bit goto SoundLoop triState: goto $+1 ; delay 2-cycles goto $+1 ; delay 2-cycles nop ; delay 1-cycle bsf INDF,pin ;Tristate the output goto SoundLoop This has a 13-cycle overhead for the loop. But all I/O changes occur at the same cycle relative to the beginning of the loop. If you wanted a 20k sample update rate, then the 'getNextBit' routine can have a delay. Scott

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