I expect you’ll tell me ‘you shouldn’t be doing that,’ Torben, but here goes.
I found recently that if you do this:
Open mAirList load some tracks, but don’t play anything.
With mAirList still open, open mAirListDB, play any track, then close mAirListDB.
Try to play a track in mAirList.
What happens is that although the Player state changes, no audio is played and the progress bars and player time display don’t update. Closing and re-opening mAirList corrects the problem.
No, it’s probably that your sound card (in the antique PC?) cannot be accessed by two applications at the same time. Most modern cards can. Mine works fine.
Would you regard a Terratec EWX 24/96 card as ‘modern’ or not?
That’s the card I have in that PC (admittedly there is also a motherboard audio ‘card’ but I don’t use that!).
I don’t seem to have that problem with other applications open simultaneously (like Media Player Classic and dbPowerAmp and mp3DirectCut, for example).
All I can say is that the two mAirList instances do not interact in any way. That is, they don’t talk to each other. So one instance cannot tell the other to suspend playback.
The effect you’re describing - player color changes but no playback, and time display and progress do not advance - means that the sound card is stuck and does not accept any data from the application. So there’s definitely something wrong with the card or its drivers after the other instance was started.
mAirList does enumerate all available WDM and ASIO devices, and initializes them for a short moment to retrieve the number of channels etc. - perhaps the EWX card doesn’t like that?
Do you have the same effect with mAirList and any 3rd-party application?
No problems with mAirList co-exsiting happily with other audio apps. so far: I’ll try a more thorough test when I get home from work tonight (after 2100 GMT).
[LATER]
OK, I’ve tried every app. I have which plays audio, and they all co-exist happily with a running copy of mAirList. The ONLY thing (haven’t tried mAirListTag yet) which stops playout is opening a copy of mAirListDB at the same time.
The MOMENT that mAirListDB opens, mAirList playout/progress bars stop dead and don’t recover until mAirList is stopped/started again. Also, it’s not possible to play anything in mAirListDB either. It’s like both instances are ‘fighting’ over the soundcard, and what happens is that both programs ‘lose’ the soundcard.
Is it possible that the soundcard driver is ‘seeing’ the same internal or Windows process name for both mAirList and mAirListDB? That seems like the sort of thing that might crash the soundcard driver access to both applications.
Sorry I can’t be of more help, and it may of course be some weird bug in the soundcard driver, but it’s definitely reproducible here. And all other audio apps., as I say, work very happily with mAirList (or with mAirListDB).
I don’t think that the sound driver looks at the process name. It’s rathet the initialization issue I mentioned. Does it happen with 2x mAirList or 2x mAirListDB as well?
I’m now wondering if it’s because I have the Config checkbox to NOT allow more than one instance of mAirList ticked? Will test that later: in a rush to get to work!
With Allow only one instance of mAirList at the same time CLEARED
two instances of mAirListDB:
Starting the second instance stops playing audio in the first instance.
BUT restarting the audio in instance #1 works thereafter,
AND audio can be played in both instances of mAirListDB.
mAirList and mAirListDB (mAirList started first):
Starting mAirListDB stops playing audio (and progress bars) in mAirList.
Progress bars in mAirList are also ‘frozen.’
Clicking FADEOUT on the running mAirList resets the Player/Cartwall Player and progress bar(s).
No Player/Cartwall Player will now PLAY, although ON AIR state is displayed
(again, FADEOUT will reset the Player/Cartwall Player, passing through FADE before resetting).
In mAirListDB, the preview Player and the PFL Player (in Properties) both fail
(do not start nor update).
BOTH programs need to be closed to clear the fault.
mAirListDB and mAirList (mAirListDB started first):
Starting mAirList stops (freezes) the playing mAirListDB preview Player.
No mAirList Player/Cartwall Player will now PLAY, although ON AIR state is displayed
(again, FADEOUT will reset the Player/Cartwall Player, passing through FADE before resetting).
In this test case, mAirList video performance is affected.
Video updates are slow and can briefly lock out other graphics updates for one or two seconds
(for example, window redraws when the window z-order changes).
In mAirListDB, the preview Player and PFL Player (in Properties) both fail
(do not start nor update).
Closing mAirList clears the fault in mAirListDB.
After mAirList is closed, the mAirListDB preview Player and PFL Player work normally.
two instances of mAirList:
Starting the second instance stops playing audio in the first instance.
No Player/Cartwall Player will now PLAY, although ON AIR state is displayed
(again, FADEOUT will reset the Player/Cartwall Player, passing through FADE before resetting).
In this test case, mAirList video performance is VERY BADLY affected,
Video updates are EXTREMELY slow and lock out other graphics updates for several seconds
(for example, window redraws when the window z-order changes).
The mAirList time-of-day clocks are also erratic.
Closing the second instance of mAirList alleviates this to an extent.
No Player/Cartwall Player in instance #1 will now PLAY, although ON AIR state is displayed
(again, FADEOUT will reset the Player/Cartwall Player, passing through FADE before resetting).
Starting any Player/Cartwall Player ‘freezes’ the mAirList time-of-day clocks for a few seconds.
I haven’t done any testing with Allow only one instance of mAirList at the same time TICKED.
