XXHighEnd

Peter - I'm still getting random hiccups and clicks between tracks (as discussed already) - not exactly smooth gapless.  :(

As before, it happens on long playlists, but if I stop and play the "problem" songs individualy then all is fine.

I know you've been pulling your hair out over this one, and have been alluding to the possibility that it has to do with my setup - but it only all started with 0.9u-7 when you introduced the 'Mem' checkbox. And FWIW, I've played with the possibility of different Scheme and Invert (and subsequently changed my preferences - see sig) but with no resolution.

Do you have any other ideas?  :dntknw:

I seem to remember being able to play long playlists yesterday with 0.9u-11 (when I was experimenting with 'DAC is 16/44.1' and no Double). Could that be the culprit? It appears to happen during the "preprocessing" when it loads the next track.

I think I started myself talking about requireing more from the PC. Whether this is true or not I don't know, but two days ago it needed a reboot for me to get that solved. But there's more variations to this;

Can you tell, does it interrupt the last track (near the end), or is it right in between of both ?
If the first, then it's the PC. See if a reboot helps and please let me know.

I guess you didn't understand what I meant by:


I am watching Engine3.exe in Task Manager and right when the Memory increases (as it loads the next track) is when it "hiccups". So, it is not right in between both, but rather around 2 seconds before the end of the last track.

But the "click" is right in between both.

Ok. But what you don't know is that either could hold up the other.

Did you try the reboot now ? 99,99% chance it helps.
Edit : ... for the hicups !

Were the clicks gone in u-11 and now they are back ?

Too late to try now. I will try again tomorrow.  :sleeping:


Well . . . no I did not notice any clicks with 0.9u-11, but as I said, I was not (could not) using 'Double'.

I just realized ... you say that this happens with Double, Right ?

Edward, don't get psychologically influenced by this. Of course this *was* so, but not anymore.

What happens though is that with Mem unchecked there's pre-processing which wasn't there before. This spikes one of the cores to 100% (you'll see 50% with two cores), and it will be (during) this time that playback gets interrupted.

Remember that I told you that it looked like the system is influenced such that the priorities / time slicing doesn't work properly anymore ? I think I for myself proved a few days ago this is just so.
First the system got "deteriorated" to a level even under Windows 3.11 (I saw that one time before), and buttons almost looked like Dos. Then there was no way the track loading would not interrupt playback. Playback could hold up track loading, but once track loading happened, playback stopped. Single user processing ...

As you know, you already *set* your system (more or less) to behave like that. It is my theory that the processing just takes too much (or takes too long) to let it be unnoticeable.
Remember, the trackloading happens at the lowest priority already, and can't be influenced by you (but the "opposite", the playback thread, you can). If you come to the conclusion that you don't like this net, I can only advise you to check the Mem box. It will then be a tradeoff between more accurate playback because of the coding, versus your stuff that indirectly does the same.
But as said, it's my guess that a reboot helps.

Btw, I just tested and retested ... nothing wrong here with Double as well as normal (used The Wall from Pink Floyd for it).

Lastly, don't hesitate to go against all. We'll work it out. :yes:


PS: Might is help you, I'm using Core Scheme 3, and actually never try anything else anymore ...

I had the processor running up to almost 100% a couple of times in end of a song, nothing happend exept the windows taskbar changed color from black to white, but I have not been able to either repeat nor isolate what happend - sorry! Could that be kind of same thing as problem you described?

Else I find u12 sounding good so far. I run 16/44,1 and back to upsampling via Purcell to DSD, with Q=0.

Oh yes. Those kinf of things happen all the time (but they may stay away just the same).
It can be restored (all becomes nornal), or just stay.

OK Peter, the album I'm playing with is "Spiritchaser" (from Dead Can Dance). I played after a fresh boot, and the same thing happened as before (and in the same spot - so it must not be all that random). Here's what happened:

I started with track 2 and there was a hiccup between 3 & 4 as well as a click - I stopped there.
Then I started with track 3 and there was a click between 4 & 5 and every song after that, and I didn't have a hiccup until between 6 & 7.
Sounds random right? Well, the hiccup seems to be happening at the point when the Memory usage for XXEngine3.exe gets to around 1GB. And the click just seems to happen after the second track and then continues. FWIW, If I start with track 4, then there is no click/hiccup between 4 & 5.

Well, at least I have that album !

I started at 2 (Attended), moved the slider towards the end, and had a hicup. Whether that went along with a click I can't tell.
Repeating that wasn't possible, which should lead to the disk access doing it (a second attempt not needing the disk anymore because all is in cache).

Sadly, playing the remainder of the album didn't cause any hicups or anything.

I used the settings from your sig, but Core Appointment Scheme 3.


Somehow in here is the crux. I now think of the combination with your earlier observation : the memory not being freed at the first couple of tracks. To too, usually is not repeatable. I have been watching this closely since then, and it occurred to me that I am now able to free "fixed" Vista memory, which otherwise won't go. Just overrun the memory (by much consuming tracks), and from then on my Vista uses in the 300 range (which otherwise would be 600).

Ha ! During typing of the above I restarted at the end of 2, let run 3, and 4 began with a click !
Now, indeed (or coincidentally ?) XXEngine3 used 1.1GB of memory (you can't see that in below DCD01 but I checked).
Next this happened (and this too is one which keeps on puzzling me) : I restarted near the end of 3, 4 loaded, the cursor moved, but no sound. This is the occasion that Engine3 just runs, but it beats me where it hangs out (in the code). FWIW this is DCD02 (say, for my own reference).
Then I again repeated this, and then it played without click.

Ok, and this time during typing of the above, from 4 to 5 a click. Total mem usage only just over 1GB.
From 5 to 6 the same (ver small tick).

Well, I have the example ... :)
Thanks again for your efforts Edward.

Edit : Since I have these subsequent pictures, there's also something visible that I kind of expected : The heading "wisselbestand" meaning swapfile, shows a decrease of 500MB between the first and thye second picture. I expected something like this because we may expect that when the OS manipulates the swap file it gets all the priority there is. Note though that this never will skip coding parts (but the hicup skips sound) because otherwise we will get one big mess (wrong byte order). So what might happen is :

a. The OS thinks more memory is needed than available (might just be true btw);
b. it moves something over to the swap file.
c. This is logic, because at hicup time as I've seen it, there's more IO going on than expected (by me).
d. This is not the best thing in general.

Now, during the playback of 7 the following happened :
The memory had gone up to 1.74GB.
At the move to 8 it went down to 0.96GB.
Playback stopped and even XXHighEnd stopped (cursor stayed at the beginning).

I quickly made a screenshot when 8 was still playing but forgot to save at making a next screenshot of the 9 situation, at which I found that I didn't save the previous one, and then didn't save *that* one. :fool:



PS: Bueatiful dry drums in that 3rd track, don't you think ?

2.5 hours later ...

At this moment I can come to no other conclusion than that this whole .net / Vista / whateveritisstuff s*cks allover.

I have switched off the virtual memory as fas as possible (Re: Disabling Virtual Memory can cause errors (http://www.phasure.com/index.php?topic=260.msg3456#msg3456) and the result I get from that is that the used memory grows and grows.
So now I know how "Managed" dotnet works for it deciding when to delete memory. The G.d. thing first copies to virtual memory, and then lateron it may delete it (which IMO can happen only after a copy-back to the physical memory first).

I hope to have solved it ...
See 0.9u-13.

Additionally :

Edward, like I said, your (remarkable) remark about the memory Engine 3 using, indeed gave me the clue;

It appeared to me that all the memory that should be free went right to the paging file. But, as it seemed it stayed into physical memory as well. I think this is about one part of it staying in physical memory and another part was just moved to the paging file. Both should not be so, and the first triggered the last (because that too mr. Bill Gates wanted to preserve).

I'm not sure what in the end triggers the deletion afterall, but as I found earlier, it has to cross some boundary. And, this boundary shouldn't be crossed with a too large amount, or otherwise things can't cope. Think of a "collision", and when *that* happens, we're out of sound.

For those who really want to know, all seems to be related to the thread all happens in. So, within one thread this is out of control. But, dedicate the memory to the particular thread, and it *is* removed immediately when the thread finishes.
So this is how I solved it (and in fact how it emerged as a problem) : do not keep memory over thread boundaries.
Oh, in fact this is no problem for the OS, because it appropiately deals with it, but it's my guess that when this has to be dealt with, the one part has to move out, while the other part has to move in before it can be deleted (that is, this seems very normal to me from a structured means of programming). And that is where it went wrong : there's bits of I/O's back and forth (instead of a sequential stream) and that holds up too much.

Btw, this is (by me) excpected to be kind of similar to the OS performing whatever it is according to I/O, where the disk light goes on and off all the time. It is that what can cause a hiccup during playback. That is, I *never* experienced any hiccup while the disk light was continuesly on. This must be a matter of (too many) interrupts (at the first).

Also, I had the lucky occasion to be able to test things under the "worst" conditions (again, to my interpretation), which was during many services had shutdown (Note that even your network services may shutdown ... (http://www.phasure.com/index.php?topic=489.0).

But let me know if it still doesn't work for you. :innocent:

Peter

 :blush1:  :blush1:
Uhh . . . should I have mentioned that I've been running with Virtual Memory turned off for like the last 9 months with no problems.


What do you mean I'm not allowed to shut down virtual memory (or that it can't be achieved)?? I did this a long time ago because of the benefit of better SQ. Is it time for me to re-evaluate this? (And, that crackling thing is interesting.)

Anyway, back to the topic:


It still doesn't work. Neither with virtual memory off nor on. I even tried setting "DisablePagingExecutive=1" in the registry. Still get the hiccups. OH! But I think the clicks are gone!

On a side note - the SQ changed between 0.9u-12 and 0.9u-13. Did you expect that? My first impression is that it is "better".



Edit:

Might this help - I just tried the same scenario with Thread Priority set to "High" (instead of RealTime) and still get hiccups.

Peter,

Hi i am back again :).... Yesterday i have been playing a bit and there are a few things wrong.... I am sorry but i am not been able to test it more... This post is what i have too and i wanted to let you now. I will do some testing in a few day's. I upadated from U4 to U13 and played around a bit  :). Before i could play double when i set the EMU to 88.2. At the moment not anymore. The test say's i can. Even upsampling also not done anymore. I get a weird hickups crack thing with both. Something i did not have before.

44.1 is the only thing that works for the best.. But so now and than a hickup... I think i can call it like that...

I will try other players and will see from what version it began to do this....

One thing i come up with is that when i do something else like open a internet page or go from playlist to library the hickups/weird singing begins.... And the Taskmanager shows weird pike's...

Grtz

Gerard.....

EDIT: I order more memory.... Maybe that will help.

Right. So now you are telling me that with all the testing of that one particular CD, where I could copy the behaviour, and where now for me the culprits have gone, for you it's not so ? I've been playing that CD the whole day !!
(anyone wants to buy it ? :)

My remarks about the virtual memory are about when you are near to run out of physical memory. Please keep in mind, I only could solve the issue that was added with some of the before versions. The same issue in the more general code is still there and can't be solved IMO (because I *have* to work with different threads and shared memory).
That in the mean time this doesn't bother you at all, is something else, which may only prove better that I'm dealing with something else afterall.

Now, if you can find a way of making me clear how to copy what you still have ... I can't for the moment.
Btw, I ran at least 6 other CD's yesterday night with the same test setting, and not any hiccup.

Must think ...
But if you can come up with anything ...

And Edward, would you be able - and willing - to test this briefly with all your services On ?

In the mean time, when a, say, 5 minute track loads, how long does your disk light lit ? Please keep in mind that you can only test this properly for a first time per track. Otherwise the cache is involved.
Also you could try to notice whether the hiccup occurs during the disk I/O or right after that (during the cpu peaking).

Lastly, you might show a plot of the cpu useage during the track boundaries, but please tell me how long (minutes) the loading track is.

Thanks.
Peter

Thanks for all your work on this. And since not many other people are having similar problems, I do not want to waste any more of your time (or anyone else's time) on this *at the moment*. I will do some more investigating on my end to find the culprit in my setup. At the moment, the only way it works is if I check 'Mem', but I will try to find if there is a configuration (in the midst of my services tweaks, etc.) which will work without checking 'Mem'.


I've been using my RAMDisk again, so a 5 minute track load is less than a second. Can you  be more clear as to how I discern whether this happens during disk I/O or CPU peaking (it seemed to me that these things happen simultaneously)? As far as I can tell (when watching Memory usage in Task Manager) is that the hiccup occurs at the same time as the Memory Usage changes. And more specifically (with 0.9u-13) I think there is a point during the track load when the Memory grows large and then quickly shrinks to a lower number (as if it is releasing the previous track). I believe the hiccup occurs at the time it shrinks to the lower number.

Peter,

I did some more testing.... About double and upsampling you can forget that... That has something to do with te EMU. I have that with previous versions aswell at the moment. Maybe something to solve for EMU.

44.1 works well with other players. From U4 till U11 no problems.

U12 and U13  gives these problems. Before U12 they do not. The thing i also have seen is that the CPU usage is bigger with U12 and U13. Atleast at the moment the cracks hickups thing begins.

Grtz

Looking at Attended playback and native WAV files :
- When used amount of the memory grows (or just changes), the track is being read from disk (etc.).
- The very moment the time position cursor starts to move the next track is playing.
I think that is all what can be said about things to observe.

Sidenote : your copying from RAM disk will be another cpu intensive (small) task, which is not there when the file is read from disk.
Also : never mind earlier versions working OK. It is good for me as a reference, but it doesn't imply errors as such in the newer version; things are just too different, and the memory used just *is* more ! (somewhere I reasoned how much more it would be opposed to mefore). Of course, this does not happen with the Mem box checked.

Then :

This is more complex than it seems, and this is about the way dot-net (or possible Vista) deals with the memory management.
Also important to keep in mind : when the virtual memory is Off, it just won't work right. Better for you may be : won't work right anymore (?). And please don't forget : the virtual memory just IS NOT Off, but her limit is lower. So, the physical size of the virtual memory is small (2MB in my case) but the behaviour stays exactly the same ! When I tested with this, crackling occurred during the load of a track with a kind of nasty nature. No real hickup, and you could say that 30% of the sound still could be heard.

Another important thing to observe is that as far as I can tell, things are just wrong. Wrong by Vista or wrong by dot-net. You can see it for yourself :
When memory decreases, the virtual memory decreases just the same. When it grows, the virtual memory grows along with it. The correlation with the program (XXEngine3) is kind of hard (even for me), but the correlation between physical memory and virtual memory sure is there. And mind you, we talk in terms of 500MB here that is added or removed from virtual memory (hence disk !) within the snap of your fingers. Btw, it would be logical to state that the "virtual memory" showed, is including the physical memory, but that's not what the screen says ("in swap file"), and furthermore the behaviour is kind of "logic" if one thinks like this :

Physical memory in use is copied immediately to the swap file, but with lower priority. When additional physical memory is needed, all what has to be done is free it (because it's already in the swap file). Smart thinking, and all is faster now. Also try to see the correlation with "dot-net (memory) managed code", where one golden rule is on top of all : It is not you the programmer who can decide to free memory. But don't worry my boy, because all is taken care of.
It is my idea that things go wrong when memory needs to be freed from the swap file. On that matter, try to imagine that this process will have a higher priority than the process copying the data to the swap file. This is kind of logic of course. But maybe this priority (to the sense of stalling other things) isn't even important ...

To me, now, it more looks like a piece of memory (at the array level) is temporarily just not available or so. This then should happen during the process of reorganizing stuff by Vista, and which should be the case at removing in fact already not used memory from the swap file. That is, to me it became clear that the hiccup emerged at the physical memory growing larger than available, which right after that shrunk to normal proporptions. This shrinking is not caused by me (as far as I can tell) but just the notice by Vista that at needing more *that* is the time to physically free what was already freed logically.

As far as the comparison with older versions (or Mem checked) go : keep in mind that before (or with Mem checked) only the 50 MB of a 5 minute track was temporarily needed, whereas now this is 6 or 8 times more (150 - 200 MB). This is significant, *and* better noticeable by us, looking at the task maganer plot.

After I noticed that it all wouldn't work without assigning virtual memory (while all easily would fit in my 2GB of physical memory), I assigned 2 GB of virtual memory to each drive in my system.
Lastly, without my own "memory managing" adjustments, it still wouldn't work. With it does (for me).

Concluded : instead of my before suggestions (last post), you better try to assign virtual memory again. Keep in mind : Vista uses it anyway, so it shouldn't matter for SQ or whatever. But it won't run into limits this way. Thus : when Vista finds that the 2GB of physical memory will be used up, it frees memory, but IMO first whatever the amount is that doesn't fit, goes to virtual memory. Theoretically (and as to what I observed) this is the same amount as the physical memory is (2GB in my case, and which showed after shutting off virtual memory). From this by itself follows that the more than 2GB physical memory needed, will never fit in 2GB of virtual memory, combined with the philosophy (beginning of the post) that *all* physical memory will go into virtual memory as well.

Sorry for this rather unstructured post.
Peter

Peter,

Do you think more memory would help?

In the very end : no, I don't think so. It would be postponing the culprit. You could run more tracks before it occurs again.
All based upon what I wrote before, and maybe that is wrong by itself ...

I had two times a hiccup myself now on a first album (just Double).

So Edward, please don't bother. I will report more if I can find a pattern.

:heat:

Might you feel like trying something ... put your XXEngine3.exe aside and stuff the below in your XX folder.
I changed something which is more official according the books. I ran 1.5 album over it without problems, which - as we know - doesn't say much.

Peter,

I tried... I loaded in 1 cd... But going from playlist to library is enough for bringing up the cracks. Also this came up the first time. And only 2 cd's show up in the library area.

 :)

Well, I report here for the first time, so I hope I am at the right thread with the right topic.

I have followed your site for quite some time. It is very interesting because I am very intersted in good music retreival from cd (for this moment red book 16bit only).

Reading all the comments on clicks, pops, cracks, glitches etc (in Dutch gekraak, onderbrekingen, etc).

I personally am a totalally inexpierenced person within the technal context of computer audio, only I want to have a good audio expierence with a pc and headphone dac/amp. Simple as that, but it is not so simple! At this moment I did not try your audio engine, much because I want first that other engines work at their promises within the context of Vista. After that your engine can show its bennefits to me.

At the moment my WindowsAudioPlayer and/or Foobar2000 have all the clicks and hickups or glitches etc that are described here with respect to XX. So I think the hickups, clicks, glitches, interuptions etc are not related to one specific audio engine!

Not wanted interuptions in the audio stream are reported in respect to using XXhighend, but I expierence the same sort of interuptions with the other audio engines! My setup is HP9630ed/2gb RAM/usb out/usb in Corda Aria Headphone amp/Ergo2 Headphone. Without the reported artifacts a great soundmachine for a critical listener I can asure you. Within the context of  XP Pro the USB out/Corda/Headphone never/never gave any audio problem!!!

I hear those 'glitches' in this setup (USB out), but also in the direct headphone out. Foobar or WMP makes also no difference. All glitches, hickups or other interuptions in the audio stream are at random, I never have been able to rehearse a symptom in the same setup or plase on a cd audiostream. There is no system in the symptoms. Only I have observed that changing or adding a application gives some extra hickups. For example, adding mail or internet to using audio gives a extra puch to the same symptoms. When not changing or adding other applications there is less interruption (so interacting of using more than one application at the same time withing the context of using Vista gives problems). I am waiting for Service pack I in the Dutch language for an update, but I am not sure it will help al lot.

When I looked into a article in the Guardian about Vista Audio (Jan.2008) I get a little dissapointed, but also more informed! Look for yourself at the internet, the article is published fully. The people at MS themselves disapproved the audio results of their own Vista! Look also when you google with : vista audio glitches, hickups, cratches, audio problems etc. You get hundreds of hits! In the sfere of Proffessional Audio you can get even more comments on the audio applicability of Vista. No one in that proffessional area is going to use that OS at this moment! It will become a economical disastre for them.

The point I want to make is: is it possible that you all are trying to solve a problem that is not solvable by you alone because the Vista OS context within your are trying to solve it, is at this time principally not functioning correctly for audio at the first place (that is for correct audio retreival and audio datastream) and your are not able to correct it because you can not alter the OS itself.

Let me be quite clear: I have great believe in the XXhighend engine at itself although I have not listen with it at this moment. I only think that there is a possibility that you are looking for problems and solutions in the wrong place. Possibly XXHighend is not the problem, but vista and its surroundings are the real problem.
I hope you find the solutions, so all audio engines will function correct and the XXHighend will be really the best.

Pieter.

Superdac,
One thing to keep in mind is that in recent earlier versions of XXHE there were no pops/clicks/crack sounds.  So things have worked fine.  Peter changes things for sound quality, and these latest versions have an appeal that xxhe people are pursuing, but this "higher" audio performance is causing some "hiccups" some related some not... that's for Peter to figure out and us soldiers to help with hehe. But I'm  sure Peter will bang his head against the computer long enough to spill blood and get things fixed in a way that's good for SQ... we're in beta.  I think, if anyone has figured out/has a handle on Vista audio, it's Peter... sometimes I truely think he knows more than the individuals at MS.

Anyway, as stated, earlier versions of xxhe which you can dl, have not shown "hiccups" in Vista, and to my ears have already beaten Foobar....to a pulp.

Nope. :no: Still hiccups.



This is not the same thing we are discussing. I'm not talking about random glitches or dropouts. This is a repeatable interruption. Thanks anyway though.

Hi Pieter,

Thank you very much for your extended and nice reply. Indeed as others said, the hiccups (a 1 second silence) is special to the latest versions of XXHighEnd, and in the end just caused by me. You could also say : caused by my little knowledge on how the OS deals with certain (memory) situations. Whether that by itself is buggy by the OS or not is not important. Bugs are to work around (or solved when they're in your own hands).

For you I only can say that your glitches and all will be caused by your system, which doesn't say they can be solved or solved easily. All the people in here prove that audio can be completely glitch free, unless it is the player itself doing it to you, of course.
Some systems are setup in a way that they are prone to glitches (hi Chris), and some others are prone to crackling (Gerard built such a system ;)).

Glitches most often will come from interrupts which shouldn't be there (think of a wireless keyboard), and crackles are there because the OS draws away the needed cpu cycles from the audio driver (not the player software). Crackles therefore can be influenced by priority settings, and glitches will go away with a balanced interrupt scheme. The latter often is very hard to do, and may be incurred by a device itself. Remove (replace) the device may be the only solution.
When you indeed have glitches, what is used in here : Check to see if your computer can cause drop-outs  (http://www.phasure.com/index.php?topic=349.0) will most probably show it.

Btw, I would not be surprised if you don't perceive glitches from XX (while getting them from Foobar) because XX works very differently from the others.

Peter

Peter and all,

The problems are gone over here... I have set q1 on -2 for a few weeks.... Today i moved it a bit upwards (0)  and the cracks and hickups are gone.... :)  :blob8:

Maybe something for Edward to try.....

Grtz

Hmm ... if this is really so, you get the Nerd Award of the year, ok ? :) :)

In the mean time, I think I can adjust the Q1 temporarily then, which would only be during the load of the track (which typically is less than one second).

Thinking of this really being so, it would even make sense to me. But then there's another solution, and this is in fact the solution to something I pointed out some longer ago (over half a year) :
(actually, here it is : XXHighEnd Model 0.9m (Implements Processor Core Appointment) (http://www.phasure.com/index.php?topic=210.msg1220#msg1220))

So, at that time I wasn't able to appoint that -by now (!!) heavily cpu using thread- to the other core. Maybe with the increased knowledge (:fishy:) now I can ? Anyway, this now just *should* happen. Why ?

That half a year ago, the only thing what happened in that other thread was reading the file from disk. This is not able to use 100% cpu because of the I/O involved. Today, the cpu (better : that one core) will be used for 100% and that might take up to near a second. This is officially way too long to keep on filling a buffer each 1 millisecond, and as I indicated earlier : it looks like time slicing doesn't work properly anymore. Now I say : how can that ever be done properly with a cpu (core) being in use for 100% (and tasks between that core *have* to be divided) ?

As a sidenote I refer to what I said earlier about the copying from RAM disk (as Edward does it), which only makes this worse (the situation stays longer) ...

Gerard,  :good: :good: :good:

When this keeps on going, i will have to make a special showcase for all the awards i receive!

 :rofl: :rofl: :rofl:

 :)

I think we may have a winner!!

Well . . . at first attempt with Q1=0 there was more stumbling (and crackling) between tracks than before, so I decided instead of trying every one, I just went to 14 hoping that is most neutral. Success! I only played through the offending album once, but I think everything was smooth. And it makes sense, because I was eventually going to get to trying Q1 settings, but I first tried Schemes. No appointment was full of crackling. And the others were only mildly better. Scheme 1 is the only one that is perfect for me (which is just as well because it clearly sounds the best to me).

And let me just add, Peter, this success comes with all my usual tweaks (Virtual Memory off, limited services, etc.) in place. And also, this is with the original 0.9u-13 (not the modified XXEngine3.exe that you offered)

So, to be clear, I still clearly prefer Q1=-2, but if you have a way if tricking it to 14 during transitions then fantastic.



And finally, during all this, I stumbled onto something else - Peter check your PM.

I've been working the whole evening on the Appointment stuff for the loading thread, and eventually got it running. That is ...
I had been looking for two hours into an error that shouldn't be, prepared for bed, but got back. It suddenly jumped on me that the error could be caused by a thread not being allowed to have different Appointment (ok, Affinity) than its starting thread. Since I was working with Scheme-3, which appoints the audio to core 2, the threads coming from there couldn't go to core 1. It just errors.

Now I don't know of any logical plan to fix this. Yeah, maybe some technical complicated structure which uses a special scheduling thread (no Affinity), that synchronizing the playback and the load threads (each now can have their own Affinity).

Man, I must rize the price to 73 euro. Hahaha.

Peter

First i like to say that u13 sounds just great overhere. Specially the bass!
Leaving q1 at -2 and changing to schema does the trick also like Edward sayd. But a bit different.  No appointment, schema 1, schema 2 dont give problems. Schema 3 and 4 does.


I allready have the 1 euro ready to send!  :rofl:

 :)

Yes, I was looking into this excessively yesterday (because of wanting to tweak the appointment of the loading thread), and from theory (hence looking at the cpu graph, without sound) it is clear to me that Scheme-2 behaves how we want it. That is, the loading goes to core 1 BUT the playback can't be decided for (with Scheme-2 playback goes preferrably to core 2 but may go to core 1 when the OS likes that.

Scheme-1 is a different beast; this tells the audio to play in core 2, and all of the other stuff to be in core 1. But, the downside is that the loading goes to core 2 as well (it inherits from the playing thread). Also, knowing that Edward has (had) the problems with Scheme-1, from this we should derive that it is the loading itself. When you, Gerard, find that Scheme-1 helps making it better, the conclusion must be that it is stuff from the OS itself that interferes with all, and that it actually is a problem with switching between cores (the output towards the general bus or whatever) or something in that area I can't comprehend so far.
Scheme-3 indeed is the worse from normal theory, and Scheme-4 is the worse when switching between cores to the matter of dedicating threads doesn't work properly. On the last, keep in mind that each time a thread switches from core, the in-cpu cache memory has to be copied which is consuming by itself.

These matters are rather complex, and FYI many pro audio people see a degradation of sound (like glitches) with Quad core processors (or at least an unexpected lower throughput opposed to dual cores).
I think one can get a degree in getting this right.

FYI : So far I am not able to solve this by a different Appointment (Affinity) to the loading thread, but also the temporary change of Q1 cannot work. The latter is related to Exclusive Mode not being able to initialize more than once per Ausio Session; with 0.9u-14 I thought I could trick it (according to the concerned properties), but this turns out not to be so.

For now this remains unsolved for those who are bothered by it.
:scratching:

... but since I never give up, I managed to tweak the unallowed changing of the inherited Appointment (Affinity).

:evil: :evil: :evil:

Below a few plots for Scheme-3 (must work out the others), noting that Scheme-3 plays sound on core 2, while the other processes are preferably on core 1.
The spikes represent the track load (hence the preprocessing of it), which went to core 2 with Scheme-3 before.

What I observe (or seem to, relative to how it was) is that there is plenty of headroom now for the 4-6 minute tracks which are loaded here. Normally the cpu shows a horizontal line at the top for the Doubled padded to 32 bits tracks (which for the before situation indeed would indicate some heavy working against itself e.g. heavy core cache switching). No squeezed toes in my shoes "will it do it" now. It just feels good.
Btw, Q1 is -2 here.

I'm near the end of Amused to Death now, and no single hiccup. Does this say anything ? :nea:

Oh, note the plots are at full throttle here, and TaskManager itself consumes the most cpu. The most flat lines in the right core are the most representative for what Engine#3 is doing. Where core 2 shows more activity, it's the "dying out" of other services being active at that moment. Picture 03 shows this from off the middle (the track load is not visible anymore (but for in the memory line, near the left).
In 01 vs. 04 (and 02 a bit) you can see that core 2 tends to help core 1. In 01 this apparently was not necessary. By itself this is good balance, because the paying thread now is on both cores temporarily ...

For those who were bothered by this, would you care to try the below version of XXEngine3.exe and report please ?

Put the current XXEngine3.exe in your XX folder aside, and replace it with the one in the zip below.
Thanks,
Peter

Edit : Removed the zip, while results are known from it by now, and it can create confusement (merely created by myself in other posts).

I am really sorry to say Peter..... :sorry: But nothing has changed.... For me it is exact the same like before.... From the beginning till the end of the song cracks.

Q1-2 schema 3 & 4:                          Cracks
Q1-2 schema 1 & 2 & No Appointment: No problemmo
I can bring my pc over... When that safe's time for you  :)

But Gerard, I may have said it before ... you are bugged by something else. This is not about cracks throughout the tracks, this is about track boundaries.
Sorry ...

OK Peter, I finally got around to trying this. I put this in with version 0.9u-14a. I played my "usual" set of DCD tracks and unfortunately I still heard a hiccup. Although, it occurred at a different point, so it sort of caught me off guard. Before I would start with track 2 (from Spiritchaser) and I would always hear a hiccup between tracks 3 & 4. And this is consistently repeatable. But with 0.9u-14a (and the new engine.exe) I didn't hear a hiccup until between tracks 5 & 6. I've only had a chance to listen once, so I will try again later to make sure this is repeatable.

But all is not lost!! There is a significant improvement in SQ over 0.9u-14! (Do you owe me one euro now or do I owe you?  ;)  )


Edit:
And BTW, I tried this with my new favorite Q1 = -1. (I figured this shouldn't make a difference since prior to 0.9u-14 Q1 = -2 was really -1.)

Hmm ... I am playing with 0.9u-14a since it is there, Appointment = 2, and at least I never had a problem anymore.
I must say though that in 75% of cases I played with Q1 = 14. :)

Well, if you can find a pattern I'll be happy to dive into it again.


In 0.9u-14 that new XXEngine3 is incorporated. But I guess that's what you were saying ? (hence don't copy that separately uploaded XXEngine3 over it ! the latest is working a tad differently again to this matter !).

But with 0.9u-14 (with Scheme 1) the track loading still incurs a CPU spike on core 2. With 0.9u-14a (and the separately uploaded XXEngine3.exe) the CPU usage during track load is with core 1. (I assume this accounts for the better SQ)

Is that what you mean by this:

And if it's different, how can it also be already incorporated?  :wacko:

The separately uploaded XXEngine3 was dedicated to Scheme-3;
0.9u-14a works with all the Schemes (and thus incorporates a newer version of XXEngine3, which you can see by the date it carries).

I hope we understand eachother ... :)

Nope, you lost me again.

0.9u-14a was posted 04/14.
You posted on 04/16 about the "new" XXEngine3.exe.
Now which one am I supposed to be using??

(Bare in mind, I'm using Scheme 1 and I don't want to change it)

:fool::fool:

You are completely right Edward. I am very sorry for the confusement;

I did apply those changes I mentioned, but never uploaded that as a new version, and they *are* just in that separately uploaded zip.
Time for a vacation ?

As a matter of fact, I now recall I was waiting for your response on that separately uploaded zip before uploading a full version which should include it. And I never did.

To make it more clear : you listened to the intended combination, and apparently it still doesn't work 100% for you.
Added to that I listened to Scheme-2 where I should have been listening to Scheme-1 in order to copy your behaviour ... you can well say that my mistakes are going to add up. :cry:

:sorry:


PS: I will try Scheme-1 now.

After 7 tracks and Scheme-1 on a first album I just receive my (0.3 sec or so) hiccup between tracks ...

Well . . . I listened again, and it is indeed repeatable. Although, I must say, it does seem to be more subtle than with previous versions.

Thank you Edward.

Edward,

I didn't get around to explicitly testing your situation, with the -honestly- idea I can't improve on it anymore. This idea is also given to me by the fact that I one time (yes, one time only during all this time now) had a small hiccup with Scheme-3 and Q1= 14. And, since Scheme-3 is the best solution for spreading resources for all of the other services/threads (which Scheme-1 does not), there's no solution in there as well (like temporarily spreading everything over the two cores). But :

Today, during testing something else, and by pure coincidence, I saw the small hiccup occurring during the drawing of the Wallpaper. So now I'm thinking it is just that doing it. Or at least *now* that is doing it (and the longer hiccups from before indeed were caused by some I/Os that receive priority by the system).
Oh, that process drawing the Wallpaper has the lowest priority already ...

Might you be with the screen in front of your nose during listening, can you confirm this ? No obligations, but might you see it by accident ...

Peter


PS: Might it be relevant ... my Wallpaper is set to 590 (and playback is UnAttended).

I have read this thread carefully and realize I have the same problems: Occasional short ticks. Sometimes they last for many seconds, somewhat like "50%" traditional harmonic distortion, with changing intensity - let's call it "scratches"?! (I never had "digital" noise like dropouts or bursts). Obviously its a resource conflict between Vista and XX, as you have discussed above.

I am not an PC-expert. My brother is. I will ask him to study this thread to see if he can come up with something clever. In the mean time I am fidling around, using the trial&error technic. (Not to be underestimated, that's how Colombus discovered America). Here are some observations:

Observation 1:
In Windows > Task Manager > Performance there is a button called "Resource Monitor". This feature has lately become my favourite watch (apart from The Simpsons, of cource). Here I notice that Vista is running A HELL OF A LOT OF system operations. There are more operations first 30 minutes after rebooting. Also, more operations early in the day. (Probably Vista has a lot to monitor, update, etc, etc). Ticks and scratches seems to happen more, when Vista is bussy.

Observation 2:
Setting both priorities to "Nothing" seems to help a litle bit.

Observation 3:
Changing Scheme from 3 to 1 seems to help a lot! BONUS: I feel an interesting change in SQ between 3 and 1. EDWARD: Can you pls describe your opinion of SQ diference between Scheme 1 and 3? (You first, then I'll tell mine... 8)).

Observation 4:
When useing XX: I never load only 1 track. Normally I load an album and play some tracks, or all the tracks in a row. Eventully I load a readymade playlist of 10-20 songs taken from various albums. This is probably common use also by you. If such a playlist has been in use, it seems that the "pre-processing" of those songs is present even if XX is turned off/on. To completely remove them I have to reboot the PC. This is necessary if I am testing the VISTA performance with different settings to get rid of ticks and scratch noises. At least this is what it seems like when watching Task Manager > Resource Monitor. Peter: Is it so?

Observation 5:
Beacuse of Observation 1, trying to find a solution is like shooting on a moving target. For example today I switched on my PC and started playing with old settings (see signature). A lot of ticks and scratches. Unlistenable. After 3 hours, and several changes of settings (se photo) it now works perfect (for the last 30 minutes at least). Going back to old settings (right now while typeing) it's 98% perfect, with only couple random ticks each track.
 
Present settings: Se photo.

I just copied your current settings for myself, in case you will change them.

Thanks a bunch for your extensive outlay.

Fine.

Tomorrow morning I will follow up my findings. I hope going from Scheme 3 to 1 is a valid solution also when Vista is crumpy/moody in the morning. He-he.

Try to up your Q1 setting to at least 7 and hear if you can detect any "clicks" or noise in the same tracks.
I have similar problems with Q1 around 0 +/-.

Btw., How's the new soundcard behaving?

Good morning!

Following yesterdays settings-experiments, I got surprising results this morning:

1.
I switched on the PC and started all programs as usual (Explorer, Remote desktop and XX).
I went back to "worst case" of yesterday settings: Scheme 3, PP/Below normal, TP/High, Unattended.
Startet to play music. The first half hour I heard a few ticks during each song. After that it's been perfect playback.

2.
Have tried to "provoke" the setup, by changing Scheme, Priority, Unattended, but WHATEVER SETTING, it is now perfectly stable without any ticks or noise. (All the time I use Q1 = -2 due to superior SQ).

3.
today, there seems to be less activity from internal Windows systemfiles. Maybe this is a part of the explaination?

4.
Also, today I didn't have any "accidents" with XX/my PC. (Yesterday morning and the evening before, the PC got "hung up" because of XX abruptly closing down - probably because I asked it to load a faulty playlist while entering too many commands).

THEORY:
If a clumsy user, like me, "mistreats" Windows/Vista/XX, then maybe it provokes extra OS system activities/programs runing in the background. (I think there is A LOT going on inside VISTA, which you normally don't see). Which again creates a conflict with XX afterwards.

Picture: Resource Monitor in Task Manager. TIPS: Clicking on the green DISK graph, opens the DISK log, where you can study OS files running. Disk use is in blue colour. When the blue graph goes max, that is when ticks and noises MAY appear. They did yesterday, but not today...

I am using two DAC's DDDAC1543 with USB interface and  a PCI Soundcard. I only have the random hiccup problem with the Soundcard. With version 09v-2, as far as it takes i did'nt noticed hiccups anymore . I'll have the impression that the problem is solved!?!

During the hiccup period i have changed / disabled a lot of things but never found a direct relation. Now i disable standard the virus checker, infrared devices, and more programs.