djh@dragon.metaphor.com (Dallas J. Hodgson) (06/12/90)
I recently wrote a few support routines for reproducing sampled sound on the
PC. I used a Mimetics digitizer to capture the samples (8-bit, around 14KHz)
into an Amiga, and compressed the bits like so:
for each byte that exceeds the 0 crossing, output a "1" bit
else output a "0" bit.
This stream of bits would get bit-packed into a byte stream, translated into
"C" source, (a large static array) and subsequently shifted out into the
speaker port of a PS/2. My player looks like this:
PlaySample(buffer,size,speed)
unsigned char *buffer;
unsigned short size;
short speed;
{
char x; /* must be unsigned! */
unsigned char tmp;
unsigned short bitctr,dly;
/* Samples are stored internally as bit-packed values; each PCM value
appears in Bit 7 down to bit 0, the starting again in the next byte.
Packing the bytes this way gives us an easy way to check the each
bit (via the sign) before it gets shifted out. */
while (size--) {
x = *buffer++;
bitctr=0;
do {
tmp=inp(0x61);
if (x < 0) { /* bit 7 set? */
if (!(tmp & 2)) outp(0x61,tmp | 2);
}
else {
if (tmp & 2) outp(0x61,tmp & 0xFD);
}
x<<=1; bitctr++;
for (dly=0;dly<speed;dly++);
} while (bitctr<=8);
}
}
My question is this : Why does it sound so poor? Compared to some other PC
sampled sound, the distortion is really bad; a very audible aliasing-screech
overtone is present on top of the sample regardless of anything I try.
Regarding the sample itself: I used a 2-second sample of speech, taken from
a comedy CD and run through a compressor. Frequency content is well below
7KHz. For reference, I remember a PD program called "helpme.com" that had
excellent clarity. Thanx in advance,
+----------------------------------------------------------------------------+
| Dallas J. Hodgson | "This here's the wattle, |
| Metaphor Computer Systems | It's the emblem of our land. |
| Mountain View, Ca. | You can put it in a bottle, |
| USENET : djh@metaphor.com | You can hold it in your hand." |
+============================================================================+
| "The views I express are my own, and not necessarily those of my employer" |
+----------------------------------------------------------------------------+xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/12/90)
In article <1207@metaphor.Metaphor.COM> djh@dragon.metaphor.com (Dallas J. Hodgson) writes: > >I recently wrote a few support routines for reproducing sampled sound on the >PC. I used a Mimetics digitizer to capture the samples (8-bit, around 14KHz) >into an Amiga, and compressed the bits like so: > > for each byte that exceeds the 0 crossing, output a "1" bit > else output a "0" bit. > >This stream of bits would get bit-packed into a byte stream, translated into >"C" source, (a large static array) and subsequently shifted out into the >speaker port of a PS/2. My player looks like this: > [omitted] > >My question is this : Why does it sound so poor? Compared to some other PC >sampled sound, the distortion is really bad; a very audible aliasing-screech >overtone is present on top of the sample regardless of anything I try. > [He reaches back 23 years to a class in radio theory...] If I understand what you've done, it is the equivalent of class C clipping: you've amplified your signal to infinity, then lopped it off into a square wave. In so doing, you've introduced a lot of high frequencies that weren't in the original, and lost a lot of what was carried in the shape of the wave you squared off. I do _not_ know how to do this, or how it interacts with th PC's fairly modest sound reproduction capabilities, but perhaps you need a conversion where the _density_ of 1 bits is proportional to the height (from a negative minimum) of the wave, rather than just letting the zero crossing act as a switch. I.e., at the most negative part of the curve, you convert to all zeros, at the zero crossing you have "01010101..." and at the most posittive part of the curve, you have all ones. Might not work, depends on the physical play mechanism. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- in the distance a roasted cave newt screamed in agony -- Andrew Palfreyman
eda@persoft.com (Ed Almasy) (06/28/90)
In article <1990Jun26.013548.246@eng.umd.edu> nulspace@eng.umd.edu (Michael Chang) writes: >There exists a program written by a Canadian author, what it does is play >digitized sounds in the Macintosh format. Surprisingly enough, it is >*damn* good, the quality that is. The problem with this program is that it grabs almost EVERYTHING in the machine to accomplish its task. In other words, it makes the (usually foolish) assumption that it can do whatever it damn well pleases with the hardware, and if you've got something else running in the machine (like multitasking shells, network shells, device drivers, TSRs, et cetera) you're screwed - the machine will act weird, lock up, or even reboot in the middle of the sound playback. >[I don't know why IBM-PC sounds are so crappy, the sound quality seems >mighty fine to me after listening to these mac files... maybe a >conspiracy by IBM to hobble it and then ten years later come up with >a new invention that does wonders to the speaker?] There's no conspiracy, just a lack of coordination of development efforts on how to deal with the hardware. If the PC had a operating system that was powerful enough that most developers would go through it (instead of going directly to the iron), doing "mac-like" sound wouldn't be a problem. I don't mean to cut down the program you mentioned, but after spending several hours tracing through it to find out exactly why it wouldn't run with anything else in the machine, I felt compelled to respond. :-)
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (06/28/90)
In article <1990Jun28.003451.1287@persoft.com> eda@persoft.com (Ed Almasy) writes: > >>[I don't know why IBM-PC sounds are so crappy, the sound quality seems >>mighty fine to me after listening to these mac files... IBM PC's aren't SUPPOSED to sound anything other than a very very mundane beep. All they do for sound is to turn on and off a single bit to the speaker. > >There's no conspiracy, just a lack of coordination of development >efforts on how to deal with the hardware. If the PC had a operating >system that was powerful enough that most developers would go through it >(instead of going directly to the iron), doing "mac-like" sound wouldn't >be a problem. > This last statement is utterly wrong. There is no real hardware support for sound on the PC other than a simple timer that makes a square wave. Square vanes sound bad. IF the PC had a "control everything" OS like, say, Unix, then there would be nothing anybody could do to make the PC sound better. GIven that MSDOS is the way it is, a very very clever, very smart person, with lots of effort, can get it to sound better by, essentially, doing digital-to-analog conversion by time multiplexing IN SOFTWARE!!! Those who belittle such efforts are usually not really familiar to what is going on. A challenge: To the people saying "get a real OS" ----- Unix runs just fine on 386 PC's. Go out and buy it at the store. Write a program under Unix to do the same job of displaying sound. On the same hardware. I dare you. I double dare you. Especially if more than one process is running. Doug McDonald
nulspace@eng.umd.edu (Michael Chang) (06/28/90)
>The problem with this program is that it grabs almost EVERYTHING in >the machine to accomplish its task. In other words, it makes the >(usually foolish) assumption that it can do whatever it damn well >pleases with the hardware, and if you've got something else running in >the machine (like multitasking shells, network shells, device drivers, >TSRs, et cetera) you're screwed - the machine will act weird, lock up, >or even reboot in the middle of the sound playback. > >I don't mean to cut down the program you mentioned, but after spending >several hours tracing through it to find out exactly why it wouldn't run >with anything else in the machine, I felt compelled to respond. :-) No problem at all... I mean, it isn't "my baby"... anyways, it seems to work fine on the network IBM PS/2s in the computer labs on campus, which are chock full o' drivers. What is important is that mac sounds CAN be duplicated by the PC speaker, which means it must be possible to rewrite it to be more friendly. The author will give you assembly code if you give him $15, I will do it as soon as I get around to it. [The possiblities are endless, given source]
eda@persoft.com (Ed Almasy) (06/28/90)
In article <1990Jun28.015758.19188@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <1990Jun28.003451.1287@persoft.com> eda@persoft.com (Ed Almasy) writes: >>There's no conspiracy, just a lack of coordination of development >>efforts on how to deal with the hardware. If the PC had a operating >>system that was powerful enough that most developers would go through it >>(instead of going directly to the iron), doing "mac-like" sound wouldn't >>be a problem. >> >This last statement is utterly wrong. There is no real hardware support for >sound on the PC other than a simple timer that makes a square wave. If you would have read the rest of my message, instead of just having a "my OS is better than your OS" knee-jerk reaction, you would have noticed that I wasn't talking about the sound capabilities of the machine - I was talking about how the fact that most PC software goes straight to the hardware instead of going through the operating system, which causes all sorts of grief when two or more software components want to twiddle the same piece of hardware at the same time. The program originally under discussion is a prime example of such a component, since it does things like reprogramming the timer chip and disabling all sorts of interrupts. >Square vanes sound bad. IF the PC had a "control everything" OS >like, say, Unix, then there would be nothing anybody could do >to make the PC sound better. If the PC had a "control everything" OS, then a program like the one in question could tell the operating system that it needed exclusive access to the resources, the operating system could tell the other apps/drivers to shut down for a moment, and we could have quality sound without crashing the whole machine. As it is there is very little arbitration, and programs are constantly stepping all over each other when they try to optimize performance. >a very very clever, very smart person, with lots of effort, can >get it to sound better by, essentially, doing digital-to-analog >conversion by time multiplexing IN SOFTWARE!!! Those who belittle >such efforts are usually not really familiar to what is going on. What exactly is "digital-to-analog conversion by time multiplexing"?? I don't know if you know anything about the program under discussion (you don't seem to), but there are no analog operations involved. It clicks the speaker at a rate determined by the data that you feed it - purely a digital operation. There is no support for analog sound in the PC. And finally . . . . . I did not say anything to belittle the piece of software in question. (Once again,) if you would have read the rest of my message you would have realized that I was merely commenting on (and complaining about) the fact that getting various high performance software components to work together under MS-DOS is a real headache.
wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) (06/29/90)
In article <1990Jun28.164522.2987@persoft.com> eda@persoft.com (Ed Almasy) writes: >If the PC had a "control everything" OS, then a program like the one in >question could tell the operating system that it needed exclusive access >to the resources, the operating system could tell the other apps/drivers >to shut down for a moment, and we could have quality sound without >crashing the whole machine. As it is there is very little arbitration, >and programs are constantly stepping all over each other when they try >to optimize performance. You are right all sound request should be handled through the OS, but to do simple 8-bit sound, it should not take your whole computer (see below), even if you decide to do the proper support through the OS. It would be much easier for the PC world just to add (standardize on) a $5 D to A converter. >What exactly is "digital-to-analog conversion by time multiplexing"?? I >don't know if you know anything about the program under discussion (you >don't seem to), but there are no analog operations involved. It clicks >the speaker at a rate determined by the data that you feed it - purely a >digital operation. There is no support for analog sound in the PC. > I don't think you know what you are talking about! If I understand it right, the program in question basically uses Pulse Length Modulation (also goes by the name of Pulse Code Modulation or Pulse Duty Modulation) to simulate an analog channel on the 1 bit 'digital' channel. It is too complicated to explain how and why it works here(mail me if you really must know or in a more specific news group--(I think you could talk about this in sci.electronics), but basically the microprocessor's complete attention is needed to do it. The reason this is, is because the microproccessor must change the duty cycle of the clock chip every "sample". -Dean Wallwey ****************************************************************************** *-Dean Wallwey wallwey@snoopy.colorado.edu or wallwey@128.138.238.103 * *"If people drove cars like they run computers, 5% of the driving populating * *would die every business day in automobile accidents!" * * #define DISCLAIMER \ * * The above comments are my own and not necessarly that of my employer or\ * * school. grammer, spelling errors, real heavy flames > NULL * ******************************************************************************
eda@persoft.com (Ed Almasy) (06/30/90)
In article <22898@boulder.Colorado.EDU> wallwey@snoopy.Colorado.EDU (WALLWEY DEAN WILLIAM) writes: >In article <1990Jun28.164522.2987@persoft.com> eda@persoft.com (Ed Almasy) writes: >>I don't know if you know anything about the program under discussion (you >>don't seem to), but there are no analog operations involved. It clicks >>the speaker at a rate determined by the data that you feed it - purely a >>digital operation. There is no support for analog sound in the PC. > >I don't think you know what you are talking about! If I understand it >right, the program in question basically uses Pulse Length Modulation >(also goes by the name of Pulse Code Modulation or Pulse Duty Modulation) >to simulate an analog channel on the 1 bit 'digital' channel. It is too >complicated to explain how and why it works here(mail me if you really >must know or in a more specific news group--(I think you could talk >about this in sci.electronics), but basically the >microprocessor's complete attention is needed to do it. >The reason this is, is because the microproccessor must change the duty >cycle of the clock chip every "sample". I think we must be talking about two different pieces of software. The program I was refering to (and which I disassembled and traced through) changes the clock rate, but only at the beginning of playback. I would be interested in seeing one that changes it continuously, if only to examine the algorithm. Does anyone know where a copy might be available? (let's take this to e-mail)