I exchanged the old cartwall interface box with the new one and this resulted in shocky playback.
Changed bass settings without really getting to a result.
So I manually checked remote.ini and I saw that there was still a [Remote1] defined pointing to the old “6-button jaystick w/POV”
After deletion and renamimg [Remote2] to [Remote1] the system performance restored to normal.
Maybe Torben you have an explanation to this. Normally the old joystick should have been removed from the .ini
In config I was not able to select it anymore as it was no longer connected to the soundcard.
I know it doesn’t explain the odd performance in mAirList as such, but Windows is notorious for deleting game controller devices when they are unplugged (!). If you later plug in the same device again, Windows sets it up all over again from scratch.
In practice, this means that programs which use those devices (like mAirList) may ‘see’ the device as a new device and NOT the same device which existed previously. This is because Windows (internally) gives the device a new ID.
It’s a complete pain in the neck, but unfortunately this is a Windows issue and there’s nothing that Torben or any other software developer can do about it.
But as I said above, that doesn’t precisely explain why mAirList cartwall playback goes ‘shocky’ when a game controller device ‘disappears’ from the PC.
PS: Though I love the term, what exactly do you mean by ‘shocky?’ Does it mean the playout ‘stutters,’ or starts late, or something else? I’m just curious and interested!
By using the term ‘shocky’ I was referring to the one used in previous threads ;D Of course stuttering is correct.
Shocky might be related to shock as that. Playback is the same like when you give the CD player a hit/shock.
Nevertheless, I do not believe in Windows being involved here. I can unplug/replug the gamepad a thousend times. Windows won’t install it from scratch UNLESS you plug it into another USB-port.
The problem here was related to a gamepad emulation box that was plugged to the gameport of a soundcard. So no way for windows to recognize it. It has to be installed/setup manually.
I’d rather suspect a problem within mAirList that keeps on polling the Inputs of a device that no longer exists. Resulting in maybe timeouts and therefore creating gaps in playback due to low CPU performance. (Our playout PC is also not latest and greatest stuff)
Keep in mind that all USB devices have to be polled in order to read their input states. I’m not aware on how this was done on old gamepads connecting via the gameport of a soundcard, but I assume it is similar.
Anyhow, removing the item from the config restored to normal behaviour. The point is that the device does not get removed from the config (remote.ini) When I start the mAirList-configpanel the device does not get listed either (when unplugged), so why does it remains in the configfile when saved?
Okay: I think the issue here is that mAirList cannot ‘know’ whether or not a ‘missing’ device is temporarily or permanently ‘missing.’
Imagine this: your device is ‘broken’ or temporarily has been removed for servicing. Would you want all your (possibly quite complex) Remote setup for your device to be deleted in those circumstances? Especially if the device plug has simply fallen out of the PC?
Still, I think we need Torben’s advice and opinion on this one.
Normally, if the joystick is missing, mAirList should just write a warning to the system log at startup and ignore the joystick. But perhaps there’s a problem with the part of the code, I haven’t tried in a while
That’s why I raised this topic.
If I remember well, the remote.ini got “cleared”-off with all devices not connected at “save”-time.
So now we seem to keep the config (which is not wrong)
Again, this is a more complex topic. I now know how to handle it.
As for the rest on how it might be treated in future, to be honest, I don’t care! This goes by far too deep into OS related things I’m not aware about.
All I want to say is that (Torben might confirm this) for a “missing” device, that the poll rate is decreased after x unsucessfull communication attempts. Not to give up, but to reduce communication overhead, leading to drop-outs on the playout front-end.
And again, I only suspect such a scenario. Torben should know how this is treated.
Looking at the code again, I’d say that I leave all error processing to the 3rd-party library I’m using for accessing joysticks - obviously, it doesn’t handle the error condition as smoothly as it should.
