You are too smart ! Now I must even think about this myself ...
Ok, at first, yes, you are right. But in the end you are not, which actually is my fault, but also is new (to me !). So, what happens ?
The portion of data we talk about is projected onto the memory useage. Thus, this
looks like being equal to the portion read. However, this is far more complicated to begin with, because it is about the net used amount of memory. With "net" I mean "after all has been applied what should be applied". This means that, for example, QAP will use more internal memory than (e.g.) DAP because (regardless of bit depth) the resulting data is twice as large BUT the effect of that is that a smaller portion of data is read from the disk.
Isn't that fun ?
Now, I could try to explain all further influences, but I hope this is enough for you to reason out yourself what happens how, if you only keep on taking into account that the Split Size is about net memory used, *and* is a relative figure. Thus, your e.g. 100MB does not imply that 100MB of memory is used, no, it implies (determined by me) that (just making up something) 1GB is used, and to achieve that maybe 30MB is read from disk per time. Now you see how complicated it gets, knowing that DAP a 24/96 file does not need as much MORE internal memory compared to the form disk read portion, compared to a QAP 24/48. IOW, the 24/96 needs to expand only twice, while the 24/48 needs that 4 times (and that several times because of internal arrays). This, while a same amount of read data from 24/96 implies less playing time compared to the same amount of bytes from 24/48.
But also (and here I am guilty) :
The factors used to calculate the portion to read from disk, do not incorporate the relation between hires and upsampling (Doubling etc.). So, what will be in there at this moment, is something like "Doubling requires half to read from disk compared to no-Doubling". This is okay for e.g. 16/44.1 vs. 16/88.2, but this is not okay for 16/44.1 vs. 24/88.2. This is because with 24/88.2 as the base (thus, that Doubled) a part of it is implied already, and this is the growing step from 16 bits to 24 bits. I think this will mean that a 24 bit file which is doubled, uses unnessecary few memory compared to a 16/44.1 file, and this is because the calculation doesn't incorporate the expansion from 16 to 24 bits which is NOT needed now (but still to 32 if you have a "DAC Needs" = 32 DAC).
If you can't follow ... not your fault. But I really don't like to spend more time on it, where all is too complicated to be exactly right to begin with. Also don't forget Anti Imaging, which starts at 16/44.1 allright, but not when the actual file is read, because by then it is already (e.g.) 24/96.
Be happy that you don't receive static, because all *is* related to the parts read and the internal arrays which all must fit up to the sample (byte actually).
So, this is another side of this upsampling mess. It is all not *that* easy ...
