XXHighEnd

Hi Peter,

I noticed that double arc prediction upsamling of hi-rez material (24/96 -> 32/192) causes small dropouts every minute or so while more cpu-consuming (is it?) quad arc prediction of hi-rez tracks (24/48 -> 32/192) plays flawless. I'd appreciate your comments on that

Marcin - The 24/96 files will be twice as large to read compared to the 24/48 files. Together with the processing needed you will just run a bit short of time (and you know I am against the 1-processor "technology" ( :)) for reasons like this).

Btw, I am using QAP without any pain on 88.2 or 96 material. Completely glitchless on a today's modest machine.

Peter

Your modest machine is  still 8x faster than mine :D I'll decrease split size and everything should be fine. Thanks for your explanation

But hold on a second. Isn't the split size parameter supposed to adjust equal portion of data being read regardless of input? I'm confused.

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 ... :) :)

It's ok, the dropouts are not common, only with few of my albums and I'm gonna upgrade my audio PC in few months, that will solve the problem. Out of curiosity - what split size value do you use? There is very noticeable difference between e.g. 32 MB and 64 MB. The latter sounds fuller.

70. But that is for OAP and I have 2GB of memory. It can be a little higher, but I don't want to run into a (hidden) out of memory error, and think it is something I did wrong in the program. So, this is a bit on the safe side.
FYI, because this is also important, this incurs for maybe 0.3 sec of disk activity. Suppose this is 3 seconds on your side, then *that* will create a problem for sure (this can be your disk subsystem, but also just your CPU which is always involved, and which may be very busy with it's sad one core :)).