For the 24 bit versions, no, I don't think so. But many report like this (compare the Fireface, which does it right).

If it's not a 192000/24 card then more is the matter (compare the Fireface, which does it WRONG above 192000 ).

Moving to a sound studio he ?

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.

Well Dave, not to keep you from your sleep because of perceived brain damage and all, when I wrote the before I was still at home, and I just couldn't wait. So I already listened.

Ok, the family came down wondering whatever was going on because I never play music that early.

I can only say : I can't comprehend;

I took that crazy ticking Cornershop thing (and now I'm stuck with that 2nd track in my head the whole day), of which I knew that the vinly ticking goes along with the beat.


Ah, you just admitted that.
Psychologically we are influenced by the third track, that indeed mimics the vinyl (or whatever it is that it tries to mimic) and which is VERY similar to the other ticking. Only more exaggerated.
Btw, I didn't run from 4 and further, but I would swear there are more of these exaggerating tracks. In fact they all ticked so where is the border of reality.

To make a long story short, the ticking has gone (not in the beginning and other pieces of the third track), and I really don't know what to make of it.
The first thing I should do now, is comparing both player situations for being as bit perfect. Of course I know they both should be as can be, but I want to be sure.
Assuming both are the same, we have the most wild example at our hands on how software can differ to SQ. I mean, man, this isn't normal !!

Please do not forget what I said before about this, which I won't draw back : the transients just *are* in the data, they look completely abnormal to me, I was told that can be so, and from there on we heard them. This was the sequence, so this was the placebo ? Oh no ...

Until I can prove otherwise (and I will be hard working on this the upcoming days) those transients can be squeezed out of the data (before 0.9u-13 latest versions), or they are just skipped (u.9u-13).
It is clear to me - by means of a couple of bold statements from a few who listened 5 minutes and posted that things had changed for the better - that this influences the complete picture. Even I can hear it hehe. But now hear this :

If this really isn't incurred by software error (the being bit perfect of both versions must prove that), then we now have a tool that can tune in between following transients which really shouldn't be followed (before 0,9u-13 versions), and which does that a kind of other way around : rounding those to a pleasureable listen (0.9u-13). The tool is a real tool only when it is under my control (which it is NOT at this moment), but we have the reference.

Apart from the blahblah, I would like to say that for me this morning was a moment to share with some other audiophool (preferrably "you"), because it actually brings up the desire to lit a few cuban cigars (never mind you smoke or not), have some brandy, and infinitly talk about how on earth this is possible. Never mind it's early in the morning, I can pretend it's late at night.
I really really don't know, despite my own outlay earlier towards the opposite, how these ticks can happen to emerge. Remember, this was theory (for me), but now it is practice. Strangely enough now I don't dare to state so firmly what I stated before about this. A kind of scared to be wrong somewhere ...

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.

This sounds truly unbelieveable, but I guess I have to ... Actually can't wait to get home and find out that Cornershop album isn't full of vinyl ticks anymore while I changed NOTHING to the code but different memory management.

The settings in XX are about "logical" maximum rates. And since I don't think a DAC will exist that has a maximum of 88.2 (because then it will do 96 as well), 88.2 is not there. Same for 176400.
On that matter I think that any DAC that can do 44.1 will do 48 as well, although I am not sure about that.

352800 is a different one, because this is a kind of official standard, and DACs may be produced to that standard. Theoretically 384000 could exist as a double of 192000, but I don't think it does and will.

Note that the DAC Is settings are used for "self protection", and sometimes to make decisions on how to behave (like playing 352800 on a 192000 DAC will downsample).

When you can only choose 96 with soundcard settings of 88.2 - and play 88.2 - this really does nothing. All behaves as if you chose 88.2.

I hope it is clear a bit ...

A few days now playing with 0.9u-13, makes me think this :

Bass has got it's individual vibes, possibly more than ever before. The latter may not be true, because I recognize it (but it sure must have been a longer time ago).

The buzzing (and I mean fly-like) which may emerge in air, is more there than ever before, it seems. May you have it, try Les Nuits from The Nits. It's all over.

Somehow it very much occurs that drums (I mean toms, but also bongos) got a "dry" reality which I never heard before; At listening to Dead can Dance a whole day long at Mondays I thought it was special to that album (and certainly some tracks), but I recognize this in much more now. It gives the feeling of not all drummers smashing anymore, but just dropping their sticks onto the veil.

Another occurring thing is that the forward sound (which IMO was taken away a little in the latest versions) is as profound as it started with 0.9u-0. Somehow this gives me a feeling that it can't combine with those beautiful drums. But it does ... The explanation to this is more depth ??

Anything else ? well, if anything else must be menstioned, it is my feeling that Double sounds more refined than Normal (mind you, not Upsample). This comes to a kind of surprise to me, but otoh I hardly listened to Double for many months (and now I have to in order to solve that hiccup problem ).


*That* the sound has changed is what I kind of was afraid for because of the rework on the memory management, and using less memory anyway. How this exactly influences I am not sure, but apparently it does, looking at 0.9u-0 and the (e.g.) forwardness getting less and less (while more and more memory was used towards the newer versions!), while now all is back, and the memory useage is back to much less. Coincidence ? probably not. Voodoo ? as usual.

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

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 () 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, 

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 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

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.

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.

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

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

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

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