how to use AHI, basics

Does anyone know of a small, tangible and working example of how to use the lowlevel AHI functions? I am trying and trying, but no sound comes out... Need it for Napalm.

@alfkil

Are you sure that you want lowlevel ahi functions ? Better choice is to use hi-level ahi functions, just because low-level ones will "block" ahi, and so, only one sound app can works at one time, but with hi-level, its all will works without blocking and many apps can works at one time (i.e. running amigaamp + some mp3, and napalm with only sound fx enabled). If you will choice low-level, then only napalm and nothing more can works at one time with music.

Can't give you ready to compile example right now, but can show almost-ready-to-compile source, where i play raw sounds over hi-level ahi interface. Of course a bit lame, and should be done better, but it works. Source have:

load_song() - that one load raw sound to memory

play_sound_routine() - main code, which open ahi interface, create necessary message ports, fill the ahi packet by necessary info , and then play sound via DoIO.

play_sound() - create a process in which use main playing functinos.

stop_sound() - kill process

You need a bit modify to make it works (add right includes, and few very-small changes), but as it now, it works and i take it from ready and released prod.

@kas1e

Hey cool, it actually works! Thanks a lot, dude!
Now I just have to convert it into m68k assembly.....

(Only thing that bothers me is, that the ahi manual says, that the right way to make ingame sounds is to use the lowlevel interface. Also just out of curiosity it would be really good to have an example of lowlevel usage.)

@alfkil
Quote:
Btw, out of topic, but just intersting to know: how you do C to Asm conversion ? You manually trying to write the same on Asm from scratch, or by any disassembler ? I, back in past, do conversion by this way (for ELFs):

Compile binary, then objdump for .text, then just copy+paste to C source as bytecode to char massive, and then, just step by step trying to replace it like:

"\x90\x90" // nop
"\x80\x80" // int 80h

and so on.

This way of course a bit "brute force", but good for testing :)

Or almost the same, but with help of IDA (disassemble, and then step by step).

Quote:

Can't give you low-level example right now (i have done it as well some time ago, but can't access to it right now), but, i think that AHI doc a bit dated. I.e. it saying like "for sounds better use blablalbal", but its just not take in account that none single app should blocking anything , and even 100 sounds apps should works at time. I think that docs was done a bit like "bang the", and meaning by itself some rare retro CPUs/classic amigas when saying "better use low-level interface". For our current machines worring about 100% not noticed anymore speedup, and loose because of it ability to use any music app together with your code make no sense imho. And actually, even on on 060 cpu and a1200 it already (back in years) was make no sense to worry about low-level interface when it comes to games/demos/mags.

Btw, i never like that strange logic of AHI interfaces: low-level there mean not like something very low-level and OS deep, but as AHI low-level only (but for the os, its more hi-level). I.e. low-level should be called hi-level, and hi-level should be called low-level, because as in my example (which in reality ahi-hi-level), we use deep ahi structs and OS functions like DoIO (or SendIO/WaitIO if need it), but with case in low-level by AHI meaning, we use AHI only functions like AHI_SetSound(), AHI_SetVol() (which in theory sounds like hi-level).

In end of all i just understand for myself, that better use hi-level-in-terms-of-ahi-meaning interface, and so all will works fine all the time :)

@alfkil
I also do some tests back in the pasts, in which i test: paula, ahi-low-level and ahi-hi-level mod players, on my old 060/66mhz. Of course players was a bit different: for Paula mod player i use ptreplay.library (which are direct access to CIA and stuff), for low-level ahi player i use srcsby Ronald Hof, Timm S. Mueller and Per Jo hansson , and for the hi-level ahi player i use ptplay.library (which are based on the same Ronald's and Co depacking routines).



So, even on 060, difference was not so big beetwen hi-level and low-level interfaces, but, in case with hi-level : mixing of sounds/musis and many apps is possible. Difference is so small for todays, that on our cpus it will be never noticable. Only can be "a bit" noticable on old classic machines, but for us difference in few ticks make no sense imho. Even on 060 it was already "fine enough", for making normall sound apps which block nothing. In other words, you can not worry about low-level ahi interface, only if for learning purposes :)

It is possible to use low-level interface without interrupting other processes. The device.audio driver comes for that purpose.

However the low-level interface is meant to play music. The sounds can be played with high-level interface without problems so use Kas1e's example in that matter.

These steps will allow you to use low-level AHI functions:
- Create message port and AHIRequest with appropriate functions from exec.library.
- Open the device with OpenDevice() giving AHI_NO_UNIT as a unit.
- Get interface to the library with GetInterface() giving as the first parameter io_Device field of IORequest.


Once you get the AHI interface you can use its functions. To start playing sounds you need to allocate audio (optionally you can ask user for Audio mode and frequency). Then you need to Load samples to use with AHI. You do it with AHI_AllocAudio(), AHI_ControlAudio() and AHI_LoadSound().



When everything is set up you can use the functions AHI_SetVol() to set volume, AHI_SetFreq() to set frequency, AHI_SetSound() to play the sounds.

As for M68k you don't need to convert these functions to M68k as there are working assembler examples in AHI developer's archive.

I'm writing the source code by hand so sorry for mistakes ;)

@RNS-Amiga-Club

Thanks for the info, I will try and test very soon. From what I can read right now, this is pretty much as far as I got with my assembler test app, which failed to play any sounds. Do I need AHI_SetSound to actaully play a sound? I'm asking, because this function is not defined in the autodocs, and therefore I do not know which register to put the arguments into. A full autodoc (with assembler registers) would be very helpfull.

@kas1e

Very interesting test! I hope you are right about the "not-too-large" overhead theory of yours, because I'm probably going to use the "highlevel" routines for all the sound in the game. A question, though: You are using a seperate process to play the sounds. Naturally I want to be able to play several sounds at the same time inside the game. Do I _really_ need to start a whole new process for every single sound I make?? Because that is for sure going to give a lot of system overhead! Is it possible to play more than one sound at once using a single call to OpenDevice, or do I need to open it up, say, 4 times and the count the times I call CMD_WRITE??

@alfkil
Quote:

Yeah, go this route of course. There will be no problems with it at all, and in general, will be cool someday just remove low-level ahi interface from os4-ahi at all, or maybe do something, just to have only one interface which works fine all the time and allow everything. But currently hi-level is the way for everything imho.


Quote:

There i can't help normally, because i do not know, but just from my small understanding of today's speed of our HW and cpus, running tons of process for every single thread (or even per 10 thread on one sounds) will give no problems (imho of course), and such kind of overhead can be noticable only on zx-spectrum with 3-7mhz cpu, but not on 300mhz-1ghz cpus.

I play stuff over new process just because i found its better to make for music/sounds different processes, which will works in backgorund and not give problems to main programm.

For my prods i just use hi-level ahi interface, which have different process for each music/sound, and , even on 060 with 66mhz (which slower than any slow PPC) all was fine. Music plays, in this time sounds plays when need it and so on. I of course not trying to play 4 sounds right at one time, but imho should be no problems ..

Quote:

As i understand you can just one time setup ahi (open the stuff i mean), and then just only fill/clear ahi structs and do DoIO when that need it.

@alfkil

Quote:

No, you really don't. I have no idea why kas1e does it in this weird way using DoIO().

For better idea of how you can play multiple sounds at the same time using AHI high-level interface you can look at some code I wrote for MissCmd game:
http://dl.dropbox.com/u/26599983/audio_ahi.c

The idea is to create several iorequests and then when you want to play a sound you pick one that is free and then simply start CMD_WRITE to it with BeginIO() and then mark the iorequest as in use (ch->busy field in above code). What the SoundIO() function does is check for replies from ahi.device that some iorequest has finished and then simply marks them as not in use any more. If no iorequest is free the PlaySnd function simply interrupts the one that has been playing for longest with AbortIO()/WaitIO() and then reuses that one.

The code is somewhat dated in that it doesn't use AllocSysObject()/FreeSysObject() for the msgport and iorequests and slightly ineffective in that it does OpenDevice() for each iorequest instead of using ASOIOR_Duplicate tag of AllocSysObject() to simply create copies of the first finished one.