Issues with MPXPLAY library for SB Audigy
Issue #1
resolved
renamed from Upgrading to DJGPP 2.05
Comments (85)
-
repo owner
-
reporter
they don't seem to have a forums option on here. so this will have to do i suppose.
-
BWT is there any reason why not keep MAXVESAWIDTH to 1920? I have one machine at work with 1920x1200 LCD and it run fine there so why to limit high modes that VESA BIOS offers?
-
reporter
You need to test that it even works properly by loading a map with water and jumping into it. MAXWIDTH and MAXHEIGHT also need to mirror those values. The main reason is because 1920 is a really high almost asinine value that would need a fast computer to play it a decent resolution.
If you got a machine that can handle it and it won't crash going into the water we could possibly add more modes...
-
repo owner
try it, test it. and tell us what card does VESA modes that high!
Of course the software renderer was never meant for resolutions anywhere near that high..
-
I ran it on nVidia Geforce GT 210 (very low end card) and core i5 750 and it ran smoothly (real DOS of course). On LCD it's always better to use native mode than interpolation. I played 2 or 3 singleplayer maps (swimming in water too) and didn't find any problem. At home PC I have native 1600x1200 and it makes 103 FPS and also works fine. So I see no reason why fear hires modes. BTW nvidia currently use dynamic VESA mode table so it means that for different LCD attached you get reported specific VESA modes.
-
reporter
The only other potential issue is raising the values this high will make the locked memory at startup possibly slightly larger. 32MB might be required from here on out.
I'm also a goofy-ass purist who tries to run this stuff on P1 and P2s. But everyone else wants to try it in DOS on modern stuff. Anyways, I'll add it.
-
Please add -std=gnu90 to your CFLAGS in makeo2a.frank and wattcp's djgpp.mak so it will be e.g. CFLAGS = -g -Wall -O2 -std=gnu90 It definitely cure the ntohl etc issues caused by diffenet inline behavior in gcc 5.x - it seems that 4.8.4 use gnu99 and 5.x use gnu11 by default taht is problem because inline is not enough and needs gnuinline attribute. So forcing gnu90 is the easiest way to fix it. I just tested and it works for both ver.
-
About memory - cwsdpmi supports paging so all other mem can be swapped if no enough phys RAM. I'm going to boot my old PPro 200 to see how fast it will be :)
-
reporter
I will try out the gnu90 later. We're currently just using 4.84 like you hinted at earlier. I added the res modes upto 4000x4000.
-
So I run it on my Pentium Pro 200 MHz, 192 MB RAM, SB AWE64, Matrox Millennium II MGA 2164WP s 4 MB WRAM and got 7FPS @1024x768 while only 5,9FPS in windows version (WXP SP2). 640x480 is quite playable. Sound via AWE works fine. I also tried to rebuil my FFMPEG DOS port as heavy test of djdev 2.05 and other recent updates and didn't find problem.
-
reporter
regarding your pentium pro. download fastvid (check readme for link) and run that to enable the linear frame buffer options. I can get about 20-30 fps on a P1 166 @ 400x300 with this.
-
reporter
Please note that fastvid is only going to work on P1, PPro and P2 era chipsets. It has no effect on anything newer.
-
Sure, I even programmed my own utility called MTRRLFBE to enable write combining cache mode over LFB region. This is not the issue because I can measure ~85MB/s in my VESATEST (on my site http://rayer.g6.cz/programm/programe.htm ). The reported FPS I got from demo test: timedemo 1 demomap demo1.dm2
-
reporter
That's pretty cool. Is it possible to add it into Q2DOS eliminating the need for the utility? If so, you're welcome to fork and make a pull request when it's finished.
-
Currently not, I have messed with code for quite a long time and not finished yet - there's several problem on some newer machines that they set MTRRs wrong way creating whole 4GB region (or some other smaller overlaping regios) that overlaps LFB and so disable WC (as WC has lower priority to WB or UC) so I need to make some mechanism for "sanitizing" MTRRs to not collide.
BTW you give up the new soud lib? I think it was on good way as it detected by SB Audigy 2 and even play some chopped sound in game menu but crashed when load new game....
-
repo owner
I got the intel HDA to work in Qemu. I have to rebuild my VMware server (non related) tonight, but I'll get to try it as I'm in the office with my Xeon box.
-
Well, I could test on Realtek ALC888 then... BTW good job with fixing warnings, looks much better now :)
-
repo owner
Tested on my Xeon E3-1230 3.3Ghz Z87 board, with an Nvidia GTX 760. I'm getting 42fps at 1280x1024 500fps @ 320x240 (VESA) and 333 fps on VGA mode.
It's crazy smooth, and it's just a bummer there is no packet drivers or ODI/NDIS2 drivers for this crappy 'killer' network card.
-
Hm, 42FPS... not sure if MTRR WC properly enabled... Try to run http://rayer.g6.cz/1tmp/mtrrlfbe.zip mtrrlfb lfb wc /d and send me the regs printing What 'kliller' network card do you have? I have Realtek 8111D and Realtek provides DOS drivers for all their 1gbit models. Aso intel supports their 1gbits: https://downloadcenter.intel.com/download/4239/Network-Adapter-Drivers-for-MS-DOS- On older MB I had Marvell Yukon and it also had dos driver. There are packet and odi drivers - both can be used there are various convertes. I use old MS TCPIP stack.
-
BTW I tried some more optimizations for PPro but it didn't bring up any fraction of FPS. Positive is, that it run even with -O3 that sometimes break something. My CFLAGS: #CFLAGS = -g -Wall -O3 -std=gnu90 -frerun-loop-opt -finline -ffast-math -fomit-frame-pointer -march=pentiumpro
-
repo owner
i have this crappy msi "gaming" z87 based board with an alteros ethernet chip. Its the smallest one so a PCI nic is sadly out of the question.
Im just amazed the sound worked, and it wasnt the SVGA VESA thing all over again where it runs fine in emulation, but not so fine on iron.
-
reporter
It's recommended to not change any of the cflags because the game relies heavily on floating point operations (especially for the software renderer!). I've noticed playing with those flags can cause very subtle quirks in rendering issues or stability.
-
Frank OK, I just played if it makes some speed difference on that old machine. No effect, I removed it...
Jason You still can push some cheap PCI/PCI-E x1 NIC to your MB :) Is the HDA support in current tree? It didn't detected my realtek (master, yesterday).
-
repo owner
i can test in a few hours.. you should need the "—hda" flag.
Frank, thanks for pushing everything up to master! Q2dos is seriously kick ass!
-
Aha, -hda option was not mentioned :) Cool, it works almost fine on my SBA2, except there are short glitches at end of samples in 44kHz mode - mostly noticable when walking through menu the hit sound makes some pop/clicks. In the game it's less noticable. At 22kHz it seems to be OK, maybe sometimes lagging a bit (eg. machine gun shooting but maybe it just feels so). The real issue is that when I change sample rate or 8/16b mode 3-times it always crash. It doesn't matter what sample rate I select but only the count of changes. eg. 44->22 OK, 22->11 OK, 11->22 crash... But anyway it's huge progress that I hope will help to port the new sound engine also to QDOS, Hexen II and other games. DOS will not be silent anymore :)
-
reporter
The HDA driver is not tested very well and I can't do much work on it because I don't own the sound card. The biggest issue is that the values are currently hardcoded and are not reacting to the cvar changes. It's probably causing buffer underruns or overflows and hence the crashes.
You're welcome to try and improve it and submit a patch. Beyond that, I can't do very much for you currently.
Frank
-
Hi, how did you compiled the libau? I got too many errors: http://rayer.g6.cz/1tmp/libauerr.txt Do I need to install some extra package to my DJGPP? Seems like it doesn't recognize _asm (should be used asm instead for gcc) but not only this error...
BTW, yesteray I played with Ruslan's QDOS and ZDOOM with HDA support. When I tried to recompile qdos I run in several troubles resulting FS corruption so I just give warning. Dou tou use nearptrenable? If so I think it'd dangerous and rather should be used some mapping function to avoid this evil. Here's my FWD from BTTR:
Yeah, I must admit there are some issues. E.g. watcom/pmodew crashes on my machine. But I observe it's not uncommon that pmodew doesn't like with Jemmex (at most on my PC)... DJGPP version of Zdoom was quite playable, I didn't need map in first episode :) It played nice on my SB Audigy 2 in 1024x768 with mouse enhancements. But I have trouble with Ruslan's Quakedos. I recompiled it with -O1 as he has in makefile with gcc 4.8.4 and it crashes when you select New game. So I relaxed to -O0 and it plays then but crashes at exit to DOS. And even, it messed my FAT16 FS! Some crashes cause only temporal mess up e.g. when you tyope dir you got total garbage but after hardreset it booted and FS seemed to be OK. But then I got heavy mess up of entire 2GB C: partition (game was ran from different one I:\QUAKE) and I have to restore backup because directory structure was gone. After some time I got an idea what could happened - I use UIDE with it's large cache. I suspect that program crashed so hard to hit the cache area. If it use __djgpp_nearptr_enable() it can be very evil because it makes protected mode unprotected. So when I do hard reset, the cache couldn't flush to disk and FS leaves untouched by angel of death but when I do crtl+alt+del it probably write corrupted data to HDD. Binary provided by Ruslan seems not tend to crash, probably he used some old gcc. Anyway its not excuse for abusing __djgpp_nearptr_enable() that's potentially dangerous...
-
-
reporter
just for the record, the game runs djgpp_nearptr_enable itself in dos_v2.c and never uses djgpp_nearptr_disable anywhere in the entire Q1 or Q2 DOS code.
The game is running with those unprotected but see this http://www.delorie.com/djgpp/doc/libc/libc_141.html
"If using the Unix-like sbrk algorithm, near pointers are only valid until the next |malloc|, |system|, |spawn|, or |exec| function call, since the linear base address of the application may be changed by these calls."
So they may only be valid until something happens, since Quake using sbrk.
And again, I really can't help you with this one because I don't own the card or the hardware. Try running in pure DOS with no emm386 and if you require a cache run with smartdrv /x. I stopped using UIDE because it was corrupting write behind cacheing in some games (Quake 2 was one of them). Running with no emm386 and smartdrv /x allows me to play it on that particular machine with good speed and no random lockup issues.
Frank
-
reporter
I just recompiled the entire game and uploaded it here: https://bitbucket.org/neozeed/q2dos/downloads/Q2DOS_EXE_LATEST.7Z
From now on this will be the latest link instead of having to delete old 7zips in the downloads section.
-
-sezero Yes, updated sources of libau compiles with some warning (mostly about types) but without an error, OK.
-
Are the warnings serious? If yes, I'd like to fix them. (I remember that there were some printf format string warnings which I didn't bother)
-
Nothing serious, here's my w-list: http://rayer.g6.cz/1tmp/libauw.txt most caused by incompatile types unsigned int vs long int or long unsigned int and some unused variables. I always prefer to solve all warnings to easily see if some new potential dangerous warning will occur.
-
Frank, I think it would be better to djgpp_nearptr_enable() for only short block of code that needs it and then back djgpp_nearptr_disable() it. Or does some other library needs to leave it enabled? Always it will be better to use dosmemput() or movedata() instead... Yesterday I made some more testing on ZDOOM and different configurations, posted in thread: http://www.bttr-software.de/forum/forum_entry.php?id=14339 Sure I can disable UIDE but then my disk read/write speed drops ~10x times. I hope that UIDE is well written as its developed for long time but it cannot be imunne if some program stars to blindly shoots in memory that doesn't belong to it. I use UIDE for many years and I don't have such problems, neither with your Q2 port.
-
repo owner
The audio code counts on it being unlocked.
-
I can confirm that sound works also on Realtek ALC888 HDA on my machine at work :) (with remainning issue that multiple change of samplerate cause crash but it's usable)
-
I clean up the warnings from libau, nothing serious found. I cannot commit online so upload here http://rayer.g6.cz/1tmp/libau.src.zip I also found that there's already an option -DZDM to disable nearptr but when I recompiled Q2 this way it crashed at sound init. so there's something rotten in the code. So I reverted back to use nearptrs... Maybe I try to debug later when have some more time...
-
reporter
The actual Quake code itself never disables the nearptr. The sound code is set up this way. I also believe it's automatically re-disabling since it's using sbrk algorithm.
-
sezero, I think that DJGPP provide wide range of DPMI wpapper functions in dpmi.h and similar headers so maybe it could replace the entire assembler blackmagic in dpmi_c.c... I mean code blocks ending with asm("int $0x31"); - this should be DPMI API call and there should be nice C functions to do it more clear way.. UPDATE, I mean e.g.
void pds_dpmi_dos_freemem(void) probably do the same as int __dpmi_free_dos_memory(int _selector); / DPMI 0.9 AX=0101 /
struct dosmem_t pds_dpmi_dos_allocmem(unsigned int size) probably do the same as int __dpmi_allocate_dos_memory(int _paragraphs, int _ret_selector_or_max); / DPMI 0.9 AX=0100 /
unsigned long pds_dpmi_map_physical_memory(unsigned long phys_addr,unsigned long memsize) probably do the same as int __dpmi_physical_address_mapping(__dpmi_meminfo _info); / DPMI 0.9 AX=0800 */
void pds_dpmi_unmap_physycal_memory(unsigned long linear_addr) probably do the same as int __dpmi_free_physical_address_mapping(__dpmi_meminfo _info); / DPMI 0.9 AX=0801 */
-
I believe the replacement would be _go32_dpmi_allocate_dos_memory() and yes it is similar to what quake1's dosv2.c does. Unless it is faulty though, I believe we can keep the asm as is.
I didn't even try the pci snd code myself: If I want to do that, I'd have to setup a dos machine with my au8830 card (diamond monster sound) and add support for it first.
-
I just compiled libau with and without DZM and going to try make some sample code using the library and check if DZM version crashes...
-
And if I remeber well,
_go32_dpmi_xxxfunctions should be really direct DPMI wrappers while
__dpmi_xxxcan do a bit more...
-
reporter
- changed title to Issues with MPXPLAY library for SB Audigy
- marked as bug
- edited description
-
I found there's optimization problem in libau with newer GCC! When I compiled the libau with -O1 and make simple test program that just call AU_info=AU_search(0); it instantly crashed and reseted my PC (SBA2). When I changed to -O0 it doesn't crash (regardless if DZM or without) but I'm not playing a sound yet. This would need some clean up and find the badly written code, I could try if find something...
-
Does the precompiled version in git exhibit the issue? (it is compiled with gcc-3.4.6 and binutils-2.25). Specifically what compiler version is the issue with?
An yes, we'd very much like a patch.
-
Yes, version from your repo works if I link my program with it. Even worse, my compiled version crashes only on my home PC with SBA but not at work PC with realtek ALC888. Crash doesn't depend on what memory manager used or without it. Maybe vome volatile shoul be added to to asm, I always use.
__asm__ __volatile__ (...)to prevent any optimizations by GCC in asm code. I'll try later. I use gcc 4.8.4 nad djdev 2.05 on both PCs.
-
I see. I just tried compiling with gcc5 with and without adding volatile to asm, and the object files were the same. I don't know how things would be with 4.8.4.
-
Hm, unfortunately this kind of bugs are hard to search. I had similar problem with Ruslan's QDos, where -O1 crashed but -O0 too, only later-at exit. Sometimes there's needed to use volatile class for variables that are asynchronously changed - commonly if a global variable is changed from an ISR and main loop check this variable. But there are more case and I'm not an expert about this... :(
-
BTW to help debugging it is possible to use some #pragma to locally change -O flag for a block of code inside #pragmas. So it's possible to narrow the area and better localize where the hell rises. One time I used it and it was some problem in inline asm function...
-
reporter
also though AU_Search is passing wront types (right now a char array but should be I believe a uint). But, I don't think that would be the cause of this particular crash?
And yes, the dma buffer in Quake uses volatile. It may be worth at least setting au lib's dma buffer to volatile as well.
Frank
-
As I can see AU_Search just returns pointer to global var libau_istr that is char aslo, so I don't see problem. I cannot find a volatile keyword in entire libau source so maybe needed to add somewhere...
-
reporter
I'm saying a good place to start with the volatile is changing the buffer to volatile. It really needs to be as such.
Frank
-
In latest version I cannot set 1600x1200 VESA mode anymore. It's listed in supported modes in console on start-up but cannot be set via video menu neither it was not set from my config (i renamed my old config to q2dos.cfg).
-
reporter
Can you manually set it with vid_listmodes then running sw_mode?
-
reporter
Also you can reuse your existing config by typing exec config then type writeconfig to dump it back to q2dos.cfg
-
Sorry, I was confused by modes order in video menu (1280x1024 followed by 320x200 so I though it repeats). But worse, I experienced crash when diving into water e.g. here http://rayer.g6.cz/1tmp/quake04.png (the map from your network server) but also in map1 singleplayer in the canal... When I float up and down and shooting the crash will come in a while. I can repeat it quite easily. I have one older Q2D binary from 1.7.2015 that seems not suffer this problem (I couldn't force crash it during some minutes floating in water).
-
reporter
Knightmare's FOV fix might be removed now or re-implemented wrong which could be causing the crash. It had some specific code for water warping at high resolutions.
You could try building your own and reverting the FOV and let me know what happens.
-
reporter
err reverting the aspect ratio/fov code that is
-
I pushed commit aba4a2d in an attempt to fix the underwater crash: does it help? (also uploading a binary for it at the moment.)
-
OK, I'll check later, going to work now...
-
It seems to be fixed in latest version. I was unable to crash it in water like before, tested ~15min in 2 different maps.
-
That's good, thanks for testing.
-
This thread was hijacked a lot, so let's make a summary for the actual subject:
- What is the current status of the PCI audio code?
- Which parts are tested and which parts are not?
- What is the experience?
- Rayer: were you able to pinpoint the miscompilation issues with new gcc?
-
Basically libau works but there are some issues: - on slower CPU like my NTB with pentium M Dothan 2GHz and ICH4-M AC'97 the sound is choppy - on faster CPU like my C2D E8600 or C i5 750 it plays quite smooth during game at 22kHz - when sampling freq. or sample bits is changed in options menu for 3-times it crashes. - I tested (and can test in future) on 3 soundcards: SBA2, Realtek ALC888 and ICH4-M AC'97 I can also reproduce crash on simple sound example playing a tone from static buffer when using gcc 4.8.4 with -O1 (while -O0 works) but it happen later after init on my NTB (ICH4-M AC'97). I tracked it to call of aui->card_handler->cardbuf_clear() in AU_start() Sorry I'm quite limited with free time as I work on full-time and have other duties than debugging the code but I'd like to return to it and try to isolate it and maybe fix that bug...
-
on slower CPU like my NTB with pentium M Dothan 2GHz and ICH4-M AC'97 the sound is choppy - on faster CPU like my C2D E8600 or C i5 750 it plays quite smooth
A slow cpu is like PII-300 MHz, so yours should count as fast and that choppiness not nice at all.
I tracked it to call of aui->card_handler->cardbuf_clear() in AU_start()
That's good to know. I'll try eyeballing around those places
-
reporter
Keep in mind in the MENU code I have it basically capped at 96khz. If you enter that menu and change things it might cap to 96khz (which it looks like in the audigy code in libau it's trying to default to 192khz for some things) This might be part of the problem. Have you ever tried setting s_khz manually via the console and running a snd_restart?
If it works that way then my menu code needs fixed a little.The pentium M may get choppy if it's switching into a low power mode.
Have you tried disabling any kind of power saving features via the BIOS?Frank
-
reporter
Any thing new on this?
-
Sorry I'm still busy, I even didn't try new version quite long. BTW I readed that you added 3Dfx driver :) On my NTB I have soundcard capable only 44 or 48kHz. When power adapter is plugged in it runs at maximum clock speed (2GHz) under DOS so it's not PM saving issue. Under Windows it can go down to 600MHz when on battery.
-
I made several api changes to libau, fixed a misplaced break statement in it, and made it to compile and be used as a dxe module. Also, q2 must be run with -sndpci command line switch for pci audio to be used (previously it was -hda and was undocumented.)
If you want q2 to use it as a dxe, compile q2.exe with SNDPCI_DXE=1 on the make command line (or edit the makefile.)
I'd like to hear the user experiences and whether any of the old reported problems still exist.
-
Hi, after some months I tested Q2DOS again. 1st I was curious about 3Dfx accel. that I successfully tested on my Pentium Pro with Voodoo1. I just wonder that I measured the same 12,6 FPS (timedemo 1, demomap demo1.dm2) as with VESA driver (at same res. 640x480) but of course 3Dfx makes better hicolor and bilin. filt. image quality. Sound on SB AWE64 was OK on lower fs. On main PC it works as usual, still remain the crash issue when I change fs in menu 3-times but I don't care much. On notebook it's still very choppy regardless used fs (11/22/44k tested). I run on AC adapter and checked running at 2GHz. The sound looks like 1/2s plays OK and second 1/2s it's silent while graphics move normally. Maybe it's 1/4s interval or so but it's quite constant, not random or load dependent (same in static scene like under movement). -O1 still cause crash with gcc 4.8.5. BTW do you have some simple wav player using libau as test program that I could run to check - if it plays continuously outside Q2?
-
reporter
You could try the program it derives from... MPXPLAY (check readme for website) and see if problems persist there if you recompile it from source.
Voodoo 1 is a rather useless card for Q2 unforunately. I put one of these in a P2 machine and later a P3 machine and got the exact same results on timedemos so they hit a CPU wall pretty quickly. A Voodoo 2 (or ideally a V3+) is ideal.
PPro probably is limiting it as well. You could try a Voodoo 2 in the same box and see if the results change. I tried it with a Socket 7 P1 200 MMX processor with a Voodoo 1, 2, and 4 PCI cards. THe voodoo 1 was slower, maybe about the same framerate (but I don't recall the exact number offhand) and the Voodoo 2 and 4 got the same numbers between them... because of the CPU limitation. Later on, I tried the Voodoo 4 in an AMD64 3200+ and got some really nice results there. So, they are scaleable. But, only the later generations and the V3/4/5 series really benefits from running fastvid or your MTRRLFBE utility.
I did also notice your MTRRLFBE utility gave me better results compared to fastvid!
-
reporter
Also, you can try and see if raising the snd mixahead CVAR to a higher value might resolve your stuttering.
-
Yes I use mpxplay on this NTB without problem. I never tried to recompile it, I don't have setup OWC building env.
I don't have other 3Dfx that the old Voodoo 1. But I remeber that I was playing Q2 under Win95 with V1 on Pentium 200 and it was quite well playable. I also played Unreal on it. V4/5 is quite rare now...
I don't know what all Fastvid do, my program just set one variable MTRR to LFB region in WC mode, nothing more. I have new version under devel. that would better handle other conflicting MTRR settings, but time, hope I release it one day... :)
-
reporter
Yes. V1 will be slower in DOS. Mesa and Sage both seem to have some slowdowns with larger outdoor areas compared to Windows. I think the last time I tested Voodoo 2 under Windows on the P200 I was getting barely 25-30fps in timedemo demo1 and under DOS it was like 18fps.
-
Maybe it would help to set MTRR-WC also for some V1 memory area to improve data transfer from CPU to V1 buffers. I don't know much how V1 works and what is the structure of V1 memory mapped block. MTRRLFBE supports to force user memory range by base-size arguments so you can try if it would have some effect but it may also corrupt the data flow. MMIO registers shouldn't be cached.
-
reporter
That's up to you to see if it's a feasible option. Pentium 1 boards don't support MTRRLFBE or fastvid utility. However, on my BX440 boards it makes a huge difference on my Voodoo 3,4, and 5 cards. Speeds can be comparable to windows in most benchmarks, but again, large outdoor areas will be better in Windows. This includes comparing Windows Mesa DLLs to 3dfx OpenGL ICD, MiniGL, and WickedGL.
Let me know if you get a chance to test recompiling MPXPLAY for yourself with new DJ2.05 and GCC4.84.
-
reporter
Regarding V1, it's almost near a waste to get it working at an "OK" speed IMO. It can handle QDOS and QWDOS at an OK frame rate on the P200 though. It's up to you how crazy you want to get trying to improve V1 performance, but you're better off getting a Voodoo 2 PCI or a Voodoo 3 if you can find it.
The nice thing with getting a Voodoo 4 in a slower computer is that you can force Anti-Aliasing on with no performance hit because everything is CPU bound. I put the V4 PCI in that P200 box and was able to turn the feature on with about the same framerate (maybe lose 1 or 2 fps on timedemos).
-
Is it possible to recompile mpxplay under DJGPP just by selecting different makefile? AFAIK it requires OpenWatcom. As there are a lot of inline assembler and #pragmas it wouldn't easy to just recompile with DJGPP. No, I don't want to mess with V1 now... If I would see some newer Voodoo for good price on a local flea market I would buy it :)
-
reporter
To be honest with you I have no clue about mpxplay's inner source code workings. At some point, someone emailed me and neozeed saying they added PCI sound to QDOS with parts of the mpxplay sound pci library. Source was included (after much teeth pulling). I always assumed it was a DJGPP project.
May be worth comparing the original mpxplay source to this libau maybe he missed something...
-
No no, as it's stated on top of mpxplay homepage: http://mpxplay.sourceforge.net/ "Mpxplay is a commander-style console audio player for DOS and Win32 operating systems, developed in OpenWatcom C v1.9 " and AFAIK Attila took his PCI driver sources from linux OSS tree. I don't know who made libau from mpx to djgpp, I knew only about WSS and Judas DJGPP libraries that supported newer snd...
-
I added support for -sndpci to uHexen2, new version is soon to be released. Source and dos latest binaries are here: http://uhexen2.sourceforge.net/devel/
source: http://uhexen2.sourceforge.net/devel/SVN_LATEST/ dos binaries: http://uhexen2.sourceforge.net/devel/DOS-SVN/
If anyone can test and provide feedback, it would be great.
-
Hi, cool! I did a quick test on my new machine (core i7-2600k OC 4,5GHz, SB Audigy 2 remains), I keep 22kHz as default. Sound seems to be good same as in Q2. But I have other performance issues. 1) when go to menu during the game it slowdowns to 1-2 FPS and so navigation in menu is uncomfortable and sound is a bit choppy. If I enter menu just after startup before start/load a game it navigate smoothly without problems. 2) during play when I come close to water or other translucent object like a teleport it slowdown siginificantly to a few FPS. 3) mouse wheel mapping is some way messed with middle and right button - I cannot assig different action for each. Pressing mid button do same action like wheel down... Also right button sometime behaves like wheel move in control setup But this issues was probably there in Hexen2 before you added the sound code... I tried without -sndpci and it had same problems.
-
sndpci library (libau) is updated a lot, and the brokenness in optimization levels > 1 is fixed. I could only test functionality with two sound cards (CMI, and - if I recall correctly - SBLive) and Intel HDA is not among them: Any new sndpci issue report must follow a patch to fix it from now on.
Closing this ticket now.
-
- changed status to resolved
- Log in to comment
so this is like their version of a forum or something, right?