New Member :-) Hello and some information please!

Hello, I’ve been using Audacity for some time, and love it. It’s not something I need all the time; but, when I do… it’s my go to for sure! I’m on a Newer PC (1 year) using AMD64 and running Windows 10 Pro. I’ve been a programmer and developer off and on my whole life, and like many, have ‘kind of’ run into that old familiar SidebySide Event in my logs. Fortunately for me, I’ve found settings that work just fine using 2.1.3 and it works as well as I’d expected with the way I use it. I don’t often run Audacity through its paces; but they seem fine too; or, if any issues, it would be an old memory.

So, digging into the WinSxS issue on generating events, I’ve discovered in various sources, and examining the manifests in the SxS directory that the issue is a conflict between two existing versions of a component, as stated in the Event Viewer. The problem seems to be a conflict between AMD64 and x86, and thus there are two identical manifests that seem, so far, to only differ in the ProcessorArchitecture designated.

I haven’t figured out which one is actually being used by Audacity since my understanding is that AMD64 is pretty good at handling old x86 stuff. But, I realize that to eliminate the error, I would have to have or make a copy of Audacity that allows one of those manifest conflicts to disappear. It seems to me that if Microsoft was smart, this wouldn’t even be an issue, as long as backward compatibility exists.

Can anyone direct me to information that gets into the nitty gritty of this issue, like what’s been tried or someone who’s familiar with it. It doesn’t seem like it would be that horrific of an issue, but it’s still here which is highly empirical evidence of a big issue. I think one of the reasons it may work well for me is that I use H32 (NVIDIA High Definition Audio)(loopback) as both my recording and playback device. I’ve had other configurations that worked in the past; but, I would have to play around with it again. Just noticed it on my new machine that it’s completely using NVidia drivers for the first time; I think my other machine I had to use different settings (the error was on that one too) and it was an AMD x86. (I think AMD was switching, or thinking about switching the name of the processor to AMD64_x86, and wonder if that might be an issue.

But, I’m just trying to seek to understand this a bit better from the Microsoft (Painful) side of things. I’ve had this event filling my Viewer for quite some time (years), and it grows tiresome. And, of course, SideBySide isn’t easily removed. Last time I did it I broke Edge for months before MS fixed it. (No loss, didn’t even miss it.) But they fixed SideBySide too. But, that was when MS liked to default to Edge. Things are different now. Feels like Netscape all over again; but, hey… all we get is an error message… and if it ain’t broke…

Anyway, it just seems to be a tiny thing at first glance; and it seems there might be some solutions, like one I saw recommending a technique at the code level that could be a workaround. Here, “I am getting this error how to solve this error”: [url][/url].

So, Hello… I go by Chip, nice to find this. I’d like to help… sure would be great to be able to use Audicity with a more recent version. I see that Windows is not really supported now. Perhaps this issue is one of the main reasons; perhaps there are others. Any info on that would be great too. So, let me say Thanks… hope it’s not TL/DR for anyone. And thanks for letting me see where I can go with this.

The current version of Audacity is 2.3.2 and is available via the Audacity website:
The “side by side” error was fixed about a year ago.

Fantastic! That is great news. Thank you so much for the reply! Troubleshooting and Debug mode off!

Since my original version is a standalone; I’m wondering if it matters if I wait to uninstall it after I use the new version. I’m actually having other issues related to the latest v18… update that I need to resolve first!

It’s “possible” to have multiple versions of Audacity at the same time (but only possible to run one version at a time), but it’s not recommended. One of the problems of having multiple versions is that Windows is unable to handle file associations correctly if there is more than one app of the same name.

I would recommend removing your old version, and then installing the new version. If you want to revert back to the old version for any reason, then you can get the old version from here:

Thanks for that. I figured that would be the primary issue. Yes, I understand. That means, only open files from within the application, not from an extension association. And if there’s any internal conflict on resource interpretation, uninstall both versions, and reinstall the one wanted. At my own risk, of course.

The only aspect I’m wanting to test out is the ability to make internal wireless connections. As long as the new version can recognize my NVidia internal (loopback) and playback, what I’ll need, I’ll dump the older version. You’d save me a bit of work if you can confirm loop back recordings work.

For DMCA Takedown purposes, I just need this for fair use. I could just do this with video capture, and strip out the audio if I needed it; but, I find it easier to just record the audio and edit; Audacity is a great audio editor! I use it when I want to create a review, or for educational use, a digital audio publication source.

Originally, for me, this issue looked like Microsoft interference to thwart non fair use of the DMCA, doing some internal policing. As it seemed to only interfere primarily with wireless connections I could see no real reason why Microsoft couldn’t or wouldn’t continue to distinguish between two different Processor Architectures on a same name .dll and defaulting to the local directory version. But, this does create updating issues and if improperly reference in the source could create unexpected problems, especially for something like a “common” control. But, as I recall early on, during the years of DLL HELL, they allowed specific ‘same name’ .dlls with different versioning to exist in the main folder of the application runtime, to avoid such conflicts. As long as CPU manufacturers continue to maintain x86 backward compatibility, x86 will be a useful architecture, properly constrained and monitored. But, at least now, Audacity resolved the issue. Kudos for that! Much appreciated. And thanks to the community for this support!

I’m retired; but, as soon as I can I’ll be sure to throw a donation this way!