user57

what happend to the bigger sector solution ?

i have shortly looked into that cuda/cuvid code, i expected it does set (control, output, input) - and yes it is doing exactly that it is right that a grafic card that supports a codec is needed to make use of nvenc/nvdec (or with other words if you want a grafic card doing the de/encoding you need a grafic card that can do this) what seems a missconsumtion to me is that you need a grafic-card to make a de/encoder - that is just not right the example code is totally bond to the dx9 video engine // Create the D3D object. "Direct3DCreate9Ex(D3D_SDK_VERSION, &g_pD3D)" to this point it dont look to bad for xp (dx9Ex video engine) (and in the end maps a RGB buffer to that dx9ex engine) but it can be expected there is a deeper code (inside the d3d9/11 dll), where you if you use that engine code actually dont see what it is doing there the code itself, is also mixed up some parts initialize cuda/cuvid while other gather the d3d9/11 video engine so this method use both (d3d video engine + cuda/cuvid engine) (it is mapping the cuda/cuvid engine to opengl/d3d video as RGB buffer) it would be possible that the driver simply dont have the right control code and just returns 0 or not function it could be that if the right parameters are set, that these are just not being processed (either nvcuvid.dll, d3d9.dll or the driver version) the nvidia driver either user or kernel level is closed source, makes it hard to overview and dont allow a direct controlment with high level functions (what also only do set control/parameters,input, output) for ffmpeg i looked around for the NVDEC/NVENC engine, ffmpeg use up these engines (ffmpeg is not independent) rather ffmpeg is to understand as command line that if it wants to use NVDEC/NVENC ffmpeg then calls up these engines so ffmpeg isnt doing it alone either or "just can be used on xp" the user engine/api seems to be at nvcuvid.dll what then calls a function inside that nvcuvid.dll like this: cuvidMapVideoFrame(&hDecoder, nPicIdx, &cuDevPtr, &nPitch, &stProcParams); but this is a low level function it dont tell what nvcuvid.dll (and all its followers such as the video driver) actually really do https://github.com/tpn/cuda-samples/blob/master/v9.0/3_Imaging/cudaDecodeD3D9/videoDecodeD3D9.cpp https://docs.nvidia.com/video-technologies/video-codec-sdk/11.1/nvdec-video-decoder-api-prog-guide/index.html then website for a devloper making use of NVDEC/NVENC tells us this: Software: Windows 11, Video Codec SDK v12.2, NVIDIA display driver: 551.76 this seems hard to me it tells a driver version that xp actually dont have (551.76) the SDK might be able to do it without opengl/d3d video (as cuda/cuvid maps a RGB buffer in the end, why would it have to be a opengl or d3d video engine?) but a new SDK tends to use new api sets (and here is where it says something about win11) it might actually already use win10+ apis in the SDK already the driver and the nvcuvid.dll (the newer versions) might also be used up with win11 windows api´s a real solution would look totally different we would need the high level functions that control the nvidia driver then we could set the right parameters/controlcode, input buffer, output buffer (RGB) the control code, input buffer, and the output buffer can be done in a player then that would be very os independent solution and could make use of nvidia grafic cards that support hardware de/encoding it will be exciting to see what happens now

it is for MPC-HC ? then the question apears if it play the h.265 codec i do not know specific details as "CUDA" is closed source but if i get it right cuda makes: control input, control and output so if the driver isnt doing that the grafic card isnt talked to it dont has to be a grafic card but, its a plain c code (both en and decoding) - the question raise how fast that actually runs the code written with mmx-avx instructions are very fast but for a player only the decoder would be needed https://openrepos.net/content/lpr/libde265-hevc-decoder

i dont have insight in this project but is dump_ntoskrn8.sys even part of the ACPI 2.0 driver ? sounds like a kernel extender but i do not know

what about this player ? https://www.videolan.org/vlc/releases/3.0.20.html

i personally like that you guys are writing with me i also lern the things everytime a bit more, neither where the direction goes well first to x265 you are right its rather a encoder (also rather no pictures, rather for video) this is the case because that encoder (x265) is rather using a command line for encoding (it has no command line or extra function for the oposite piece) that HEIF also rather use a command line to call x265 up ... to x265 there is its counter part called libde265 but here is the catch those libde265 routines looked pretty much the same to the ones from x265 ffmpeg is working like a command line too, just want to point that out. (you get it and you call it) so x265 should be able to be reversed to a decoder, but certainly not with a command line i looked some of the codes, names and such they are very alike but i did not study every compression method because i dont see much sence to that going with that logic, what can create that picture can also display that picture - it just has to be the reverse input (RGB buffer for example) -> output (encoder x265) -> back to input (RGB frame) if you have a good argument why that dont work i will listen (i dont think i didnt just read all the routines so exactly) i also get now why windows 10 besides the fact it use many engines over next engines still got some speed so it is right that windows 10 got a slow high language code ... and many engines that use other engines so in this case (aka win10) that slow engines are called up - but not doing the de/encoding stuff it is given to a grafic card thats why ... win10 despite the fact win10 has a very slow code .. win10 can encode/decode with enough speed a normal CPU can handle the "inefficient engines and highlanguage code" going backwards yes the idea to use a hardware unit for a software is a old idea the grafic card is doing that this time - to me it raise the question what method was used: 1: a firmware or a source code that use a "core on the grafic card" - GPU and CPU at some point are the same (rather only different schematics) 2: a pure hardware unit, a "core" that has the firmware on the hardware schematics if its 2: the schematics cant be upgraded if its 1: it raise questions to do so, you have a multicores today then we just use a other CPU and that is basicly the same (+ the XMM registers are pretty fast) quote: "Direct3D can be used to put the decoded picture on screen with acceleration: allowing to rotate and stretch it for free without using the CPU" this one i like special, that is right but that is exactly the problem that engine is bound to directx11-12 so it need this d3d engine to use the next engine (what maybe is cuda) and that is exactly the problem it are already 2 engines that maybe already are limited to win7+ therefore we cant use that with CUDA the problem seems that for XP there is no newer version = the cuda engine we have on XP dont support the controlment for the driver = we would need the control engine (aka the internal code of cuda) to control the driver (and the grafic card) then we could use a grafic card that supports the h265 de/encoding (the only question remains what version of cuda still works in XP and what en/decode modes that "newest version of CUDA for xp" support) https://youtu.be/H3AQnlpxk0c https://developer.nvidia.com/video-codec-sdk that LAV going the same direction, the LAV engine might be open source but the right question made to it are different first : it tells us a problem many dont seems to understand a engine always has a "internal code" that it uses up (this time we see it, but only that it use non xp functions/engines/apis) so using the LAV engine you are bond to what the LAV engine programmer used internal (and that is also going away from XP) the LAV engine seems not to have a very deep level either, if LAV use up DX10/11/12 its rather something to script the DX10-12 engine and the DX10-12 engine already is in favor of win7+ its not going like we use LAV and that works on XP LAV dont make the h265 encoding either its a in between engine going to FFmpeg "FFmpeg has supported NVDEC since 2017" that tells us ffmpeg already use NVDEC what at best has limited support for XP FFmpeg is a nice fork for codecs , but rather ffmpeg wants to use command lines and in the end calls up a engine https://trac.ffmpeg.org/wiki/Encode/H.265 maybe ffmpeg would be a option ... quote: "which is talked to by CUDA. OpenGL can be used to put the decoded picture on screen with acceleration" if that is right opengl4.5 still cant do it because cuda isnt doing it on xp if i follow that logic opengl4.5 calls up the cuda "engine" where it finds a outdated version - and then it would just not do its job going into a different direction the player "VLC media player" claims to work on XP and that it can play h265, and its open source do we know something here ? because open source means we can see what that player actually do we could copy paste the code too - or have our own interpratation sounds good to me that with x265 or libde265 we already had but even on x265 going with a try (as if x265 would be the encoder): RGB to HEIC (a few losses yes its a compression after all) but now it should be possible to convert it back the same way HEIC (logic reverted) to RGB what im trying to say is if you know the encode code you know the decode code i 100 % agree that x265 has no engine or command line code to do so to me the VLC media player and the x265/libde265 sounds most relyable for xp for the grafic card we could try if nvidia helps us and either makes a working engine for XP or at least nvidia tells us how we programm the grafic card without these engine (cuda ect.) cuda is also just a code that control input/output and "controlment code" for that grafic card unit i agree its much to talk, but so we sort out the stuff we dont need

that refers all to a grafic card doing the encoding/decoding and using a engine (maybe through more engines) (engines like dx9 to dx11 can change and just say "no i dont support this", what then? that just raise the question to install win10 and use the dx11 engine) i looked neither one engine does say clearly what it supports for XP(like modes "10bit" or codecs "h264") , and some engines dont say anything about XP (therefore what should we think ? probaly xp is not supported) so lerning that engine or engine"s" would take a lot of time and probaly lead to a dead end also they have the inner source code of these engines, so they can stop the "support" anytime , version 1.001 is here now - xp is not supported anymore the website of nvidia names: vulkan (no OS said) directx video(only directx11 and 12) nvidia video codec sdk (says directx9 but not what exactly what mode can be done with d3d9, if lets say its the h264 codec and cant do h265 codec it is directly dead end) PyNvVideoCodec (no OS said) namely says CUDA but with CUDA there again is nothing about the OS said so that are 5 engines by name nvidia video codec sdk: to me that nvidia video codec sdk seems to be a engine to control the directx engine (i often wrote about that - engines for engines - and the cpu power lost by doing so) (why i think it use up directx? because later on it writes "nativ api interface directx9-12") since cuda is also a engine it raise the questions if it supports h265 for XP, then you also need a grafic card that can do that mode it might say directx9 but not what modes directx9 support, if its the h264 codec only it is not useable vulkan: someone already name the vulkan engine https://msfn.org/board/topic/186252-vulkan-api/ i do not know if that is just the right/full information but opengl 4.5 ? i dont know ... sounds like a never touched part - and nothing says that the grafic card is used on xp, there is just no information if opengl4.5 is doing that on xp the websites rather says vulkan is something for linux, android, mac, fuchsia, iOS (but we need xp) but important to see is that this vulkan engine rely on the OS grafic drivers, what if the driver isnt doing it on XP while on win10 it can (aka you might get it to run opengl4.5 but then it dont play anyways on xp while on win10 it do, maybe the code reaction is missing for xp while 10 has it) then again its a thing to lern - where might actually again reach just a dead end (but what i know opengl is a pre engine, the real thing happens later in the operating system and the grafic card driver) directx video: (dx11 and dx12) - directly out of question (dx11-12 are win7-11) CUDA: cuda sounds interesting, but it dont say what it actually supports it says that there are CUDA versions but like version 1.0 up to 12.5, hard to say if XP has the latest version available then again its a engine (with versions), hard to say anything if xp can do anything here and the nvidia information says not even a operating system ... its a closed source too - the cuda engine has again to be said a internal code that has a deeper controlment (+ maybe the related driver after the cuda engine) PyNvVideoCodec: nothing said, but you can see that it says it use CUDA, and since phyton is something like java that "phyton engine" probaly uses up cuda (engine for a engine) but this is what i pointed out at the very first talks about LAV and the MPC-HC player (that the MPC-HC author started to rely on engines) and these are all engines and engines are often very OS limited and version limited (therefore MPC-HC is no longer self contained - it rely on engines of certain operating systems (that might also be a dead end for that player - because many others can do that also, if mpc-hc would have a XP support it would make mpc-hc a special player - but like this it is "the same old - there are other players that can use that new engines on win10 ect. too")) ------------------------ the x265 i called out - dont rely on any engine, nor OS, nor driver, nor grafic card, nor unsuppored directx 11/12 engine (dx10 is probaly dead) i dont think the CPU is to slow the decoding process is faster then the encode option "ultrafast" https://msfn.org/board/topic/185879-winxp-hevcheifheic-image-encoderdecoder/ also the video frame will not be written with a file engine, therefore it can go directly into the video frame buffer (what also is a lot faster) the decoder also is generally a lot faster then the ultrafast encoder -------- i must say that i dont write this as absolution i want to try to create a positiv talk about this and if some have more specific information - i would be happy to hear that informations and i like to be corrected up ----- but again guys notice this : they made this codec bound to a engine and what this engine do is closed source in win10/11 or a closed source from the grafic card company (such as intel, nvidia) so if you actually try to use win10 engines you probaly fail (because you only can use win10, where only win10 has that engine to function) very important to know would be what players can play the h265 codec in XP or maybe what players played that codec in the past - that might be a good question to be answered one is worth of a try and says it has h265 into playable formats, and says it works for xp https://en.wikipedia.org/wiki/VLC_media_player#Input_formats -- one word to that cuda engine nvidia might tells us a "engine(aka cuda)" that we should use to do this: https://upload.wikimedia.org/wikipedia/commons/5/59/CUDA_processing_flow_(En).PNG but they dont tell us how this is really done (if we would know this we could write a own control code and use the grafic card and encode h265 with the grafic card) but in this case its "the engine is doing it - or not" if for example we would have what in the picture is called "copy the result" in our case that would be the "decoded h265 RGB buffer" - we could control that memory to the player or directly into the video frame buffer the other things we would need is how it make the control code (like decode this h265 data 8 bit - there should be a control code, as always) the input data where and how has to be given to the grafic card (a h265 file we will give it, or at least enough data in steps from that file) in win10 or "aka directx 11) this is not a problem because the engine "dx11" is doing that for you but thats a problem many todays programmers have - they dont have insight how things really work anymore - and have to rely on a high language/script/or multiple engines again that x265 code let you see what actually really happens ... (and this with the engines are solutions for a win10 player/stream/video solution, you actually dont see! how that decoder/maybe encoder really work - with the x265 source code you can see exactly that)

well what we should not do is just to let them do their thing every kind of resistence is a resistence everything that is good against 10 is good, everything that is bad to 10 is good everykind of remembers how it used to be, what has badly changed might be something we can say we can code other programms linux is not a enemy we can stay on a OS before 10 , it dont matter what one just that it is not 10 or 11 we can talk against 10 we can try to bring missing parts to the other operating systems we can try to ask lawers what we can do against this monopoly we can try not to buy win10 products (such as only support that os) - what is our right neither what someones resistence look like, try to be creativ just not giving up ...

well yuv is a old compression the idea wasnt that bad going back to only have the contrast first it was a question how much luminence that pixel had adding the colors was next so what i remember is that they had created a signal modell for 3 wires (4 signals , 2 and 2) 4 for luminence 2 for chroma blue 2 for chroma red in since of 3 wires the data win is 2 times 50 % less there was a YUV 4:4:4 mode that is lossless but the data is a lot more so we can say yuv 4:2:0 or 4:2:2 are compressions - or also must be seen as compressions https://en.wikipedia.org/wiki/Chroma_subsampling then there where already different modes for this transition yuv to rgb or rgb to yuv but there are more compression tricks, today even more - to discuss all of them it would be a long story to really make a decision we need compares with a current encoder the heic decedents would be such encoders(vp9, svt), maybe also the codec from frauenhofer is from consideration (h.266) those have modern compression tricks then we need a compare filesize and pixels to figure what is better if 10 bit is better ok , if 8 bit is better then its 8 bit but coming from a different end netflix and other stream providers longly used that h.264 codec it seems a bit much to provide a even better quality then a common stream provider as we are rather normal people but dont get me wrong on that 10 bit question if it can be proofen to be better at similiar filesize, i certainly would agree to that decision but also back to the h.265 player question, i think i can do it - but it would be a lot of work - not just a going there and its done if that LAV is the right decision, i doubt that LAV is the right choose - that i already pointed out for my perspectiv i would have to lern that entire LAV engine and its use on a player - that also is extra work where i think i will fail really hard because i think the encoder might is at a spot that cant be programmed from XP (one idea was maybe the driver dont accept the control code - maybe it can but its closed source) if this would be the case the entire lern for the LAV and player engine would be a waste but going forward - what are the next possible idea´s for this project ? we could start with players for xp that actually can play the h.265 codec , and if so what modes, are they open source, ect.

somehow that website x265.com was down and changed weird ? also https://bitbucket.org/multicoreware/x265/ is down here is a working one: https://github.com/videolan/x265 https://www.file-upload.net/download-15418681/x265_3.5.tar.gz.html

i remember that effect quite often https://fixthephoto.com/images/content/banding-in-photography.jpg also in a raw format but it raise questions why it happend those stream encoders have to be realtime therefore they probaly cant use the encoder/decoder to the maximum extend if the bitrate then drops they are more likely to apear the next picture is wrong but: https://fixthephoto.com/images/content/banding-in-photography-bit-mode.png it says 16 million colors but actually the color palett to the left only has 22 colors instead of 16 million one reason can be that there is not enough color differences aka only having like 16 colors a other is that the picture/or pixel had to be repeated a next reason is that somewhere before the progression unit what somewhere before arranged it inperfect a next reason would be no 100 iso (if iso is pushed you have less information, also in colors) a lack of dynamic range or a strong light differense can also be the reason hard to say what exactly caused either the RGB to not having 1 contrast difference or in YUV why it also dont can make 1 contrast difference i think we need pictures to really see if that is the case, and if yes how many the filesize actually increases, if its 20 % we just could use a higher bitrate and might have the same result you might have some information for us ? to the other part if version 442.74 can do this it raise the question if older versions can set this mode we dont have insight into the nvidia driver source code but therefore i would say if people from here just try to find where the problem rely it will be hard to figure out regarding 1 cpu thats to simple to say we dont have insight into the entire thing the entire os is also running in the background, then somewhere is the player, that LAV engine and that d3d video engine + more (maybe the driver ? more engines ?) it dont play just the h.265 codec someone would actually have to study the player and engines - and then might fail because he cant see into the nvidia driver (since that LAV engines or d3d video engine calls up that somewhere somehow) thats why i the past i pointed out it might be better to have a own engine the full source code is available at x265.com but writing from here you also then have some work to bring this into that MPC-HC player i might point out that the XMM registers are a lot faster in this like 5-150 times (sometimes called SSL but mmx ssl, avx are the same origin and still are called XMM registers (maybe added a ZMM sometimes)) a pure player/decoder should not cause many cpu power - the encoder need a lot more it certainly would be possible to bring that x265 decoder to that MPC-HC player - the question is rather who makes the work

so there is progress in this one now ? what is the status ? that with the bit depth is a longer discussion as for RGB 8 bit per color or RGB 24, it dont improve any pixels as it supports already over 16 million possible resolution per 1 pixel even on a 4 k video you need a lot less then that for the entire frame (8,8 million pixels) so if you copied a picture in RGB you got a lossless picture, but it get big in filesize many camera´s actually dont resolve 4 k either (yet), useally they are upscaled those who actually can do nativ 4 k are rare i dont want to advertise them but here are the only 2 i know that resolve nativ 4 k https://www.red.com/red-tech/red-tech-red-ranger-with-monstro-8k-vv https://www.arri.com/en/camera-systems/cameras/alexa-lf notice the smallers versions of those dont resolve that resolution sometimes even these dont resolve 4k if the low light performance is coming for example or the lens is not on the best spot also from consideration is how many light the object emmits (if the shutter speed is high the momentums get more bad) its a very long discussion many lenses dont resolve that resolutions either, and for a nativ performance you need a large sensor or/and very good light https://www.dxomark.com/Lenses/ to me it raise questions to go higher because its getting less of a compression jpg is a yuv 4:2:0 compression, there might be other modes - but they not very common (main 10 main 12) where only 4:4:4 can resolve the maximum, but for this useally RGB 8 bit or RGB24 is used going to 10 bit raise exactly that question, the filesize will go up, in sence of bit from 8 to 10 bit its 25 % so lets say you have a 750 mb video would have 937 mb video what i for example want is better performance for the same filesize, not a increase for example in bitrate that cause a few more pixels but a bigger file the hardware compressions for a stream useally dont produce that much quality either i think they might have to use a older compression version and have to use medium to keep the frames to realtime https://youtu.be/5rgteZRNb-A?t=72 we can see that software performed a lot better (both P3 and P6) (well seen at the white parts at the mountains) we might start this pixel discussion that way, but being set to peak performance because in other case it might cause a few more pixels with 10 bit because the encoder performance needed to be realtime hard to say if 10 bit it should be reasoned

im not certain if he thinks assembly is dos programming, so i think we try to create a better view actually assembly not a dos language assembly is not a high language in a high language you have something like "for i=0 , i<10, i+1" in assembly that looks different you have to write that vars on your own , you have to write where that routine/loop starts and ends and how many times it repeat it assembly has a big advantage, its a lot faster but assembly is a lot more work to programm for example today are many "engines" and something like the sdt (C++ Standard Library) like std::array is also very script "ish" and engine "ish" those engines always load a certain engine, api , or certain codes - that sum together so the file is getting very big and slow (aka now some people might understand why win10 is not the fastest) assembly is still used today for example the XMM routines are written in the heic encoder https://msfn.org/board/topic/185879-winxp-hevcheifheic-image-encoderdecoder/ sure you can use normal commands , but just try to use a big jpg file (such as a 20 mb + one) and encode without assembly (aka hardware acceleration and no XMM registers) the encode time is 5-50 times as much but here is a good part of your question "the book is old" the good news in assembly there is not many of new stuff, like they do today with engines, api´s or the sdt there is only a few new stuff (that you can lern like instand if you know the "old ones") there is not much differens between x64 and 32 bit either , the registers are called with a R(64 bit) instead of a E (32 bit) - still doing the same job you can write assembly in the vs2019 or 2022 compiler (or the olders ones too) you just write __asm { // assembly code here } assembly = faster, smaller downsides = you need a lot! more time to code, a lot more of understanding is needed (like many math), less code you can copy paste like you certainly could use a engine/or something like that - but then you have to write the right assembly routine for it then one more thing is to know, every current compiler or language have to create a assembly code (because thats the only code the cpu actually can read) so a java, c or phyton code actually creates assembly code - that makes it hard to say its a language for dos back in the day you had other assembly commands too, by writing a emulator you can translate these old assembly commands to new compatible ones (thats what people sometimes still do) normal c++ found a good compromise in my opinion (the new c++ styles rather go into a script direction like java, phyton and others do)

i always find this discussion kinda interesting but actually i cant speac with the guys here because i simply dont know the details around it and lack the toolz to see into that specific stuff but it keeps going like there has to be a extra driver that exactly fits only for this purpose shouldnt there be a possible solution when the others operating systems like 7 10 ect. do ? what exactly is problem?

that with the segments i probaly didnt write that well i wrote it like microsoft shows an example how to use a "4 GB extension" over segments but i only wanted to show that microsoft make use others segments but what microsoft dont do is to use the other segments for data extension/breaking the 4 GB limit the 32 bit protected mode also contains the so called segment registers CS (Code Segment), DS (Data Segment), FS (F Segment (the one microsoft uses a little in that example before) , ES (Extra Segment) GS (G Segment), SS (Stack Segment) https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture in the 32 bit protected mode the CS points to something called the Instruction Pointers (IP) you might heared that somewhere in 32 bit it has the E in front of its name called EIP (64 bit useally have an R in front (AX=16bit, EAX=32bit,RAX=64bit) the instructions are encoded with this combination CS:EIP (segment and offset) for example the data has also an segment (DS) but microsoft made it point to the same memory as CS so the idea would be to change either the selectors (what microsoft only use like 2 vars 0008 and 0032 (out of 65535 possibilities) or using an different segment such as ES, or GS common debuggers like "ollydbg" or "ida debug" dont show the segment selector before the EIP im sorry that i could not find a better picture: https://stackoverflow.com/questions/43300040/understanding-8086-assembler-debugger here you can see an example of CS:IP (16 bit) in 32 bit it is called CS:EIP - what he marked red would have been like cs:0000010D here is the alternativ to PAE called PSE it shows how to use PSE with 36 bit, and later on with 40 bit https://en.wikipedia.org/wiki/PSE-36

maybe it dont have to be always the maximum of 128 GB from the "russian patch" maybe 8,16,32,64 GB would also be something but i readed up the information here on msfn they dont say what they actually used if PAE is used there might be still open questions lets say its PAE in PAE page table entrys (PTE) and page directory entrys (PDE) are not 32 bit wide they are 64 bit wide https://en.wikipedia.org/wiki/Page_table#/media/File:X86_Paging_PAE_4K.svg however this not neccesary means 32 bit PTE and PDE cant point over 4 GB of RAM thats because of the pages - for example common PTE and PDE that are 32 bit wide and are bound to 4 k pages (4096) that PSE can extend that to 4 megabytes pages (thats 1024 times as much then with 4 k pages) (4 mb) https://en.wikipedia.org/wiki/Page_Size_Extension#/media/File:X86_Paging_4M.svg (4 k) https://en.wikipedia.org/wiki/Page_Size_Extension#/media/File:X86_Paging_4K.svg but here is a other catch i once noticed windows has a certain space for a 4 GB address room so PTE and PDE entrys are exactly calculated for 4 GB entrys if you would extend these entrys a PTE would overwrite a PDE entry (thats because the space for PDE/PTE is exactly calculated, AND the next entry for the PTE is a PDE entry (aka the next space in memory) - therefore you overwrite the PDE´s) and here is the catch that PDBR (page directory base register) for each process would not have a such "overwrite of PTE/PDE" problem it can just use new PTE´s and PDE´s that point to a different memory (aka above the 4 GB room) so if that russian patch is doing that it are theorecial 4 GB for each process thats "OK" in my opinion (maybe they also done something with PTE´s and PDE´s ?) one more word about that /3GB option in normal space usermode has 0x00000000 to 0x7FFFFFFF (you might have seen this somewhere) thats only 2 GB room - however the kernel also can be used as RAM (for example for a RGB buffer) kernel mode begins in that "normal space" at 0x80000000 some are static at this place like ntoskrnl and some drivers (but the rest here can be used as ram) (why not kernel32.dll and some others are also always loaded and take some of the "normal userspace" 0 to 0x7FFFFFFF) thats why the /3GB options increase the userspace to 3 GB room 0x00000000 - 0xBFFFFFFF and the kernel mode then has 1 GB of room, while userspace had 3 GB ram so it raise questions what the "russian patch" used to reach this it would be something new, it seems there is actually room for real XP inventions neither what method was used or if the entry problem was extended and fixed inside the windows drivers if not PAE with not PSE, we could have instead of 4 k entrys 4 mb entrys less talked about is segmentation is a combination between a selector (called segment selector) and a offset https://en.wikipedia.org/wiki/Memory_segmentation i do not know normal programs that use a different selector just for extra memory a common selector is that FS: selector often FS:[00000018] in 32 bit sement selectors are 16 bite wide (65 k) following by the 32 bit offset (4 gb) = 65536 * 4 GB segmentation might also has potential, to make an example from microsoft: https://devblogs.microsoft.com/oldnewthing/20220919-00/?p=107195 swap files are good too, you use the harddrive what today is a SSD, as memory storage. in this case you simply put data you want to progress on the harddrive and by needs either control it on the harddrive or getting it back to your memory (as pleased) this allow you to pipe a lot more data then 4 GB (for example a blu ray movie that is above 25 GB, you dont need the entire 25 GB at once) in the past if you didnt had the ram (like 16 mb ram) you stored the data on the drive (you had a slow harddrive in the past) then you progressed it either on the disc or you loaded parts into memory where you progressed that data you might do not need 4 GB instantaneously/at once the pagefile of windows is doing exactly (also) that by the way someone called out the RAMDISC that is also very nice, and are very fast

https://msfn.org/board/topic/180669-two-questions-about-diyba-128gb-pae-patch/ dibya says it works, maybe good thing to test

hmmm maybe we should ask Dibya about the 128 GB ram patch for XP (there is a such thing - do i know if it works - no i do not know if that 128 gb ram patch works - but i know 32 bit can pass the 32 bit address room) from what i remember he said he tested that and it works, when i first seen the 128 GB patch i had doubts Dibya should be still around, he may know better about that 128 GB patch for XP, maybe others also know some details, geoffchappell also has mentioned that 128 GB ram somewhere if there is nobody at least it seems that we have people that want to test that out a problem could be that it maybe is app/executable-wise, but thats still ok then you have 4 GB RAM each app, only 2 APP´s would already use 8 GB of ram - what sound ok to me i say this because i remember a problem with the PDE/PTE´s windows had it calced for exactly 4 GB ram, so going past might overwrite one of the entrys (they follow up directly) i do not know if windows has a different way to handle this if more then 4 GB are present, this is not a problem if that PDBR (that i mentioned is involved) - because that exactly leads to 4 GB / per app

there are basicly 4 things that can pass the 4 GB limit 1 PAE physical address extention 2 PSE page size extension 3 the PDBR (page directory base register) 4 segments also worth to mention is setting the userspace to 3 GB instead of 2 GB with normal settings windows xp use 0-7FFFFFFF (usespace of 2 GB) the rest for kernel mode this can be changed with /3GB then the userspace is going up to BFFFFFFF (3 GB) its only 1 GB more, but it is considerable to some extend to not explain it to a long story text i try to make it short PSE can extend the page size - a page is a certain amount of memory like 4KB PSE can increase that to 2 MB or 4 MB each page PAE this can use more address bits and therefore using more then the 32 bit limit the PDBR is something that points to a "APP/Executable" memory these are filled with PDE (PAGE DIRECTORY ENTRY(s)) and (Page Table Entry(s)) these can address a different spot in memory, therefore you can have an APP each time for 4 GB address room this dont extend the memory for 1 app to more then 4 GB ram, but allows you to have many APP´s with each having 4 GB address room segments: a segment was a known thing in 8 or 16 bit mode a segment point to a fraction of memory like for 16 bit it would be 64 KB (per segment) the next segment is then a next segment of 64 KB (for that example it would be 0-65535 kB then 65536-131070 (that makes a segment 0 and a segment 1 - aka 2 segments) also worth to mention is what you called out the normal harddrive what today is a SSD (flash memory) xp use that as memory too(yes it can use a HDD or SSD as ram) since we have SSD now this isnt a bad thing SSD´s are fast in the past you used up a slow harddrive and the loadtime was like terrible this is called the PAGEFILE so storing data to the disc is also an option that we can mention also worth to mention is that 32 bit can calculate with at least 64 bit (its the FPU unit or so called XMM registers) if you have AVX 32 bit can even handle 512 bit since these are made speed if if you are on x64 bit, MMX/SSE/AVX are faster then normal opcodes ... so if someone gonna challenge SSE or AVX with normal 64 bit opcodes he still gonna lose very hard against this hardware speed registers by far they not 1 times faster often 50 or 500 times faster in short story first was MMX then got the name SSE then SSE version X-X then SSE was called AVX (so basily its the same nature) i could write more detail, but its like complicated stuff and would fill to much of text now 2 more things are also important to remember: the hardware has to be able to do so (an example would be that there are only 32 wires or the cpu dont got the PAE or PSE mode - so lets just say cpu and bus/ram have to be capable to do so), the software has to have it supported/programmed (aka windows in our case)

maybe joaquim is a good candidate to reprogramm VDMSound, and the right spot to ask would be that dosbox guys it only has a few people working on it https://github.com/volkertb/vdmsound

it might be an application that starts up this. try msconfig and look around

well from a programming perspectiv it is most likely the buffer it also can be the cpu what ticks cant read it out smoothly so knowing if this happens on a faster cpu/ram is also a little piece from consideration a good way would be to know 1: the game (i suspect its a game) 2: the source code of the emulator 3: a open source game if it has the same problem having those give you insight in the input (such as your open source game) and where it lands (the emulator) 1 way was already said, just using a different emulator one programming way would be instead of just playing that sound instead is loading the sounds into a memory location, memory accesses are a lot faster a ssd would also be possible a to small buffer can also be the case a false order (such as a wrong interpretation) if the source is slow the buffer is slower to be filled (delay) a very common windows function to play a wavesound would be playwave: https://learn.microsoft.com/en-us/previous-versions/dd743680(v=vs.85) a codec such as mp3 use compression tricks that goes from lossless tricks to "what soundwaves the ear hears better "soundhearing" " the mp3 does not recontruct the wave as it was to be for example mp3 boost certain types of wave forms you might dont hear that so well - but in a wave compare programm you can see that then there are like longer discussions too for example that 18-24 khz discussion "can you hear the 20 k tone or not ect." a other one would be the "sample rate" https://en.wikipedia.org/wiki/Sampling_(signal_processing) often in a computer its just a small piece of data like "make 10 k wave" "make 2 k wave" ect. at the end a sound is nothing but a wave form i think it is certainly possible to find that issue but its work to do all the steps you have to search the right code, the right OS, the right compiler, the right debug toolz, the right places of the code, you have to run tests ect.

32 MB/s is a very common speed for old flash memory - you might look what speed your flash usb stick has flash memory are in USB sticks, SD-cards and SSD harddrives to make an older example the super ninentendo ram uses flash memory https://www.kingston.com/en/blog/personal-storage/memory-card-speed-classes flash memory is a lot faster then reading from optical devices (like the cd-rom to dvd/blu ray) - the cd-rom use light to read out the signal the next storage is a common hdd drive, it use a magnetic tape older versions where VHS (yes hdd drives and vhs have a "head" for the reading signals) those are cheaper to manufacture the optical devices long lost the battle also because they are bigger light is around 380-800 nanometers while a modern CPU goes with 5 nanometers, thats a lot smaller then the light also a common myth is that light drives faster then "electrons" , this is not the case what also is very important is the frequency that can be used - not always only the "drive speed" a fibre-glas-wire is also never straight it bounces in the wire - also the "basel effect" makes it impossible for light to go straight - therefore you never reach the 300 000 km/s (travel not tick/frequency speed) https://en.wikipedia.org/wiki/Basel_problem a next problem is that the "photons" due that problem have different momentums so some overlap because a different momentum - so some what not suppose to reach the target yet are hitting the target before the others then you have to give the "photons" more time - what result in less speed now the catchy part photons dont exits its a so called electromagnetic spectrum (aka 380-800 nm) there are smallers (gamma rays for example) that also travel in that 300 000 km/s speed

you might have an example where and how exactly it starts to lag from what i know the ms-dos mode is not a real ms-dos mode anymore for xp it is a "emulated dos" some old ms-dos stuff do not work there anymore i criticized that trend also in win98 - in win95 when you returned to dos-mode useally worked ... in 98 it was bugged already you had to boot up in dos mode first windows 98 and his last release (windows me) still had 16 bit parts inside that gone away while windows me had its turn (and to my opinion was a bit more bugged then win98 SE) they made their first 32 bit only aka nt 3.1 4.0 and 5.0 (what later was called windows 2000) is it a ms-dos game ? its been really long when i programmed a dos sound device (midi and wave for example) so its hard to say where the problem is if we dont know the cpu and the ms-dos app sure i think also xp still has open possibilities regard backwards compatibility to ms-dos as i think xp has found a nice compromise to still support backwards, somewhere in the xp area and future compatibility

SSE dont sound to bad for me to be honest, at some point a CPU would probaly just be to slow to handle the job - here it might could be solved but is it that SSL that was written in SSE ? if so it is certainly possible to write that one to normal opcodes then you probaly need to understand that XMM logic and transfer it to normal opcodes (emulators of elder retro games do so for example). since it would be a hash then nobody would reconize a differenz