OpenAL

Would be great if developers could look further into improving this concept? Perhaps intergrate A.I generic thinking into it and add it as a higher layer being on top of AHI by extending the features of AHI? OpenAL, or in the case of AmigaOS, should be called AmiAL, could help add Delay, different types of Reverb, hardware mixing of multiple stereo panned channels, EQ, Cross Echo/Echo and different 3D audio environment settings, ideal for games. Lots of possibilities. Would be interesting.

It would be nice to have an update, the current release seems a bit untested and we noticed some problems with certain projects, for example with the porting of Woof

This one is very useful to have on Amiga, even at this stage! An important work-in-progress! Keep it up!

Sorry, wrong line number: make it 188-191 instead of "around 280"... That 280 came from my analyzing-setup :P

Hi, I got no reply so far, so I post it here as well: during analyzing LoadConfigFromFile in alcConfig.c in search for that crash again I found this: the loop around line 280: depending on (random) RAM content and config file content the loop's ending condition won't be satisfied before "i" underflows (and once it does all it may run "forever"). This happens if the config file contains a line like this: stereodup = # comment a line without a value - and such files exist, one I got from somebody with that crash contains such a line. The mem-write right after the loop is the final nail into the coffin here, since "i" may be anything now but not a valid index anymore. Fix: for example change the loop's content from i--; to if(!i--) break; Thanks!

@Daytona675x I've put up a pretty much untested version of OpenAL 1.16.0 here that you can try: https://dl.dropboxusercontent.com/u/26599983/openal-soft-1.16.0.7z

If you find any questions or problems with it please contact me by e-mail instead of using the comments here. My address is fredrik at a500 dot org.

The latest OpenAL 1.16.0 refuses to compile with as old a gcc as 4.2.4 so I had to build a newer gcc cross-compiler (4.9.1) first in order to be able to compile it at all.

@salass Thanks for checking! Yes, you're right of course, the free(NULL) is harmless on this OS. I'm definitely wrong here. Was my first idea because I used to work on OSes were free(NULL) crashs :) Sorry. Sadly I cannot provide an alsoft.conf file that crashs because it got deleted before I had a chance to look at it :( But I can give you a stack-trace at least:

[code] Crash occured in module kernel at address 0x01410DD4 Type of crash: unknown exception

Register dump: GPR (General Purpose Registers): 0: 01417DB4 589A84B0 00000000 01410DEC 598C9C40 01DAA7DC 01DAA7CC 01DAA840 8: 00000001 00000000 00000001 80000017 00000164 56CF6420 569EF1AC 569EF244 16: 569EF1AC 569EEAB4 58B2BB20 569EEAB4 56DDF03C 56DDF03C 56CEE6A0 58B2BB4C 24: 58B2C190 56DDE3E8 589A84A0 00000001 01DBDC66 598C9C40 01CA9C48 00000001

FPR (Floating Point Registers, NaN = Not a Number): 0: 0.05 1 0 0 4: 0 63.8 63.8 0 8: 438 0.0285714 4.5036e+15 4.5036e+15 12: 4.5036e+15 4.5036e+15 0 0 16: 0 0 0 0 20: 0 0 0 0 24: 0 0 0 0 28: 0 0 0 0

FPSCR (Floating Point Status and Control Register): 0x82004000

SPRs (Special Purpose Registers): Machine State (msr) : 0x0002B030 Condition (cr) : 0x56420608 Instruction Pointer (ip) : 0x01410DD4 Xtended Exception (xer) : 0x56853B2C Count (ctr) : 0x5FF924D0 Link (lr) : 0x6FB72918 DSI Status (dsisr) : 0x564203C0 Data Address (dar) : 0x015AAFCC

680x0 emulated registers: DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 FPU0: 0 0 0 0 FPU4: 0 0 0 0

Symbol info: Instruction pointer 0x01410DD4 belongs to module "kernel" (HUNK/Kickstart)

Stack trace: native kernel module kernel+0x00010dd4 native kernel module kernel+0x00017cd4 native kernel module newlib.library.kmod+0x00013ef0 native kernel module newlib.library.kmod+0x0000bf44 LoadConfigFromFile()+0x578 (section 1 @ 0x154BD0) ReadALConfig()+0x7c (section 1 @ 0x154DCC) InitAL()+0xec (section 1 @ 0x14BD48) alcOpenDevice()+0x3c (section 1 @ 0x14C5FC) _ZN2GC12SoundManager4InitEv()+0xf8 (section 1 @ 0xAFBB0) _ZN2GC11GameManagerC1Ev()+0x2b4 (section 1 @ 0x983AC) _ZN2GC11GameManager6AccessEv()+0x1c8 (section 1 @ 0x989C8) main()+0x5bc (section 1 @ 0x90B8) native kernel module newlib.library.kmod+0x000020ac native kernel module newlib.library.kmod+0x00002d5c native kernel module newlib.library.kmod+0x00002ef0 _start()+0x170 (section 1 @ 0x16C) native kernel module dos.library.kmod+0x00024bb0 native kernel module kernel+0x0003b4b0 native kernel module kernel+0x0003b530

PPC disassembly: 01410dcc: 60630dec ori r3,r3,3564 01410dd0: 44000002 sc *01410dd4: 4e800020 blr 01410dd8: 7c641b78 mr r4,r3 01410ddc: 3c600141 lis r3,321 [/code]

@Daytona675x

Thanks for reporting, I will look into this when I update the OpenAL Soft port (latest version as of now is 1.16.0).

free() on a NULL pointer should be a harmless no-op though.

Ah, well, forget that buffer-underrun issue. After taking a second look the lines 152-153 prevent that from happening. Anyway, that line 193 is no good and results in a Guru.

Lib likes to crash when parsing alsoft.conf files. Only took a quick look at the source in alcConfig.c and spotted two issues explaing the crash:

Lines 188-191: potential buffer-underrun. Check for i>=0 before isspace. Line 193: free(null)