06-Jan-2015, 12:53
(This post was last modified: 06-Jan-2015, 12:54 by Rufus McDufus.)
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.
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.
