XXHighEnd - The Ultra HighEnd Audio Player
September 21, 2024, 02:59:44 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: August 6, 2017 : Phasure Webshop open ! Go to the Shop
Search current board structure only !!  
  Home Help Search Login Register  
  Show Posts
Pages: 1 ... 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 [955] 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 ... 1048
14311  Ultimate Audio Playback / XXHighEnd Support / Re: DAC Test working OK in 0.9u-13? on: April 11, 2008, 11:14:17 am
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 Happy).

Moving to a sound studio he ?
14312  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 11, 2008, 10:39:08 am
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.
14313  Ultimate Audio Playback / Your thoughts about the Sound Quality / Re: 09-u13 Cracks have vanished... on: April 11, 2008, 09:56:17 am
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. Happy

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.

Quote
The harsh cracks (not too loud but following the music

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


14314  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 11, 2008, 09:20:27 am
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.
14315  Ultimate Audio Playback / Your thoughts about the Sound Quality / Re: 09-u13 Cracks have vanished... on: April 11, 2008, 07:19:31 am
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.
14316  Ultimate Audio Playback / XXHighEnd Support / Re: Other settings with EMU1212m? on: April 10, 2008, 04:45:39 pm
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 ...
14317  Ultimate Audio Playback / Your thoughts about the Sound Quality / Re: 0.9u-13 first impression on: April 10, 2008, 02:29:10 pm
Quote
Also many loudspeakers are not very time corrected, so the tweeter is slightly closer to the ear than the midrange. These 2 factors works well with the "softend" treble of traditional CD sound...

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


*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. grazy
14318  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 10, 2008, 02:03:26 pm
Hmm ... if this is really so, you get the Nerd Award of the year, ok ? Happy Happy

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


14319  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 10, 2008, 09:22:00 am
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 Wink).

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
14320  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 09, 2008, 10:10:36 pm
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.
14321  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 09, 2008, 07:55:10 pm
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
14322  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 09, 2008, 12:18:12 pm
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 ...
14323  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 09, 2008, 10:13:49 am
Quote
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.

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
14324  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 08, 2008, 08:10:25 pm
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
14325  Ultimate Audio Playback / XXHighEnd Support / Re: 0.9u-12 --> Hiccups and Clicks on: April 08, 2008, 07:58:13 pm
Quote
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.

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

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 ...
Pages: 1 ... 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 [955] 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 ... 1048
Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 1.296 seconds with 12 queries.