Short interruptions in playback en very tiny hickups since y3 and y4

[ed linssen]

Hi Ivo,

All ideas are welcome.
Think I did already 97% of all the things I can do, but who knows.
 Checking again and again will bring hopely the solution!

Telstar,

I did a complete viruscheck. Nada!
No infections whatsoever found.
Thanks for the help,

Ed

[Telstar]

Telstar,

I did a complete viruscheck. Nada!
No infections whatsoever found.
Thanks for the help,

Ed

No, i said to uninstall the antivirus and any other resident program. Of course, better if the PC is not connected to internet.
If nothing does, format and reinstall windows (and stay offline)

[JohanZ]

No, i said to uninstall the antivirus and any other resident program. Of course, better if the PC is not connected to internet. If nothing does, format and reinstall windows (and stay offline)

Before Y4 I did not have this interruptions in playback. I have the impression that the disk I/O (activities) are causing processor activities and interruptions in soundreproduction. As I mentioned earlier when it go's wrong (in my case) I hear sometimes an interval of 1 minute discactivities. It's a pity that you can't switch off your internal musicdisc when you hear this interruptions. Maybe your logfiles tell's you more about the discactivities.

You never attached your logfiles in this post when you have this interruptions. Maybe this give's Peter some more information.

[PeterSt]

Ed,

Just for your motivation, I still remember that the dropouts started to happen to you at 0.9y-3, so there's always a theoretical solution. BUT, I rather don't change the code because of the current SQ, unless for bugs (and I will sure look for them). However :

The behaviour of your disk I/O is not good *and* most probably the cause in the end. And keep in mind : behind that I/Os will be a process (or more) and it will be eating.
Also, it may be fair to state that you are not going to solve it. That is, not by the means used so far.

What I would do in this stage, is go to the Resource Monitor (button in Task Manager) and examine what is causing these I/Os (so, look at the Disk Activity). I don't say this is something for you, but someone just has to do it.
Btw I asked you to switch off Virtual Memory. Did you ? (maybe I missed your response on this). You really need to do that *first*, and leave it off until you're rid of those I/Os.
If you don't know what to do with the resource monitor, try to make a screenshot (or several, because the list will always change) and post them. Be sure not to cause I/Os yourself at making the screenshot (like "let's start Word to put the pictures in"). Thus, have that all ready in advance, and let the heavy I/Os die out. It may take 2 or 3 minutes (you will see what I mean by that).

If you are off line it won't be spy ware (I think). So count that out. But do (as Telstar advised) get rid of all the anti virus/spyware stuff. Not only for now and test, but actually forever (which in the end is up to you of course).

And indeed it may be a good idea to list your processes to us; who knows we may see something.

Although nothing is wrong with Ivo's advise to let only 36 services remain, it is my advise to not spend time on that. Not now. My tweak list is sufficient, but be careful, this is for Vista, and W7 might need a somewhat different list.

Computers ...


PS: What Johan just said ... yes, you may post the XX and X3 log files. I never thought something interesting would show in there, but you never know. The least I can do is look.

[PeterSt]

Before Y4 I did not have this interruptions in playback. I have the impression that the disk I/O (activities) are causing processor activities and interruptions in soundreproduction.

I think this is true, and more clear to you than to another because you can hear your disks. Haha.

I myself start to have the feeling that something may go wrong with the priorities, like with the OS bug I worked around. This is a most difficult thing, because while the sound engine receives the idle priority this can not be seen by TaskManager. Only internal program code can show it. For WASAPI there's also a priority thing that leads its own life. Something like "I'm audio, thus I must have a high priority". In there something might be wrong as well, or worse, since I mangle the priorities the internal OS code may not be able to cope with that.

And for Ed and to stay awake : Thus this post tells how to solve something which is wrong in the first place, while my before post just tries to solve the I/Os which in effect will also solve it (I think).

It may be time for a special debug version for Ed ...

[ed linssen]

Hi All,

Before I started this thread, and after installation the OS, I did not install any anti-virusprogram. Switched off Defender too. First time I did Yesterday because of a rongish understanding of Telstar's reply. After the install , of the A-virusprogram, I did a total scan and uninstalled the program again.
Yes Peter, sorry I did not tell you about the virtual memory. I had switched it off already before I started this thread, some two weeks ago.
I have to leave the house now, and will send some screenshots and loggings, no, no leggings, later in the evening.
Thanks all for the compassion,

Ed

[JohanZ]

It may be time for a special debug version for Ed ...

....and..Johan?

[PeterSt]

Hey Ed,

You may have missed a response to your email about the log files not being attached, but I rather have them in here anyway.
Click the "+ Additional Options" you see at the bottom left at creating a post. In there you can easily attach them (don't paste the contents in a post because it is too long).

Peter

[Telstar]

Hi All,

Before I started this thread, and after installation the OS, I did not install any anti-virusprogram. Switched off Defender too. First time I did Yesterday because of a rongish understanding of Telstar's reply. After the install , of the A-virusprogram, I did a total scan and uninstalled the program again.
Yes Peter, sorry I did not tell you about the virtual memory. I had switched it off already before I started this thread, some two weeks ago.
I have to leave the house now, and will send some screenshots and loggings, no, no leggings, later in the evening.
Thanks all for the compassion,

Ed

I do not have other suggestions to you, except this:
-restart your pc
-open task manager/processes (tick show all users) and sort by cpu%
-check if there is something that goes above 5% most of the time, if so click on its properties and tell us.

[ivo]

Actually going through this thread makes me think that this one maybe a good answer to all questions ans concerns (have not tried by myself yet, will report here when done):

http://www.vlite.net/about.html

Has anyone tried it?

I have tried it for XP (for XP it is called nlite) and it is great!

Ivo

[AUDIODIDAKT]

Nice one Ivo,

http://www.msfn.org/board/windows-7-rtm-32-64-bit-updated-t137765.html

It can do W7 as well.............!

Will try it in the future


PS: If you can install programs too, its a kind of BACK-UP

[ed linssen]

Hi Telstar,

Thanks for your suggestions. I am working again with taskmanager. Processor duty only ecceeds the 5% barrier for XXengine3 and XXengine3.exe.
All the other processes about never pass the 2% line wile the average of the rest of the processes is a fraction of a percent.
I'll concentrate on disc activities and and prioryties. See what it delivers..

Ed

[ed linssen]

Hi Peter,

Some logs as you like them...
Hope tey tell you something!
Thanks,

Ed

[PeterSt]

Edit : NO !! Below textst about the "one core only" are all wrong. See next post.


Hi Ed,

Allright ... I won't say I solved it, but it looks like I can see the cause now. It is your Atom not doing what it promises plus what I said before : the program should error which it does not.

All may be caused your yourself at "tweaking" it for making one core of it (did you say *that* ?) while it - at least in its current state - still reports one core, but half or so. I don't know the effects of this really, where the program should error on addressing a core that doesn't exist ... (but which *does* exist I guess). Never mind this for now.

Currently there is "one processor" available, and the least I can say is that it is enormously slow. I know, I let you test this, but the test was not representative because I anticipated on two cores. Can't explain that, but it tricked me. Now :

The worst thing I see happening is that at track or file part boundaries there is not enough time for the processor to do its job. Actually - but I can not see that - it may be so that while something must be run in parallel it doesn't, and the parallel process only starts when the main process is finished. And the latter will be ... "playback".

On a side note - and as a measure for you - converting a whole album from FLAC should take 7-10 seconds, maybe double for a slower processor, but in your case this takes a minute. I think this is not because a way slow processor, but because in that stage the playback eats the time the conversion needs (by itself that is good).

So, during playback a process which is allowed to have 14 seconds and usually takes 4-5 for Quad Arc, in your case seems to take 16. Or at least the throughput time is 16, which is 2 too long for continious playback which will be somewhat less because of buffer stuff.

Long story short :

a. You may not have a multi core processor at all, but if so, a most slow one; or
b. Your processor runs in a one core mode, but can have addressed a 2nd core in the mean time (this is a processor or MS bug); or
c. The processor may have two cores but they can't be assigned for doing "work". That would be quite worthless.

Ed, if it is you having applied a wrong setting - or you may not exactly know when things are right, if you start an album like the one from the log files (needing FLAC conversion), look in the XX log file, and look for the ++++ and ---- lines. If you look at them now, you'll see a subsequent ++++ and ----; When more cores are active, you'll see ++++ followed by ++++ and ---- followed by ----. It is "mixed" (the ++++ denote the start of conversion, while the ---- denote the finish).
So at knowing this, you can test it at "back tweaking", of which I sure hope you can do it.

If you can't change it, I have a version for you which at least doesn't try to address cores which don't (officially) exist, and it may change the net result of things. But I'd rather that you get those cores to show, and I'm sure you would too ...

Peter

[PeterSt]

The before about the ++++ and ---- and my determination that this would show only one core is running, is false. Sorry !

There is a mode in XXHighEnd which just does it like this, although not really intended by me. And at least with Arc Prediction this mode is used, and some tests show possibly everything currently does (call that a bug by itself ).

This invalidates almost the whole of my previous post, weren't it that it would explain about everything to me - were it indeed so that only one core is used. For example, the *always* being short 2 seconds on the trackboundaries etc. can happen theoretically, but a. to me it looks outrageous that the particular process takes that long, b. you don't see a difference without Arc Prediction for the dropouts and c. it merely indicates that when at last the main process stops, that other process can do the work concerned. To be sure about this (and this *is* important) you may run one or three of those SAME tracks as from the topmost listed attachment without Arc Upsampling (untick Double/Quad as well). But start the whole album as before (just draw the log files when 3 tracks have played). Notice that the exact same behaviour can't be shown because of the less memory it occupies and the moments the other process gets active are different, but I guess I will be able to make something of it anyway. Please set the File size limit to 40 for this test, or otherwise the process may not get active at all.

Well, at least we can see that something is going on (wrongly), so let's see whether we can work it out for the better.
Peter