Searching \ for '[EE] [PIC] ultra low cost audio out from a microco' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=audio
Search entire site for: '[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

flavicon
face

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

face picon face
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

face picon face
On 2/28/07, rolf <spam_OUTrolfvwTakeThisOuTspampizzicato.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

picon face
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

face picon face
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}

2007\02\28@161753 by Jinx

face picon face
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
face picon face
>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

picon face


>-----Original Message-----
>From: .....piclist-bouncesKILLspamspam@spam@mit.edu [piclist-bouncesspamKILLspammit.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

flavicon
face


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

face picon face
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 <.....rolfvwKILLspamspam.....pizzicato.com>:

{Quote hidden}

> -

2007\03\01@164326 by Mark Rages

face picon face
On 3/1/07, EraseMEengineerspam_OUTspamTakeThisOuTneomailbox.com <engineerspamspam_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

picon face
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

flavicon
face
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@hectorKILLspamspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\03\01@202255 by John La Rooy

flavicon
face
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

face picon face
Hector Martin wrote:
> KILLspamengineerKILLspamspamneomailbox.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

picon face
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 <RemoveMEhectorTakeThisOuTspammarcansoft.com> wrote:

{Quote hidden}

> --

2007\03\01@222545 by Hector Martin

flavicon
face
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 (RemoveMEhectorspamTakeThisOuTmarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\03\02@004135 by William Chops Westfield

face picon face

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

flavicon
face

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

picon face
> -----Original Message-----
> From: piclist-bouncesEraseMEspam.....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

face
flavicon
face
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

flavicon
face

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

face
flavicon
face
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

flavicon
face

Hi Scott,

Thanks for your message.
Responses below.

{Quote hidden}

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}

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

picon face
>
>
> 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

picon face
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_OUTspamKILLspampizzicato.com> wrote:
{Quote hidden}

> -

2007\03\29@232905 by David VanHorn

picon face
On 3/29/07, Richard Prosser <RemoveMErhprosserKILLspamspamgmail.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

picon face
Isn't that the band he was looking at?
RP

On 30/03/07, David VanHorn <dvanhornSTOPspamspamspam_OUTmicrobrix.com> wrote:
{Quote hidden}

> -

2007\03\29@234803 by Mark Rages

face picon face
On 3/29/07, David VanHorn <KILLspamdvanhornspamBeGonespammicrobrix.com> wrote:
> On 3/29/07, Richard Prosser <EraseMErhprosserspamEraseMEgmail.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

flavicon
face
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

face
flavicon
face
On Thu, 2007-03-29 at 18:18 -0800, rolf wrote:

> From: Scott Dattalo <@spam@scott@spam@spamspam_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...