There's a few things about AHI drivers that are a bit different than most other projects. I'll only touch on a few of the points, as a complete discussion would take too long. If you or anyone has specific questions, this thread would be a great place to post them. Also, if anyone wishes to correct anything that I post incorrectly, you are invited and welcomed to do so. AHI drivers look very similar to the library/device code model that is common in OS4. But the similarities don't run very deep. Under the hood there are some very specific differences. Most devices are acessed using Exec IO Requests. This is NOT the case for AHI drivers. Yes, there is an Exec-style AHI interface, but that's not where the driver code goes. When AHI is started, it reads the DEVS:Audiomodes directory, where you usually have the modefiles for each driver. These modefiles are IFF blocks that describe the basic capabilities of the device they support.. Much of what you see in the AHI Prefs window is read from these files. A side note for developers: We have a command now that will read a text file and generate modefiles easily. It can be easily added to the project makefile so that a modefile is created with each make. Lots of the existing modefiles appear to be hacked with a hex editor. It's nice to have a more proper means available. Of note to users: You can prevent AHI from mounting a device simply by moving the modefile out of devs:Audiomodes. Back to the startup flow. For each modefile found, AHI loads and opens the driver. At this point the driver should go out and look for whatever device it supports. It IS possible to find multiple devices of the same type. If no device is found, the driver exits on return to AHI. If AHI prefs is opened, AHI will ask the driver for all the specifics, how many inputs, what are they named, same with outputs, all that other stuff. Actually a fair amount of the driver code is just to support all the queries from the driver. There's also a query model for card features: There's a small list of features that _MIGHT_ be supported by the audio device, and might not. So when asked the driver can either provide that feature or defer it back to AHI for a software implementation. Reverb is handled this way. When a program wants to make sound, it opens AHI. It might specify the device using the ModeID, or it (usually) just opens the default. The caller asks for whatever bit width, number of channels, and sample rate that it wants, at this point the driver will return whatever it can offer as closely to the request as possible. It is VERY IMPORTANT for the caller to check the returned values to see what it really got. You can't always get what you want. But if you try sometimes you just might find, you get what you need. Note: Multiple programs can use AHI at the same time. Each one gets it's own controls, including volume. AHI will mix it all down for the final output. Once the program has set up it's volume, pan, and other settings, it calls "Start()", and the output begins.. From the driver end, the start command tells the driver to begin shoveling audio buffers to the hardware. But here's another change from the usual.. The sound device is expected to create a hard interrupt every time it needs more data. So it has to go through the process of setting it up and making all that stuff right. The program usually does a typical double-buffered routine. I'll write a short loop of pseudo-code to demonstrate: Call AHI to fill Buffer A with audio data. Call AHI to fill Buffer B with audio data. Set hardware to create an interrupt at the completion of each buffer. Post buffer A to hardware. Post buffer B to hardware. Elsewhere, the interrupt code looks something like this. On Interrupt: Figure out which buffer just completed. Call AHI to fill that buffer with new audio. Post that buffer to play immediately after the one that's playing now. There may be similar code for recording, which of course copies data FROM the sound card instead of TO the sound card. Code that is called from an interrupt must meet certain restrictions. I'll avoid that topic completely. ;) When AHI issues a STOP command, your program sets a flag to prevent queueing any more sound buffers. In a nutshell, that's the process. There are a few things that are affected by this model: The "Modefile" usage assumes that you know all the available options when you make the driver. This will NOT be the case for USB devices. Each device may have different capabilities. AHI mounts everything it can find at startup. This assumes that you can not add or remove anything after you have started. Again, this is not ideal for USB audio devices. AHI does not offer much for interconnection between programs. It's really just suited for sound card drivers. (camd has spoiled me that way. Anything connects to anything) AHI _DOES_ offer individual volume controls for each client. But many programs ignore the volume control and expect the user to manage it with "mixer". "Mixer" has no interface with AHI at all. It is expected to "bang the hardware" directly to control the volume. This creates multiple issues. Adding a sound card that is driven from device code (like a USB sound card) is tricky because USB does not create interrupts when it needs more audio data. I'll stop there. Enough typing for tonight. I will try to keep an eye on this forum for questions or comments.

I never knew it made public release. :) I had sent it over privately after he asked. It's a very simple tool, but given the number of AHI drivers that have modefiles that look like they were made with a hex editor, I think it's a useful addition, especially when it is managed directly by the makefile.

It appears that you can find those includes in the following archive.. AmiPhoneSrc.lha Oddly enough I could not download this file from my primary aminet site. No idea why and I'm not much for figuring it out right now. The link I provided works for me. Have Fun, LyleHaze