Ok i got you. It says "Select the sample rate and bit depth to be used when running in shared mode" WHat is shared mode ? and if i choose 192khz 24 bits and follow up with playing low quality mp3, what will happen ?
That depends on your sampling algorithm.
Playing at a higher bit depth (24) when your music is NOT at 24 does nothing. At best, it gives you finer control of the volume, at worst it does nothing. That depends on who is controling the volume: software or windows. If windows is controling the volume, you have a 16 bit signal being played at full dynamic range into windows sound, then you are controlling windows interface directly in terms of output. This is not ideal, and this i the point of WASAPI and ASIO output modes in the first place. If the software volume is the one being controlled, you are instead doing a 16 bit to 24 bit conversion, but the number wont change. IE you can only count from "1 to 10" with 16 bit, evn though 24 bit lets you count from "1 to 100", so if your source file is 16 bit, playing from a 24 bit output will do nothing but let you set the volume to "10". I hope that simplified things, its not really correct to say, but for the sake of understanding, its an OK example. Alternatively, you could map the outputs 1-10 to the output levels of 1-100, and that means that changing your output by 1 will change the volume of your source by, technically, 1/10th. So really it depends on how its implemented.
So just use wasapi and save yourself the headache.
For upsampling: it depends greatly on how it is implemented. Best case scenario: nothing happens. Worst case scenario, noise and crap is introduced into your stream.
My rule of thumb: if my source file is in a certain format, that is my output settings. That is why i dont bother wasting money on frivolous audiophoolery junk like 192/24 bit stuff. I dont have any sacd, i just use 16/44.1. (refer to the xiph.org article about high res formats, plus i cant find any sacd that i actually enjoy listening to. just stuffy classical and jazz music. blech).
Hmm, are you suggesting that there might be no mp3 decoding issue on the X3? Just asking, because you acknowledged my
earlier bug report and announced that Fiio would fix it within the next two firmware versions (which, btw, they didn't). Just for the record, that's not a single issue with just one mp3 file, I have a whole bunch of mp3 tracks that exhibit audibly more background noise with the X3 than with my other DAPs.
Don't get me wrong, it's not my intention to bitch and I'll gladly grant Fiio all the time they need for a fix. I'd just like to have put beyond dispute that there's definitely an issue with mp3 decoding on the X3.
He is not suggesting there is no decoding issue. He is saying that RMAA is a terrible and amateur level test. It can be used by high school and college students without a problem just to do some simple testing but apart from that it leaves too many unknowns and variables unaccounted for to be taken seriously in any true engineering specification. The nwavguy (come back, guy) article referenced above has plenty of useful information about the specifics, but it is so packed with information (as usual) that it is hard to get through unless you already know what you're looking at.
I think Fiio's next hurdle will be this UI issue on the firmware (which will be kind of backburner because of the dev time it takes) along with some high priority sound issues, formats, and things like that. This is a newer issue that will need planning to tackle, and while I would expect Fiio to tackle the issue, I dont expect it in the next firmware update. maybe the one after.