Hi, I had this problem as well - if there is anyone listening who has the solution or knows exactly what Red Hat did, I'd love to know... As far as I can tell (having come across this problem a couple of days back when I upgraded 2.0.35 -> 2.0.36) it is a rather old driver - a modified 0.4.2c - that is included by Red Hat. Unfortunately the inclusion of the driver breaks the install-rh.sh script so that neither 0.4.2d (which I was running with 2.0.35) nor the current 0.4.3 will compile in using the script. I don't have a "clean" 0.4.2c to compare against, but there are actually very few differences in the code between the 0.4.2d and the RH 2.0.36 lowlevel drivers; the main one that _looks_ significant is that although the modular sound is based on OSS x.8, in awe_compat.h it looks as if it has to be treated as a pre-x.8 system. dropping 0.4.2d in by hand or using the install-rh.sh script generates a tree which wont compile, with some really bizarre things going on in awe_compat.h (the compiler error messages imply it is getting some definitions for the compatibility code that dont make sense to me looking at the #ifdefs. I admit that while I have been doing C-coding for 5 years, I have never dealt with device drivers before) Changing the #ifdef that was tweaked by RH (to include _AND_IM_A_BANANA if you want to look for it) produced a module that would compile, but produced a non-fatal (ie the system kept going) OOPS when I inserted the module and ran sfxload. Having whined about the midi non-playing, I should also say they have done a much better job now with the concept of including the driver in the base install, and sndconfig (which even at 5.1 was a significant hassle to deal with) not only detected the PnP card and that it was an AWE32, but also generated a working isapnp file for the sound card and my modem (it used to not uncomment anything) and a consistent conf.modules file. btw the version of drvmidi I have is 0.4.2 also, which ran fine with RH-2.0.35 and AWE-0.4.2d Tim Henstock
