Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!apple!well!oster From: oster@well.sf.ca.us (David Phillip Oster) Newsgroups: comp.sys.mac.programmer Subject: Re: Sound Manager: Who knows what evil lurks? Message-ID: <23065@well.sf.ca.us> Date: 9 Feb 91 14:54:23 GMT References: Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 27 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