I already sent previous post without seeing your latest:
If this ends up in well meant (!) advices how I should organize the program, please let's stop. I mean, I have better things to do than explaining to you (or anyone) why it works like it works.
I'm sad to hear you saying you're not open to ‘well meaning advices’ but it's your forum and you make the rules here so I guess I'll have to shut up.
I hope it's fair though to let me respond to your latest post?
it could have been nice or maybe helpful if I didn't make all this stuff already, but I did - and so now it will be the other way around : I am (we are) in the hands of Bill Gates how this all works and what it implies. No thank you !
Fair enough, it's your product.
Considering the ease with which this can be tested I'd personally at least try it: even if it does not work in terms of SQ it might reveal something interesting that was not known previously which just might be useful.... But then, that's just me being curious. I guess I'd have to do it myself in order to find out, LOL...
If it were so that nothing's read into memory and a disk could be treated like memory, *then* we'd have another case.
That is the point I was hoping you would catch on and IMHO a single most important improvement to XX (or, rather, to audio players in general) with potentially greatest benefits:
Look at your RAMDisk. It is nothing but software. A device driver to be exact. And it sits right alongside OS. In fact, it is on 'per tu' basis with OS Kernel.
Compare that with current situation of XX being a 'user' process (as opposed to system) running in what is essentially a virtual machine on top of OS (.NET).
What if XX could be written as a device driver (a la RAMDisk) but with a twist: It 'knows' about its contents not being 'virtual disk files' but sound data that can be directly accessed without having to go through OS file I/O layer at all?
And by virtue of, effectively being a part of OS, what other layers have also been removed? (not having to deal with VM much less garbage collection etc etc.). And because it sits there (like RAMDdisk) it is 'stable' and forever unchanging (except for contents, of course
)
Now, how much closer is that to ‘bare metal’, what new possibilities would that open and how far more could XX go and sound then?
Puzzles the mind....
You can see how ridiculous it is (ok, through my eyes) at the examples of inter process communication. So, we write something to memory (which we do, but which ends up on the "mapped disk"), and now another can read from the same memory address and communicate. Just write some ".dat" files (you know), and be normal !
I see that you have caught on this one too: I was hoping you'd see the possibility of using MMF to 'replace' *.dat & *.dao files.
I don't, however, agree that it is 'ridiculous' at least as a matter of principle:
I believe most people here can agree that introducing RAMDisk brought positive changes in SQ. And, as you said yourself, it is not clear to you (not to anyone else, me included) just WHY is this so.
Is it a crazy notion to suppose that it has at least something to do with eliminating SDD/HDD disk-induced I/O interrupts as such do not exist with RAMDisk?
And if this at least sounds plausible, wouldn't using MMF instead of writing/reading *.dat/*.dao to disk be beneficial purely on principle as it eliminates disk I/O? (Yes, I know it may be a moot point if dat/dao are being written to RAMDisk but it still _has to_ make a difference as path through OS is very different. Maybe that difference turns out to be small so it's not worth it but would that make it 'ridiculous'?)
BTW - I may be wrong (I don't have logs with me) but if I remember correctly when you do either write or read of dat/dao files they had 'non-cacheable' flags set. Those files are so small they can fit quite nicely in OS cache and, as free bonus, you are likely to avoid file I/O interrupts when reading them back in from the Engine as there is high probability they'll be served from cache. I.e. you may get MMF benefits (at least in this case) without having to use MMF (since you seem to have a particular dislike for them.)
But if I'd behave transparently (for myself) and operate at the byte level, knowing that disk transfers go at the block level, what do you think the result will be ?
I don't know! And you don’t either! That's the whole point, LOL!
What I was (obviously unsuccessfully) trying to communicate is that if there is an interesting approach that has not been tried before it might be worthwhile to check it out (if it does not require too much time). Obviously, a proposal mentioned above, to write XX as music-player-device-driver is a LOT of work but trying out MMF really isn't. (BTW If you interested in pursuing device-driver approach maybe some people would be willing to help just because they find it interesting – for example maybe it could even be me (God forbid) ....)
But to try to answer your question in a more concrete way: I speculate you would _not_ have to worry about speed. I have read about projects using MMF to provide type-ahead suggestions (you know, like when you start typing on Google and it provides suggestions in drop-down as you type) on very, very large files: order of magnitude larger than any sound file you will EVER have - bigger than 32 bits 384kHz Beethoven's 9th gapless LOL
And they had to do dynamic binary search on that file too, so they were jumping back & forth around that mega-giga-tera file without problems, where, in contrast, you only have to move sequentially forward.
And OS is prepared for it, so it will preload SFS sections before you need them - OS is sometimes not that bad you know and they have removed most of code Bill Gates wrote in his days....
So, supposed this happens at the byte level anyway, *then* there's a chance for this. But I won't believe this, because e.g. copying to the RAMDisk just takes way longer than copying an internal array (writing to it) which easily goes within 0.1sec for 500MB or so.
Yes, it _has_ to be slower as you are going through whole OS file I/O stack which can easily be seen in debugger: there is _no_ difference compared to SDD/HDD disk access so it can never do 500MB in 0.1 sec but why would you need that?
Sound card doesn’t need nowhere near that amount of data in that time period even with 8x oversampling etc. And you can ask MMF to open a view on whole file instead of SFS chunks - As mentioned, it would read in as you move forward and you would not need to manage memory because MMF memory _does not count_ in your process set! So we could have even bigger RAMDisks as XX would be using only couple MBs
But OK, I guess I misunderstood the purpose of this forum: I foolishly believed it was a place to discuss possible improvements to XX in particular and explore new boundaries in computer-based audio reproduction in general. Seems I got it all wrong so I apologize and promise to shut up.
