XXHighEnd

Had some issues with my laptop and had to defrag 3x's to get it running right. Afterwords XX was still way to slow so I deleted a "Misbehaving Config" file (http://www.phasure.com/index.php?topic=709.0 ). Whenever XX starts running slow that has always been the fix for me. However when I next tried XX I got the "Device Allocated But Cannot Play" error. I lowered the Split File Size from 200 to 60 and XX started working again; however, it sounded like cr*p. Mids and highs were way too thin sounding. I spent the next two days frickin' pulling my hair out trying to figure out what was going on, initially I thought it was the amp and started rolling tubes..... I then noticed that I had constant hard disk activity (okay, so I'm a little slow, I got that!) and I increased the split file size back up to 200. Hard disk completely settled down and presto, my smooth, full sound was back. I didn't automatically increase the split file size when the sound was wrong cause I assumed XX wouldn't work! It seems that it took the computer time to "adjust" to being defragged, during which time I had to lower the split file size. After it "settled in" I could raise the size back up to 200. Just thought I'd share, but I am wondering  why reducing the split file size was a necessary step to get things going again. Also, is there an ideal or preferred split file size?

Thanks for sharing indeed. But whether it all is related ? ... to me it doesn't look so.

The "Allocated but can't play" message comes from Kernel Streaming, and it tells that a device was found, but it couldn't be set to the bit depth / samplerate implied (by the track + your settings like Double, etc.). That really is all, and how your defrag can influence that ... to me it seems it can't. But quite some other things could have been wrong at the time (to your imagination, and knowing that you now know/understand what the message means).

The ideal Split File Size depends on almost too many things to explain (but I have a topic in mind for these kind of thing);
The preferred setting is easy : the larger the better.

I'm not sure myself what the differenc between ideal and preferred is, but let's say ideal in this context is what brings the best performance from your system, whereas preferred merely is about the inherent useage of the setting itself. The setting is there to prevent your tracks eating all your memory, while the more of the track is in the memory, the better it is (for pure memory playback).
Since tracks have a sheer infinite (read : undetermined) length, while memory so far always is imited - also taking into account the upsampling which lets all grow exponentially, you, as the operator can control what amount of memory is allowed to be used by the tracks, before your system explodes otherwise. That's actually all.

... But it gets more complicated if you see that loading larger portions of the track (or the whole track) can take too much time because of slow processor speed and/or just too large portions. And this means gaps.
Add to this the ultra low latency (KS) stuff, and either the (high priority) playback will again cause the trackloading to be more slow, or the (not high enough priority) playback will be interrupted by the huge amount of processor cycles in a row the large portion takes to process.
And there are several types of processes of course.

Anything else for now ? :swoon:


PS: I didn't check this for typos, afraid to read it all makes no sense unless two more pages of explanation are added (which I don't feel to right now :)).

Thanks Peter, that's more than enough for now. :wacko: