Hi there Zheng,

Let's see whether I can answer your questions adequately;

First off, digital filtering always comes along with upsampling. This is hard to explain, but I could try to convince you that only the upsampling step allows to have the result mostly the same as the original. Think like injected additional samples while the original samples remain. But mind you, this is typical for Arc Prediction and this means of filtering is far from common (at all).
The more upsampling steps, the more samples can be injected in between the originals. Thus, with 16x upsampling, 15 samples are injected between each 2 originals. Let's say that they imply (and hunt for) a better transition from the one original to the next original. Not "one big jump" but in 16 small (calculated) steps now. Or in two steps when upsampling is just 2x.

"Custom" Arc Prediction is not really different, BUT in this case a second stage filter is applied on top of the normal Arc Prediction. This is done the most mildly where the (possible) transients of Arc Prediction are sustained. In this case, however, the original sampling points are changed, as in any normal digital filter doing this, but with the notice that this is "measured" (by me with the analyser) to not noticeably change the transients. Do notice that a normal filter will change the transients notably, me always stating that it will changes violins into flutes (think micro transients, implied by the bow and the resin onto the string - the more resin the more "jumping" (transients) on the string).

The more times upsampling, the better the filtering can be applied (this is a story in itself). But notice that this is generally so, because it also can depend on the behaviour of the DAC at higher sampling rates (it needs to process more data and this in itself can be audible in a negative sense). And indeed it is so that some people play our NOS1 DAC at 352.8 instead of 705.6 (upsampled RedBook); less current is used now, which may mean that more reserve is there for stuff like again transients.

As you can see, the transients are almost a hobby-horse to me. The accurate rendering of them is key (in my view).

When playing out 44.1K (from 44.1K) no filtering can be active. Still it may be so that the software may "touch" other parts which again imply processing, but now in-software only. And mind you, as we know, XXHighEnd is "tweaking" all over the place and this is about processing (all over the place). Also more physical things may be in order, like you outputting 44.1K all right, but maybe outputting in 24 (or 32) bits, while the original is 16 bits. Officially this can't matter, but now physically it may imply half more data (or double) towards the DAC, which now must process it.
And as we also know by now, everything matters ...

What are the filters in the group [NOS] for? ony for Phasure DAC?

It is that you mention them, otherwise I never even saw them. I suppose they sneaked in the production version, from some testing a long time ago. Please don't use those.

I hope it is all clear a little !
Kind regards,
Peter

Funny ... If you look in here XXHighEnd Model 2.10 - Respecting Selection Sequences & SQ+ with uneven SFS and in there you search (Ctrl-f) for RAM-OS, you can see that I made something for it. But what you as the user must do for it ? no idea. Anyway, this has been made explicitly for those using the RAM-OS Disk twice (like for old Mach II and new Mach III - you'd just have the RAM-OS Disk twice (your case obviously)).

Fact is that the reference from within RDC always should go by means if IP address, with the notice that I see people have that working with the computer name. And at least that can cause problems to begin with. So probably the issue would be that you work with a computer with name RAM-OS and this is now the Music Server PC and that the RDC connection does not allow you to connect to that same name, that being the Audio PC.
What I had to make for that, I have no idea any more, but the Release Note I referred to tells I did.

Regards,
Peter

Hi there KNB,

I know what you mean and theoretically this can't be solved by means of "no re-activation" of the Music Server PC. However, a special "install" environment exists to cope with "this", noticing to myself that the "this" is quite unknown by myself by now, not even knowing what it exactly is what you want to solve. I mean, re-activating the Music Server PC can't be the problem, right ? (but ask for a new Code)

Real point is : the two times the same Computer Name is the recognizable issue for me. And I have made something for that, of which I forgot what it was ... (or why it was really necessary) ...

Regards for now,
Peter

Hi Joseph,

These are good questions. I do this from the top of my head now, so ask if you see different colors :

- No color (black-ish red) : Audio Engine (program) is not running at all. Notice that this can be incurred for by clicking the led (kill Audio engine).

- Blue : Audio Engine is in memory, but idle.

- Red : Audio Engine is playing Audio momentarily (should be audible).

- Yellow : Audio engine is playing Audio, but is Paused by means of Alt-E (continue with Alt-P).


Only the latter will do something to SQ, once it is in this sate for several hours such as 20 hours after Alt-E was used on the last Playback session (internal special quiet playback on-going).

I hope this helps ...
Peter

Hi Juan,


You seem to skip a step there, which is : check by means of TaskManager how many cores are active now. So if you had 12 (hyperthreded) in your example it should show 8. If it still shows 12 *there* something isn't working ... Esepcially not if XXHE=s Boot Menu shows the 8 after a reboot (Reboot is necessary !).

?

Kind regards,
Peter

Yea, see ? That changes the start-up sequence. In this case : first start the device(s) (they run now from the source as well as the target) and then connect the cable (it starts to push-thru right away).
Btw, leave it like this and better don't re-attempt. Haha.

Regards and thank you for the feedback.
Peter

*if* it works ...

Btw, I know of exactly *one* situation where it wouldn't work, but worked with all shields connected. Really, one only. But you seem to be more special because it workED. So in my view this has to be some environmental thing.

Please consider newly obtained stuff since you got it working in the first place (but never disconnected). This include light dimmers and the lot.
You can ask Alex C. - this all matters (but not meaning to bother him with this).

Please remember, the last time I tried, I too could not get it to work anymore, WHILE it has worked before.
And the sad thing : in some aftermath I found the possible reason ... which I thus forgot.

Hi Ramesh - Happy Easter indeed !

Maybe you can see something in the logging (but switch on logging, and if helpful in the end at all).

Regards,
Peter

And does it coincidentally work with all shields connected at both ends ?
Do notice that the sequence of connecting and/or switching on of devices, remains important.

PS: I hope you work in all circumstances with the same (isolating) switch setting of the ISORegen. I mean, that that's excluded from being the source of your "sudden" problems.
A hint could also be that something which is working "keeps the current flowing". Which is different from the necessity to set up this current flow; it may take different paths from the first time (long ago now) when you got it working. That switch could be an example ... change the switch position - it may start to work, and without shutting off anything, you might change the switch position and it keeps on working.

Well Ramesh, once you deleted that .dat file, and you restart XXHighEnd (but do that !) it should ask for the login data. And I think that should solve your issue to begin with ...

Peter

Let me think about this a little ... I have had similar, gave up on it, while only later it sprung to my mind what might have happened. But right now I forgot what that was !

A normal USB cable still works with that same chain ?

Peter

Ha, OK !

Yes, it works with avoiding the BASE OS.

1. Put in the RAM-OS disk;
2. Go to Boot Menu and change number of cores;
3. Answer "Yes, apply at next reboot" (similar);
4. Press Apply in the down-right corner (not sure whether this is necessary but I did that);
5. Reboot (by means of the same Boot screen).

What you enter there is the number of cores. I had 20 in there, now it's 24 (for a change, maybe I will hear a difference for my 28 core processor (like yours)).

Indeed in the boot screen you'll find back the by you set number.

Regards,
Peter

Hi Arvind,

I now wonder ... *can* it actually work with avoiding a boot into the BASE OS ? ... so I am going to try myself (I have this working for more than a year by now, so I forgot ...  ).

Best regards,
Peter

Hi Robert,

My 0.69 did not last long (referring to another topic), so back to 10.19 it is.

As far as I remember, 3 cores are only available for older AMD processors, and it is my estimate that you don't have that. So it has to round down to two (which exists for both AMD and Intel).


Assumed it really is so that Nick's method comes (in effect) down to the same, is thus is the same (haha), but, you can easily change it now.
Btw, I never tried Nick's method, so I don't know for real.

Best regards,
Peter