jp57+@andrew.cmu.edu (Jefferson Provost) (02/05/91)
Hi, Does anyone out there know what _really_ goes on in the depths Sound Manager? I have the replacement IM chapter on the Sound Manager that is dated 2 October 1988 (but which is apparently newer than that), and I find it woefully inadequate for my purposes. There are a number of things I need to know, but most importantly is this: I have an external device providing me with interrupts precisely every millisecond, with which I increment a counter to provide the program with a millisecond-accuracy timer. What I'd like to do be able to know the to the millisecond when a sound started. The sound is a plain sampled sound buffer (not a 'snd ' resource) that I build in memory from data read in from a file. Currently, I build the bufferCmd to play the sound, then save the current value of the millisecond-timer, and do a SndDoImmediate to play the buffer. Unfortunately, my timing (using the same device that provides me with the millisecond counter) tells me that the sound starts anywhere from 6 to 20 milliseconds after I tell it to. If the overhead were constant, I think that would be OK, but it isn't constant, it seems to vary greatly. My big questions are: What's the delay? And is there some way to make it constant? Also, I've heard that the Apple sound hardware always plays samples at a certain rate, and if you play sounds at different sampling rate than that, it has to throw away samples or create new samples, or in some other way convert your sound to its sampling rate. Is this true? If so, what's the sampling rate of the hardware? The sound manager literature that I have leads me to believe that it's 22254.5454, but I don't know for sure. Third, have there been changes to the Sound Manager (hardware or software) since the last revision of the documentation? I have a brand new SI running system 6.0.7. With this machine, ampCmd works to change the volume of buffered sounds, even though the documentation says that it doesn't. I wonder what other things are different. There are a couple of other things (like the fact that my call-back routine comes back before the sound has finished playing) but this is enough for now. Any help, pointers or worthwhile documentation of any kind will be appreciated. Thanx, Jeff +------------------------------------------------------------------------------ + |Jefferson Provost | jp57+@andrew.cmu.edu |"I had my hand on a dollar bill | Psychology | (412) 268-3139 |and the dollar bill flew away, | Carnegie Mellon |----------------------|but the sun is shining down on me | Pittsburgh, PA 15213 |-=-=-=-=-=-=-=-=-=-=-=|and it's here to stay" +------------------------------------------------------------------------------ +
oster@well.sf.ca.us (David Phillip Oster) (02/09/91)
A little tutorial on how Sound works on a macintosh. In a pre-se/30
macintosh, one with a 68000 processor, there is a buffer of memory that
has one 16 bit word for each scan line. Just as there is a vertical retrace
interrupt, synchronized with the start of each video frame, there is a
horizontal retrace interrupt, synchronized with the start of each scan
line. On these early macs, the horizontal retrace interrupt handler would
grab one byte of successive words, and throw it at the 8-bit D to A
converter. This gives you an approximately 22khz sample rate.
The sound driver would fill the buffer during successive vertical retrace
interrupts, leading me to believe that sound driver calls would
delay until the next VBL time at the least.
On the new macs, there is a sound chip and God knows how the sound manager
really works, but the new macs have to emulate the old hardware, if called
upon to do so for software compatibility.
It used to be, you could find assembly language source code for playing
sampled sound that accessed the horizontal retrace sample buffer directly,
bypassing sound manager and sound driver. This code had names like SoundPlay.c
or Scope.asm (oscilliscope that is) If all you want to do is write a one - shot
psych experiment, NOT a commercial product, or even a shareware game, then
you might consider using these codes for your raw sound output in order to
have more control of what is really going on.
--
-- David Phillip Oster - At least the government doesn't make death worse.
-- oster@well.sf.ca.us = {backbone}!well!oster