You are viewing comment page 10 of the post. View the post contents here.
Tip: Press Ctrl+F to search for a specific keyword or keyword combination.
We've noticed that you're using an AdBlocker
It's not just you, over 66% of our site's visitors are blocking the ads.
Please disable adblock for this website and refresh this page if you:
find the content useful
want us to create more useful content and software
want tech support through the comment section
The ads are placed so that there is minimal interference with page reading. There are no pop-up, pop-under or sticky ads.
Alternatively, you can support us by making a donation.
Hey,
This may sound like an odd request, but can you make it such that it doesn't automatically request to be elevated to administrator on administrator accounts?
On windows 7 an administrator account still isn't "The Administrator" which is what it is instead requesting to be elevated to. This causes it to conflict with some programs (particular my mouse gesture program) as it's not running in this mode and can't be used on windows running under this account.
Sure use it to update (though I'm not 100% sure why you need to), but can you please not make it auto request (I still have to go through UAC every time and it's a little annoying).
Thanks,
Pluckerpluck
Thanks for your feedback.
You can check what I replied to a very similar post a while ago.
What about giving the user an option to disable the auto-update in XonarSwitch configuration? Or make it a first-run decision. For example you could use a setup dialog which asks the user if he wants to use auto-update and install XonarSwitch with elevated privileges or if he just wants to run it with user rights without auto-update. Then you could offer an option "Run with elevated rights" which the user can tick on like "Automatically run at startup" and which makes XonarSwitch asking for Admin rights.
About making autoupdate opt-out, see this reply to a previous post proposing the same thing (although for different reasons).
Also things regarding privilege elevation and XonarSwitch are a bit more complicated than they look.
I strive to hide useless complexities from the user as much as possible and I don't want to change that kind of approach.
Nor do I want to remove the option to have a completely silent autoupdate for those who don't have any problem running XonarSwitch elevated under Admin accounts and appreciate the app doing all the work for them.
In addition to the previous points, I don't want the less tech-savvy users to have to set up autostart by themselves, so I want to keep that option in and I want it to work effortlessly in all supported cases.
But, depending on the privilege elevation and the kind of login account, the code responsible for autoupdate and autostart has to take a completely different approach.
All this to say that I'll support XonarSwitch running unelevated under admin accounts when I'll find a model of user interaction addressing of all these partially contradictory needs that I find acceptably simple and functional for any kind of user, no matter their usage scenario, and in line with the design of the rest of the app.
So it's not a massive problem, but it is terrible practice to have a program require admin privileges for general use. There's a reason this isn't the default for Windows anymore (as it hasn't been for Linux for years). I'm not saying I don't trust you, but you're now another point on my system that could be compromised. Windows 7 UAC works more like linux that previous versions. Just because I'm an administrator doesn't mean I can do anything I want. I still need to approve administrative actions (like "sudo" in linux when used on an account with sudo permissions) before those actions take effect.
It's just bad practice to have a piece of software that doesn't need admin permissions to run require them. But I respect your reasons for a seamless update system (especially during beta). I just think this is a bad tradeoff when it could just notify you of updates instead.
But a stronger reason for an opt-out auto-update (which is almost universally requested of every piece of offline software everywhere) is that your latest version may cause a bug on someones system while the old one didn't. Who knows when you'll fix that bug, but now your software is useless because they can't use the old version. There's a reason people use old versions of software, and you've taken that away from them (even if you are in beta).
-----------------------------------------------------------------------
Separate point though (bug). I want to have something plugged into the front panel that I switch to with hotkeys. However the profiles don't seem to properly switch between front and back when I switch between them.
When I try to switch back it doesn't always (it doesn't sometimes) revert to the back panel. Instead it will take whatever the speaker setting is (headphone, 2 speaker, 4 speaker) and put it in mode "FP ......".
I can switch to headphones by clicking the tray icon and choosing the proper output from the popup menu though, so it seems to be a profile problem.
Example:
Using profiles:
Profile 1 (RP HP) -> 2 (FP 2 Speaker) -> 1 (FP HP) instead of RP HP
HP can be anything, even if it doesn't exist on the FP, so:
Profile 1 (RP 4.0) -> 2 (FP 2 Speaker) -> 1 (FP 4.0)
I'm on windows 7 64bit.
Something is happening though. As the actual Front Panel profile is louder than the Rear Panel profile even though no settings change at all (only output should change, it doesn't seem to, yet audio changes).
It's really odd, I hope you can figure out the problem.
Also, Xonar DGX
@admin privileges. I have no problems recognizing that forcing the user to give administrative privileges to my app just for the autoupdate system to work isn't optimal, emphasis on "forcing". That's why I never said I wouldn't support XonarSwitch running unelevated under admin accounts.
What I said is instead that, before I do that, I want to find a way of covering all bases that doesn't take away previous possibilities, like an user voluntarily giving administrative privileges in exchange for a completely silent autoupdate. What's wrong now is the lack of choice rather than allowing the app to run in a mode you personally wouldn't, but others could have their reasons to like or even prefer.
What I want to get at is to give the user the choice to do what he pleases, and have the app behave coherently and as simply as possible in all scenarios while still providing an easy way to autoupdate and activate autostart. So far I haven't found a way I completely like to manage those options running XonarSwitch unelevated under admin accounts while simultaneously not changing the experience of those who want to just run the app and forget it. That doesn't mean I'll stop thinking of a solution.
The situation you see right now is the consequence of how a small app I had written just for myself has gradually evolved in something else, and not a personal statement against taking security seriously.
@ opt-out autoupdate. Here my opinion is the very opposite of yours. You end your thought with "even if you are in beta", but that's not a detail, that's the main point. This is a beta test. It means that it's a "do ut des" situation where I give you a free software under the assumption that you will help me make it better in exchange.
XonarSwitch can't "cause a bug on someones system", since it doesn't interfere with the system activity in any way or form. At most it can be bugged itself and crash or behave weirdly, which it has and surely will again in the future. But when a bug arises, I want people to be pissed and be vocal about it until I fix it. Sure, it might be frustrating for both me and the testers, but I don't want a beta to turn into a "Yay, free warez!" thing.
Nobody is forced to use a beta software: if you do, you accept it could be annoying, in exchange for having it available now, instead of having to wait for the beta to end and the software to be reliable.
@bug. The behavior you are experiencing has an explanation in the fact the Xonar Driver has two separate options for the active panel (front VS rear) and the speaker mode (HP, 2.0, 5.1 etc), even though the ASUS control panel (and also XonarSwitch, in an attempt to provide a familiar interface) sums the two options in one single combo box.
So, for some reason it seems when you switch profile the speaker option is correctly applied while the panel one sometimes isn't. The fact the volume popup window seems to always work is a detail that could help me find the problem. I find a bit weird that nobody else has reported this bug, but I'll see if I can reproduce it myself and then fix it.
In the meantime, you can use this little workaround I mentioned in an earlier post:
Create a new shortcut with the following command as location:
cmd.exe /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" "[...]\XonarSwitch.exe"
(Make sure you also copy the quotation marks and replace [...] by the path to XonarSwitch.exe)
You can't enable build in autostart with this, but everything else works fine. For autostart, simply place this shortcut in "%AppData%\Microsoft\Windows\Start Menu\Programs\Startup" instead.
Hey Giulio!
Unless I'm missing something there's no way currently to switch profiles and keep the volume unaffected. It will either use the last volume setting of that profile or a set value. Could you add a no change to that as well plz?
Thx!
No, you're not missing anything, currently there's no way to keep the master volume unaffected. I've added your feature request to my db.
Thanks for your feedback!
Ah I see! Thx Giulio! I suppose xonarswitch could check what the volume currently is and set the same volume anew to the switching profile, but I'm no programmer, I may as well talk nonsense 🙂 Cheers!
Hey Guilio
This program is exactly what i was looking for to be able to switch between headphones in my front jack to my sound bar plugged in the rear - however i have set the profiles up and the hotkeys but when i change profiles it seems to change my outputs on the profile to the reciprocal device on the front or rear jack. IE if i change from my FP Headphones to Rear 2 speakers - it changes the profile to FP2 Speakers rather then switching to the rear panel. or vice versa RP 2 speakers to FP headphones ends up wth RP Headphones - and all that ends up happening is the volumes change through whatever device was already being used. It works once or twice as it should before this happens though
This seems exactly the same bug Pluckerpluck reported above, that so far I haven't been able to reproduce on my system. What sound card do you have?
Asus xonar dg
Yes, this is the exact bug that I am having (including how it works once or twice before failing).
As I said I'm using the Xonar Dgx (so the same card basically) and am using HD audio. I'll try messing with the auto detection to see if that's causing the problem. But the fact it works outside of profiles makes me think something else is the problem.
It looks like a XonarSwitch bug indeed. Something related to some characteristic your card (DG/DGX) has and mine (DX) doesn't, which would explain why I'm not able to reproduce it here.
Do you guys use the DG HP amp? Anything specific the profiles triggering the bug have?
To help narrow it down:
1) It doesn't not seem to matter whether I have the detection set to HD Audio or A97.
2) I have 3 different profiles, 2 set to HP and 1 set to FP. This bug occurs no matter which of the 2 rear profiles I select in these:
a) 1 is 2 Channels (same as FP), the other is 8 channels + dolby headphone so that doesn't matter
b) Volume is at use last
c) SVN is on don't change (and off)
d) Everything else is ignored
Basically the only thing that's the same is the fact that almost everything is ignored. It happens on any rear profile coming from the front panel. I have no HP amplification on (profiles ignore it) and it doesn't matter what the sample rate is.
Whatever the problem is it doesn't seem to be a standard settings problem. At some point I might try actually unplugging the FP to make sure that's not affecting it in anyway way.
A more interesting thing I noticed though is it will ALWAYS work if I save the profile before trying to switch to it (whether or not I change anything). As in, it will work the next time I switch to it from FP (I don't have to switch straight away).
So that's why it will always work once. If I haven't switched to that profile yet I know it will work first time. Hopefully that helps you find the problem.
Of all these details the most interesting one is the last one: the fact a profile always works if you save it first.
Can you please send me an e-mail following the instructions above under "How to contact the author"? I have a couple of things I'd need you to check for me and, depending of the outcome, I might need you to test some changes to see if they improve the situation.
"Added system bit depth and sampling rate options under Windows Vista and later operating systems. [...]"
I don't get this. What' shared mode? How would I know if I should touch it?
When an application opens an audio session to play sound, it can request to do so in exclusive or shared mode.
In exclusive mode, the application is able to directly affect the audio card's bit depth and sampling rate, so if you for instance listen to music using the WASAPI plugin in foobar, the playback will always be bitperfect no matter your audio engine and card settings. In this case, the new options can be safely left to "Don't Change", since they don't matter. The downside of exclusive mode is that it's... exclusive, and that means no other applications can output sound.
Shared mode, instead, is the normal way of listening to multiple sound sources where, for instance, you can have iTunes screaming out your favorite hard-rock compilation while simultaneously playing a game. Since the card is one and the sound streams several, the audio engine has to mix the sources together before it sends the resulting stream to the audio card. In doing so, it resamples all sources to the values specified in the advanced tab of the card speakers properties in the system sound control panel, unless they already match those quality settings.
At that point, the card driver receives the mixed stream and does the same before sending it to the hardware for the final output: it checks if the source quality matches the inner setting of the card (the sampling rate that has always been in XonarSwitch and is now called "Card Sample Rate", to distinguish it from the system sample rate) and if not it resamples it yet another time.
So, for instance, if the windows audio engine is set to DVD quality (16 bit / 48 KHz) and the Xonar card to 44.1KHz, and you play a CD, a lot of resampling happens: first, the audio engine upsamples the CD stream, which natively has been recorded at 16 bit /44.1Khz, to 16 bit / 48Khz, because that's the system value for shared mode, and then the Xonar driver downsamples the 16 bit / 48Khz stream received from the system to 44.1 Khz, because that's what you are instructing it to do via XonarSwitch (or another control panel).
Resampling can be bad, since it alters the original sound data, and audible artifacts might be introduced as a consequence, so ideally you don't want your source to be resampled, let alone be resampled twice. The purpose of the new parameters is to let you change the system settings on-the-fly and via profile switching, instead of having to open the system sound control panel and change the values there, if your current settings don't match the source you plan to play. So you can for instance create a CD profile and a DVD profile and by switching to one or the other, have both the system and card playback quality match the source recording quality.
I hope this clears things a bit for you and others that might find the new settings too cryptic.
Okay. I understand now. Still don't see any “Don’t Change” options though I only have an equals sign. I have win 8.1 x64, so I should have them right?
I can safely set it to 24 bit without quality issues right?
(Just remembered something. If I have the digital output disabled is it normal for the soundcard's connector to be producing red light?)
The "Don't Change" options are visible only in the Profile Editor. The Real Time Settings window reflects the current state of your card and thus in most cases "Don't Change" wouldn't make a lot of sense and isn't present.
Yes, setting bit depth to 24 won't adversely affect your 16 bit source playback quality. At the contrary, it is beneficial, since the extra bits can be used to avoid losing sample resolution when your master volume isn't at 100% and therefore digital attenuation occurs.
I don't know the answer to your last question. Maybe some other tester or CarvedInside do.
Hey since the update today my virus-scan goes mad and always says Gen:Variant.Symmi.21539 Virus has bin found in xonar-switch. maybe the file you uploaded got infected?
Nope it's just an old false positive problem which resurfaced. I'll submit the new XonarSwitch to BitDefender so they solve the problem. It should be fixed within a couple days.
It's weird your false positive isn't listed here though:
https://www.virustotal.com/it/file/3d801f293505e64c7e43638f0f3e76006cb3726e4db0d1e85858f16bd1bda171/analysis/1391018792/
ah maybe i have old signatures. sorry for the mess. great software btw. i own the xonar essence stx since 3 years now and despite it's a great soundcard, the software was always a pain in the a**. you have no idea how happy you made me when i found out about xonar-switch. now i am able to use the card the way i intended to, when i bought it.
Hey Giulio,
Thank you for the support you have provided so far its awesome. But there's a problem though, after the new update I've been getting issues with the sound. For some reason when I'm listening to music, watching videos or playing games the sound would lower after a couple of minutes of using my computer. Note my volume levels would be at the same level I left them only the sound would lower for some odd reason. I don't know what may be causing this issue but here's what I'm using.
Asus Xonar Essence STX
UNi Xonar Drivers 1.72 (low DCP lantecy)
Rear Headphones
Windows 8.1
Could you please look into this?
And one more thing. The sound returns back to normal levels after I close every window and run CCleaner but that only fixes it momentarily and the issue returns back again.
Thanks in advance!
Thanks for your feedback.
If I understand correctly, you say you hear your sound decreasing after a couple minutes since you start playback even thought the numeric value of the master volume is unchanged.
XonarSwitch can't affect the output loudness without materially and visibly changing the system volume, or in the case of your card the headphones AMP gain, because it doesn't attempt to process or alter the sound stream being played in any way. What you describe seems more like the effect of SVN being on. SVN does just that: it automatically regulates the effective output loudness without the system volume value changing.
Maybe you have done this already, but if not please left click once on the XonarSwitch icon and verify that the SVN button isn't pressed and blueish. Or open the Real Time Settings window and make sure the SVN "disable" option button is checked. If SVN is enabled try disabling it to see if the volume fluctuations go away.
If not, the only other thing I can think about is, if you use your card's headphone amp on a gain value other than zero, check in the amp dialog box of the Real Time Settings window and see if for some reason the amp gain has decreased after you heard the volume going down.
I think I have a bug. Have had this problem since re-installing windows(8.1) and have narrowed it down to this.
If xonarswitch is allowed to start automatically at log on, two things happen;
1. The windows start-up sound cuts out.
2. Non windows system tray icons disappear/don't load (volume and network are OK).
And to make things worse, its doesn't happen every time - but more often than not. If xonarswitch auto-start is not enabled windows starts OK every time.
Default profile: Rear Headphones on Essence STX. Options changed are:
Vol, 35% | SVN, off | Channels, 2 | HP Amp Mode, Normal Gain | DH, On (Studio) | PLII, On.
Bit/sample rate is on don't change.
Have rebuilt the icons a few times but the problem persists.
ie4uinit.exe -ClearIconCache
taskkill /IM explorer.exe /F
DEL "%localappdata%\IconCache.db" /A
shutdown /r /f /t 00
Sorry, ignore my last comment.
System tray icons are still not showing up randomly, thought I'd isolated the problem - restarted a few times and it all worked without xonarswitch on auto load for a while.
Where are stored profiles?
Profiles are stored in the registry under
HKEY_CURRENT_USER\Software\XonarSwitch\Profiles
Why not in a config file? 🙁
I have formatted my PC and now I don't have the profiles 🙁
You seem to imply you wouldn't have lost the profiles if they were in a file. Does that mean you have a backup of your old setup? If so they can be recovered.
Well a lot of people store programs that don't require installation on non-system drives.
Storing application config files in the same folder where the executable resides is an old concept, used in OSes based on the FAT file system, which didn't have per-user permissions.
Since the adoption of the Windows NT core by both consumer and professional Windows versions, and therefore the widespread use of NTFS instead of FAT, it's more practical for an application to either use the registry (which is what Microsoft recommends for desktop applications) or to store the config files under the "%USERPROFILE%" folder, which doesn't pose writing permission problems to any process and is on the system partition.
That means that, unless you have a backup of that partition, you end up losing your config files anyway when you reformat.
"”Real Time Settings…” has replaced “Profiles…” as the default tray icon action that is triggered when double clicking on the tray icon."
Yay. A great change.
Awesome release! 🙂
Hey thanks for new revision! Works great dude! greets
Hi,
nice release, I like the new funktions but "/InputMute=0" (or any other number) doesn't work for me. May I do something wrong?
Thanks
How did you try it? A couple of considerations:
- /inputmute won't affect monitoring. Since the Xonar cards don't implement a hardware mute on the inputs but only on the output, the input muting is achieved via windows audio engine, but monitoring is done directly in hardware and thus bypasses the windows audio engine.
- If a normal instance of XonarSwitch was running in the tray and you didn't include the /NoUI switch, XonarSwitch actually warned that another instance was running and did nothing. There are some circumstances, however, when message boxes can be suppressed, like for instance when using the system scheduler, and it could appear the command line argument just wasn't working.
A reliable test to see if it does what it's supposed to, is to open the system sound control panel, go to the recording tab, double click on the microphone endpoint and then check on the Levels tab that the speaker button on the right of the volume slider has the little prohibition sign on it.
Thank you very much, it actually worked but I tested it with the monitoring.
Hi, why are swapped front and rear channels in realtime settings? Speakers are plugged in front jack (next to spdif). In the control panel (Cmedia) I see "Front" when I turn to "front" in xonarswitc then is quiet ... when I turn to "rear" it plays ...everything except the "rear" s grayed. I have Xonar DX.
If I understand what you mean, the front you are referring to is front speakers as opposed to side or surround speakers. In XonarSwitch's output combo box, Front means front panel, i.e. the case connectors that may or may not be hooked to the internal card connector, and Rear means rear panel, i.e. on the card's plate.
So if you have stereo speakers connected to the rear green 3.5mm jack, you have to choose "Rear 2.0".
Then everything is fine, thank you for the explanation. I was a bit confused... 🙂
Too bad the mixer still only appears on second try most times.
Do you mean the system mixer with the application volume?
Yes. At first try it's just immediately closed. I only see it for a split second.
That bug was reportedly solved in the past, and since then I haven't been able to witness that kind of behavior again. That means that, even if I change the code that displays the mixer window, I have no way to test if it improves things or not. At most I can verify it doesn't break what's working now.
If you write me an email (the instructions are above, under "How to contact the author") you can test some tentative solutions, since you seem able to reproduce the problem quite reliably.