Noise in 9s-1

[Leo]

Good morning Peter,

Just had very little time to evaluate the newest but I did run into  a problem. After playing for some time a lot of crackling noice appeared, same sound level as the music. Pressing stop and restarting fixed it. But happened again later on. I forgot to look at the Taskmanager at that time.
I noticed before that however that the CPU seemed more busy than with previous versions with a spiky pattern of CPU use (running scheme 1)

Vaio notebook, USB to Maudio Transit optical to Altmann DAC. XX: Inverted, double (88.1), q=14 scheme 1, unattended.

[PeterSt]

Thanks for reporting this Leo.

What if all Priorities are set to normal ?

[Leo]

I will try that  tonight (late). What surprised me was that it took some time before it started and than it was continuous. Only stopped by STOP.

[PeterSt]

I am not sure what I am going to do with it yet, but you could copy the screen of the CPU useage in here (just during normal playback), which might tell me something. My question is also related to my perception of it being the other way around : the CPU useage is *less* spikey (Unattended Playback !).

[Leo]

I will do that. Could the fact that I use the 'double'  option  have something to do with this problem ?

[PeterSt]

Yes Leo, if you did not use that before, then now it can be too much. Rough estimate : it will use 4-5 times more CPU.
But ALSO it requires a larger buffer size !
The Q1 setting will be related as well ...

Remember, only when you before did not use Double. If you already did, it's a different story (but which, hehe).

[Leo]

I have used 'double' allready for a long time, even in my ignorant  XP days. I can do that because I use an Altman DAC which is a nos-dac  but nevertheless can process data at the more serious Hz rates 

And  'buffer size' as in amount of memory ?
Also I will play with the Q1.

Pff will not all be done tonight though, work, work work....

[PeterSt]

And  'buffer size' as in amount of memory ?

No, it would be at the receiving side of the soundcard/DAC. In your case it won't even be adjustable, and besides that, it worked before. So never mind.

Testing ? maybe also never mind, and better try again the old (XX) situation whether that still works.
If so, your attention must go to the Core Appointment (switch it off is best to check things) ad well as the Priorities (set them all to normal and see whether it helps).

Take your time ... you are not rushing for me ! (only for yourself)

[Gerard]

And  'buffer size' as in amount of memory ?

No, it would be at the receiving side of the soundcard/DAC. In your case it won't even be adjustable, and besides that, it worked before. So never mind.

Testing ? maybe also never mind, and better try again the old (XX) situation whether that still works.
If so, your attention must go to the Core Appointment (switch it off is best to check things) ad well as the Priorities (set them all to normal and see whether it helps).

Take your time ... you are not rushing for me ! (only for yourself)

Today i had the cracks again. Even with XX on a different harddisk. But i have set the  q1 to -4. When i moved the Q1 to 14 it was gone.

Grtz

[Leo]

I've been trying all kinds of combinations, and found that using your settings worked best for me as well. Lower values of Q gave distortion and hickups. But also the double was indeed asking  a lot of CPU up to 35 %.  Without that I get max of 7 or 8 %. And a very nice SQ. LAte again for work !

[PeterSt]

Somehow we must go the route of trial and error what is causing this in your systems. But not now, because it needs conveniently shutting down the Processor Core Appointment, and I don't think this is in there (like the before version which could realtime do it by unchecking the checkbox which was in that version).

Also, I'll try to find some means of capturing what's happening, reporting the buffer size of the DAC and all I can think of in order to attack these IMO unnecessary happenings. No matter all is stressed indeed, it should be able to cope with it (proved by before versions).

Two questions for Leo :
- Did you try this Unattended ?
- Could you please provide your data in your signature like the others do ?


PS: There is no way you should be using 35% CPU, not even with Doubling (then 5-6 or so). This seems a pattern for those with crackling ...
Leo, what's you CPU (and rate) ?

[PeterSt]

Gerard, I can't be sure whether you did this already :

Your reocurring cracklings should be caused by Unattended Playback (or playing FLAC/MP3 in general), and XXHighEnd reciding on drive C:.
So, if you put your XXHighEnd folder on the music drive it may help.
If you already did that, I don't know yet ...

[Gerard]

Gerard, I can't be sure whether you did this already :

Your reocurring cracklings should be caused by Unattended Playback (or playing FLAC/MP3 in general), and XXHighEnd reciding on drive C:.
So, if you put your XXHighEnd folder on the music drive it may help.
If you already did that, I don't know yet ...

Peter,

I did not move XX back to C:... Even on the other drive ( wich also contained my music ) I had the cracks back. But sliding the Q1 back solved everything...

Grtz....

[PeterSt]

Ok Gerard. For me, however, it is not the real solution. I mean, if you were able to play with Q1 lower, and now that can't work anymore (because of crackling) I want to understand why ...
Actually, for you it should be something not to "accept", because the Q1 is there to create the best sound for you, not for avoiding crackling.

For others : above only counts when you could proove (in the past) that the lower setting worked without crackling.

Lastly, it becomes more or less complex, since the lower settings of Q1 require more from the CPU; no matter it is far from 100% (or 50% looking at the one servicing core) it is about "response times" of the CPU. However, the more it's busy already, the less responsive it will be.
At the far end, those with, say, more than 10% CPU useage during XX playback, should first look into their system where that comes from. Compare with XX closed etc.
BTW, I am not *urging* for answers, but I kind of hate it when you can't achieve quality which should be possible to achieve from theory. Worse is that it worked before, and the most worse is that (for some of you) in an earlier version it did not work, then it worked, and now not anymore.

The only things changed in this direction is the priorities and appointment (processor affinity). Playing with those might (or actually should) help (better/worse), although I realize that these are lengthy processes.

As a reference, please note that -as I always claimed from the beginning- there is no way I myself can impeede for the smallest crack or glitch, not even with a SataII -> SataII heavy I/O backup (say one album per 4 seconds) from the music data, lasting many hours and playback keeping steady (as I did yesterday evening with 0.9s-1 Attended, playing music from the same disk as the backup source).
During this process my CPU is never above 5% (2x 2.4GHz processor).

Sidenote : When I say that cpu should be under 5% during normal playback (which obviously is related to the cpu rate), I am referring to SPDIF and RME (Fireface) drivers. Do note however, that when I'm using USB, cpu useage is virtually ZERO (like the right-side core looks at playback, but now the left-side is so too). Thus ... anyone using USB (with legacy (MS) USB drivers) ... if they have 10% or even 35% ... something is very seriously wrong in your system.

[Gerner]

Even I did not have the addressed problems for quite a while, I remember though when the RME FF was in the game here, that no cores here showed more than a max 2% activity when all kind of s*** were going on, me backing up and so on while the music were playing.
Even when the sound went into a cracle mode in the past, the cores didn't show more than 2% activity.

So Peter you are right, there must be something else eating those processors capacity and it can only be a question to find what it is.

Gerner