Koolyo

Well, here comes the promised bug report

When the user chooses the "Settings/Reset Settings" from the system's tray Kx Menu, and hits yes on the MessageBox that just appeared, 3 out of 4 of the buffer setting gets reset, the Tank Memory Size Entry remains unchanged. Well, that is not entirely true.
The code does indeed tries to reset the Tank Memory Registry Entries and reset it's size via the kx.sys driver, but it is doing it the wrong way.

The reason for this in the 1st place, ( as you already know i am sure ), is that when the user set's the Tank Memory size in the "Setting/Setup Buffers" the KxMixer doesn't write the selected value in the registery until the KxMixer actually closes ( or the user chooses to reset the settings, more on this later). In fact, the TRAM memory size is sent and set via the "DeviceIoControl( hDevice, CTL_CODE(FILE_DEVICE_KS,.....)....) directly to the driver each time the user changes his selection in the TRAM Size Combo Box, not when the user hit the "check/OK" button to discard the dialog as one might expect ( that in itself is another story).

You can easily verify this by changing the value on the TRAM ComboBox, Killing the process without hitting OK, and then relaunching the KxMixer/Setting/Setup Buffers, and you find the value you last selected on the combo box before killing the process. If you go in the registry now, you can see that the key \kx\config\[YourCard]\buffers\tankmem is set to the correct value, you might be wondering how come it is correct if you didnt actually "close" the KxMixer but rather killed it. It is actually pretty simple.

Upon Startup, a code section communicates with the driver to get the TRAM size, and sets it in the registery, thus making the registery entry correct. You might then ask yourself, "why then the entry doesn't get reset every time on boot, to reflect actual hardware TRAM value since the TRAM value is not kept after powering off the PC", well here is the trick: If kxmixer.exe is run with the "--startup" parameter, then instead of reading the value from driver and setting it in registery, it reads the value from the reg and sends it to driver to be set, which is pretty nifty If the tankmem regKey is not present with the --startup param, then the KxMixer will show a legacy warning and reads the hardware TRAM Config and create the key. Btw, upon Boot, the default TRAM size is 256KB.


While one would expect then that the reset menu entry will reset the TRAM Buffer to Hardware default ( 256KB in our case ), what the code does now, is that it queries the driver for the TRAM Value, stores it, and rewrites the registry entry with the TRAM read by the driver!
So if i have a value of 512K, then the driver will retrun 512KB ( current TRAM ) and the application will overwrite the registery key with that value, thus resulting in no reset at all!

I can see why you guy got this problem, since you cannot know exactly what default TRAM is, you cannot reset it to it's original value ( 256KB ) in our case, and you don't want to hardcode that 256KB in.
What i would suggest is a new DWORD Key "default_tankmem" that is set upon startup and before applying the user selected "tankmem" regkey value to the TRAM size, and that the "Reset Settings" will use to reset the TRAM Value to it's freshly rebooted value ( 256KB in our case ), which would fix the current situation/dilemma.

Ouf! that was one heck of a long post! If you didn't follow everything, don't worry, Eugene did

Eugene Gavrilov

a much larger report this time

however, the reason for such behavious is much simplier
the driver [kx.sys] simply doesn't reset the Tram size on receiving kxmixer's "Reset Settings" request
[*intentionally*]

so, when a user clicks 'reset settings', the mixer asks the driver to reset them
the kernel-level part resets the buffers, the DSP, ac97 codecs and so on, but doesn't reset TRAM size

after resettings settings, kxmixer performs 'save settings' procedure, and saves the present [new one] settings into the registry. of course, the TRAM size remains uncachanged

note that the registry is used by kxmixer only
on startup ('--startup' option) kxmixer loads the settings
it saves them when kxmixer window is closed, when kxmixer is unloaded, when the settings are reset and in certain additional conditions...

why isn't TRAM size reset? well, it is a long story
the main idea: the TRAM settings require memory re-allocation. the memory is allocated in kernel non-paged space, so, re-allocating it many times might cause serious memory fragmentation
during the development, it is required to save/reset/load settings many times [as well as load/start/stop the driver], so, it was decided to keep the present TRAM settings to avoid frequent reboots

/Eugene

Koolyo

>> a much larger report this time
I am taking that as a compliment

>>so, when a user clicks 'reset settings', the mixer asks the driver to reset them
>>the kernel-level part resets the buffers, the DSP, ac97 codecs and so on, but doesn't reset TRAM size
>>after resettings settings, kxmixer performs 'save settings' procedure, and saves the present [new one] settings into the registry. of course, the TRAM size remains uncachanged

Yep, that is what i have noticed too, it is being reset to the same [current] value.

>>note that the registry is used by kxmixer only on startup ('--startup' option) kxmixer loads the settings it saves them when kxmixer
>>window is closed, when kxmixer is unloaded, when the settings are reset and in certain additional conditions...

Yep, i mentioned that too

>>why isn't TRAM size reset? well, it is a long story the main idea: the TRAM settings require memory re-allocation. the memory is >>allocated in kernel non-paged space, so, re-allocating it many times might cause serious memory fragmentation
>>during the development, it is required to save/reset/load settings many times [as well as load/start/stop the driver], so, it was >>decided to keep the present TRAM settings to avoid frequent reboots

Ok, does that mean that in a "release" ( or final, call it what you would like ), you guys will actually reset the TRAM Buffer as well?
What about that "change TRAM on ComboBox not on OK button", the usr will fiddle around thinking the TRAM will not be affected until he hits "OK", but all he is doing is actually fragmenting more the System's non paged Pool. If you are afraid of fragmentation, always allocate max size and use as convenient ( i know that non paged pooling is to be used with caution due to the scarse non paged resources availability )

>>the driver [kx.sys] simply doesn't reset the Tram size on receiving kxmixer's "Reset Settings" request [*intentionally*]

Oh Bummer! And i wrote this long post thinking it was a bug...I even got in a dispute with my wife becaus she thaught i was chatting with a girl name "Gene" and i used the nick "Eugene" as a coverUp coded handle.

So basically i was in the right track with my "development" part, only my conclusion was erroneous, becaus i assumed it was a bug, when indeed it was intentional. I hope i didn't insult anyone there. There has not been a moment i doubted you or your team ability or talent. On the contraire, the deeper i dig into your work, the more i appreciate it

Take Care, and can't wait for the next release to test and report bugs

>>/Eugene
/Nagi

P.S: Got to close the browser now, my wife is starting to eye me from the other side of the living room

Eugene Gavrilov

>> and can't wait for the next release to test and report bugs

great!

/Eugene