XITE-1 Laptop Recommendations?

[garyb]

you'd have to make one...

[mike.kennedy]

Thanks for all the info about Apple Bootcamp and low profile adapters! It really helps to draw out where the main issues can be found for each solution.

In the meantime, I have been making significant progress on the option 1 - Legacy laptop.. Dell M6600 or M6800 at least for Windows 7 or 10, respectively. I will post further info when I have more time, but essentially, I have implemented a workaround for the ACPI driver latency and can now run Scope with no dropouts at the top ULLI setting. So I'm rather chuffed..

Mike

[Bud Weiser]

Is that ACPI driver latency workaroun a general solution or is it for the DELL laptops mentioned above only ?
I´m interested in how it´s done and how it works.

In addition, I wonder if a Win10 22H is better than a Win11 21H installation.

I recognized, I don´t get updates beyond Win11 21H for my Lenovo W541 anymore,- so it´s more or less set in stone except some security updates for the time being.

So,- downgrade to Win10 22H from Win11 21H ?

If yes, how to downgrade ?
I have no clue,- never had to downgrade before.



Bud

[mike.kennedy]

@Bud

Here's a link to the ACPI workaround:

https://www.tenforums.com/sound-audio/1 ... mance.html

The solution describes how it can be implemented using Microsoft Task Manager. I should imagine that it is equally valid in Windows 10, but I have not upgraded my backup laptop from Windows 7 to test this yet. If you have Bitsum Proceess Lasso, it is a simple task to change process affinity so that it is applied every time the system is booted. I now have only 3 cpu cores available for AudioSrv, but there is no longer any audio glitching from the ACPI driver intermittent latency. I can also get the Scope ULLI setting down to the lowest latency setting, which was not possible without severe problems before I implemented this workaround.

While I'm at it, it's also worth mentioning another configuration tip that I found useful to avoid latency from IRQ contention, and that is to switch the Scope XITE-1 device to Message Signaled-based Interrupts-mode in device manager. Here's the rationale and description of how to implement this: https://forums.guru3d.com/threads/windo ... ol.378044/

Anyway, these solutions have resolved some significant issues for me, and at the moment, I am cautiously optimistic that there are no more sharks lurking in the water.

I hope they are of interest/use for others with similar issues.

Mike

[valis]

This is a core parking issue if affinity helps this specifically. While cores won't necessarily be "parked", the OS scheduler generally attempts to move things around to resources that it thinks will be most available, based on the % of compute (thermal/usage and power state are related) available from that resource. When scheduling on a different core because the scheduler "decides" to to do so, it may actually cause a spike when accessing the peripheral due to all of the related resources that need to be freed up, spun down, spun up or etc.

I would actually recommend installing Process Hacker for managing affinity and process priority, if you have it set to run at startup it has facilities to set all of your associated settings on boot (it gives you this option to do this in the setting dialogue for each setting). Ie, you can set both affinity and priority for a process (or a given service) and it will "remember" that setting across reboots. Useful!

[Bud Weiser]

@Bud

Here's a link to the ACPI workaround:

https://www.tenforums.com/sound-audio/1 ... mance.html

The solution describes how it can be implemented using Microsoft Task Manager. I should imagine that it is equally valid in Windows 10, but I have not upgraded my backup laptop from Windows 7 to test this yet. If you have Bitsum Proceess Lasso, it is a simple task to change process affinity so that it is applied every time the system is booted. I now have only 3 cpu cores available for AudioSrv, but there is no longer any audio glitching from the ACPI driver intermittent latency. I can also get the Scope ULLI setting down to the lowest latency setting, which was not possible without severe problems before I implemented this workaround.

While I'm at it, it's also worth mentioning another configuration tip that I found useful to avoid latency from IRQ contention, and that is to switch the Scope XITE-1 device to Message Signaled-based Interrupts-mode in device manager. Here's the rationale and description of how to implement this: https://forums.guru3d.com/threads/windo ... ol.378044/

Anyway, these solutions have resolved some significant issues for me, and at the moment, I am cautiously optimistic that there are no more sharks lurking in the water.

I hope they are of interest/use for others with similar issues.

Mike

Thx a lot Mike !
It´s a lot to read,- so I bookmarked.



Bud

[sunmachine]

These are two small PCs with a full-size PCIe slot I found:

https://www.shuttle.eu/en/products/slim/xh510g (25 × 20 × 7.9 cm LWH)
https://www.shuttle.eu/en/products/slim/xh510g2 (25 × 20 × 9.5 cm LWH)

No idea if they would work with the Xite-1 interface card and how loud they are, though.

[mike.kennedy]

@sunmachine

Thanks for the links to the shuttle boxes. Either of those could be configured to perform way beyond 4gen Intel i7! PCIe integration looks promising, but depends on bracket size and orientation, I guess. Worth investigating further if I opt for a brand new PC as a replacement.

@bud - I hope you find the info useful.

@valis - I have core parking disabled, so it's a bit disconcerting if the Microsoft scheduler is still trying to shuffle things around regardless. I don't have visibility at a detailed level of what is going on when the ACPI.sys dlc latency goes through the roof, but if you google it, it seems to have been a bugbear for audio users on Windows for many years. A lot of the time people ascribe this problem to "badly written" ACPI drivers or software, whatever that means, although there does appear to be some inappropriate resource locking going on.

I'm assuming that this code comes from component manufacturers rather than Microsoft, so any fix immediately becomes subject to a finger pointing exercise, where neither party wants to take on the effort or cost of implementing a fix to an issue, which is probably of limited interest to 95% of Windows users (if they're even aware of it).

Therefore, the pragmatic suggestion to isolate the ACPI process on a different core from the audio process and which seems to effectively deal with the latency issue is a significant step towards rehabilitating my XITE-1 based computer audio workstation for reliable recording and playback.

Thanks for the recommendation of process hacker. I read that it's good for analysing the behaviour of malware. Should be ideal for looking at Windows systems .. Seriously, looks like a great open source tool.. Will be investigating..

[valis]

@valis - I have core parking disabled, so it's a bit disconcerting if the Microsoft scheduler is still trying to shuffle things around regardless. I don't have visibility at a detailed level of what is going on when the ACPI.sys dlc latency goes through the roof, but if you google it, it seems to have been a bugbear for audio users on Windows for many years. A lot of the time people ascribe this problem to "badly written" ACPI drivers or software, whatever that means, although there does appear to be some inappropriate resource locking going on.

I'm assuming that this code comes from component manufacturers rather than Microsoft, so any fix immediately becomes subject to a finger pointing exercise, where neither party wants to take on the effort or cost of implementing a fix to an issue, which is probably of limited interest to 95% of Windows users (if they're even aware of it).

Therefore, the pragmatic suggestion to isolate the ACPI process on a different core from the audio process and which seems to effectively deal with the latency issue is a significant step towards rehabilitating my XITE-1 based computer audio workstation for reliable recording and playback.

Thanks for the recommendation of process hacker. I read that it's good for analysing the behaviour of malware. Should be ideal for looking at Windows systems .. Seriously, looks like a great open source tool.. Will be investigating..

Disabling core parking really means you've disabled C-states and possibly some of the P-states if you put the processor into a specific fixed state across all cores, but surprisingly even when you do the latter the Windows kernel will still attempt to schedule resources as it sees fit. Which is why I phrased my response the way I did, the scheduling of resources will still conflict with peripheral management (hence the DPC latency hit) due to moving the hardware i/o access calls to a new core rather than just leaving them in place to keep servicing the peripheral from the same core (and thus the same code and IRQ/memory mapping etc staying actively assigned to that core). This last point is in fact what you were addressing with your 'fix' hence my recommendation for a tool that will auto-apply it on each subsequent reboot (saving you a bit of time & hassle).

Back on the subject of power management, the fact is that Windows will in some cases even override certain portions of what is set in the BIOS/EFI layer, so it's always best to double check from powercfg.exe (run from command line) and do the proper registry settings in Windows to correspond to the way you configured your BIOS/EFI (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power\PowerSetting).

Note I make no presumptions/assumptions here about what you're specifically doing, simply conveying what I know to help you cover all the bases.

[mike.kennedy]

Thanks again valis!

It's really handy to have all this relevant information documented here.

I had already implemented a persistent Process Affinity configuration using Process Lasso, which I've licenced for some years now. As I said, I will definitely be taking a look at process hacker, which may well be a preferable cost-free solution. Thanks for suggesting it.

One small point, I consider the resolution of the ACPI dlc latency incidence to be a workaround rather than a fix. As such, it does not offer a solution to the root cause of the underlying problem - and it does cost 25% of the available processing power on my 4-core system. But I would say worth the sacrifice to achieve a dropout-free XITE-1.

On another note, I've sent my blown-up laptop to the local PC Tech repair company to have a look to see whether it can be easily repaired. It seems to be some internal power issue, but the question is whether this has fried a range of components on the motherboard or is limited to a cap or fuse that could be replaced.

Mike

[valis]

When you set process affinity, it does not stop other processes from using that core. You simply ensure that that process never moves. You should have the same amount of resources as before that setting for other tasks.

[mike.kennedy]

I've actually segregated the relevant services by setting the affinities such that I have the power service running on core 0 and the audiosrv running on cores 1,2&3. That seems to work really well (beyond expectation) on my backup M6800 on Win7. I'm pretty sure I tried some other configurations when I was setting up the affinities for the 2 svchost.exe processes concerned, which didn't pass my testing with latencymon. However, I'll have another look tomorrow at whether the full segregation of relevant processes is necessary for ACPI to behave without causing excess latency and post my findings back here...

Mike

[valis]

A 17" precision shouldn't be that bad at power management, without digging in further my take is there's an errant peripheral somewhere that's eating bus time.

Do you have provision for another internal drive, or a large enough boot drive to create a second partition that clones your existing install? Here's my usual process, and why I ask:

When I do a base install, I clone to an external full image as backup (rather than using backup software) so I can 1-click restore known good base OS image. Then I start tweaking my base install + driver stack. I learn from making mistakes, and generally revert to the base install and build up what I figured out works. I also either fully TEST a system before deploying this way, or if that's not doable I use a secondary partition/drive with that clone restored to it to do my testing, until I'm sure my build process is ready for deployment.

Doing the above will help you mess around with any relevant system drivers/components without impacting your base install until you're ready, assuming you need the machine to remain productive. Recommended.