(06-Jan-2015, 02:05)AlexS Wrote: [ -> ]But see what matters here is whether you can MANUALLY induce the problem. You're probably tired of testing by now, but if you could manually wake up the monitor from sleep, and that yielded white noise, then there is a direct relationship between the screen waking and the noise. On the hand, if this does not create the problem, it probably means there is a 3rd party process both waking the screen and causing the noise.
I understand the opposite (the monitor going to sleep) did not cause problems. Is that correct?
I get short dropouts (about 1 second) by waking the screen, probably about 25% of the times I wake the screen.
I get longer dropouts - 5-10 seconds when the screen power option turns the display off, but probably only about 5-10% of the time. The rest of the time I got similar-length dropouts after short period of time, usually within 1 minute of the screen turning off.
You mentioned process priority a bit earlier - that could well be a very large factor in this. Why do the likes of minimserver etc. perform faultlessly yet AIR doesn't? They're shifting similar amounts of data close to real time so there's no particular reason why AIR should suffer so badly.
The PC I'm testing in is fairly high spec by the way - well for one that's 3 years old! Intel i7 3.40GHz (moderately overclocked from that) and 16G of memory. Local disk is SSD.
When I was using AIR 2.1.2 & 2.1.3 I tended to get a short stutter when the screensaver kicked in, which looks very similar to Rufus’ recent observations. The 2.1.3 beta1 version is in fact worse in this respect, in that rather than a stutter, there is a 90% tendency to go to full white noise. With the screensaver disabled, I find that 2.1.3 beta1 can run for hours without issue, whereas 2.1.2 & 2.1.3 would tend to go randomly to white noise, after maybe 1hour 30 minutes or so. What does all this mean? To be honest, I’m not sure!
I can reproduce dropouts (but again no white noise, grr!) with iTunes into AIR and playing music from the local SSD (so no NAS or network dependency on it in the chain). Again, with AIR 2.1.3 these dropouts only appear to occur after the power option 'display turn off' has turned off.
I'm trying with that power option set to 'Never'. I think Confused you're saying that you get dropouts, but far less often, with this option set to 'Never' right?
I'm starting to think the way AIR is dealing with interrupts is flakey, perhaps with interrupt masking. Perhaps when the display driver sets a 'power off' state then it differs in the way interrupts are sent, or the effect of interrupts can have a greater effect on other running programs, or whatever... I don't know too much about this as you can probably tell but I can see interrupt masking can have an effect, but the dropouts are a lot longer than the likely dropout from an interrupt so I can only guess AIR takes a long time to recover - perhaps it has to fill its buffer completely on interrupt before it can resume? Pure guess again and pretty much impossible to confirm without access to source code/debugging environment.
I've done a bit of googling and see with other software that require near real-time operation, one of the recommendations is to disable display power-off in power options - so someone's been here before with similar products.
Well that's a first Rufus! .... signs of frustration at not being able to get white noise, grr!
Anyway, I can indeed confirm that with the sreensaver disabled in the power options, then drop outs have more or less dropped to zero.
I'm getting white noise now with iTunes/music on local disk/AIR 2.1.3. It's horrible isn't it? Curiously I got a couple of dropouts with this playback method earlier but now I seem to be getting white noise.
I turned off display power-off and got 1 sec white noise after about half an hour, and a similar burst a few minutes later. I then got a minute-long burst that varied in volume and I had to turn it all off.
Wondering if the difference is that I get white noise with iTunes/AIR not in Bit Perfect mode, but silent dropouts with JRiver/AIR in Bit Perfect mode? I'm pretty sure I got a couple of silent dropouts earlier with iTunes though which could blow that theory.
Yes - my absolute worst case for getting white noise has always been to use iTunes with the PC soundcard GUI set to 24/192. As it happens, this also offers just about the worst sound quality I can achieve between PC and the Devialet, so a bad option all ‘round. (For the record, I find JRiver WASAPI best, but iTunes with the PC sound card setings at 16/44.1 and AIR GUI set to 16/44.1 is not far behind with CD quality material)
The other thing about the white noise issue is that it has always been slightly random in when it occurs and how it manifests itself, making it a very slippery customer to pin down.
(06-Jan-2015, 13:49)Rufus McDufus Wrote: [ -> ]I'm getting white noise now with iTunes/music on local disk/AIR 2.1.3.
Rufus, what is your AIR "preferred format" setting, when you test with iTunes? 24/192? If you can consistently recreate the white noise with this setup, you may want to try the new BETA version of AIR, to see if it improves things for you.
@
Confused, if the BETA version made playback more sensitive to the screesaver's state changes, it hardly sounds an improvement to me. Have you reported this back to Devialet?
Alex - Yes! I have sent many detailed reports to Devialet with respect to my findings with AIR 2.1.3 beta1, including the various screensaver issues. Devialet advise me they are working very hard on a solution.
Yes, I have been using AIR set to 24/192. Interested if it sounds better at lower resolutions as I've never really liked iTunes/AIR either but naturally being a bloke the first thing I did is set AIR to the highest resolution as it's got to be better, right?
I find that if using iTunes on a PC, AIR sounds best with both the PC soundcard and AIR GUI settings at 16/44.1. (assuming you are listening to 16/44.1 material) If the PC soundcard settings are at 24/192 there is a noticable drop in sound quality, I'm guessing this is because the PC's own software is performing upsampling duties.