I’ve got an urgent problem. I’ve installed mAirlist 3.0.6 build 587 on a P4 - 2.66Ghz - 1GB RAM computer running Windows XP Professional with SP3.
The sound card in the machine is the M-Audio Delta 1010LT.
When I load jingles in the cartwall or songs in the playlist (it doesn’t matter which, as they both do the same) it takes a long time for mAirlist to scan the mp3 for auto cueing. Then, when everything is finally loaded, when I press the hotkeys to start them, nothing happens for at least 20 seconds, before the player starts playing. This happens with EVERY mp3, EVERY jingle and in ANY player…
Then when the file finally does start playing – after those 20 secs – it’s very shocky, jumpy. In other words, the file stops for a fraction of a second and then starts again dozens of times during 1 track.
Does anybody know why this is and more importantly, how to solve this?
I’ve marked this as very urgent, because I have to record a 3 hour show before Saturday.
Has this issue occured in earlier versions or only in v3.0.6?
Are the files located on your local hard disk or on a network server? Can you please try to switch off all file management options in the mAirList configuration?
[quote=“Torben, post:2, topic:6200”]Has this issue occured in earlier versions or only in v3.0.6?
Are the files located on your local hard disk or on a network server? Can you please try to switch off all file management options in the mAirList configuration?
Regarding the sound card, the Delta 1010 is known to be a little problematic. Please have a look at the following document and double-check your driver settings: http://m-pulse.m-audio.com/articles/february2003/optimization2.html[/quote]
This has only been tested on v3.0.6. I haven’t tried other versions of 3 and when I was using version 2, I didn’t have the 1010LT card yet.
I’ve tried both. The files were first approached over the network, but I also copied the files to the actual hard drive on the PC and tried to play them directly from there. Same result. Also switching off file management options in the config made not difference either.
I’ve been through the list of the link you gave and tried some applicable tips out, but again, to no avail.
So has any mAirList version worked before on that PC? That is, has that problem occured all of a sudden?
I’d guess that BASS.DLL has some problems accessing the files properly. Or it might be a codec problem (in which case it should only affect mp3 files but not wav or ogg).
Could you please try the following:
Download the latest version of BASS 2.4 from www.un4seen.com.
Check if mAirList 3 works with the bass.dll from that archive. (BASS 2.4 only works with mAirList 3; mAirList 2.2 uses an older version which can be obtained by replacing “24” by “23” in the BASS download link).
If it still doesn’t work, copy the file named “basstest.exe”, found in the “c\bin” folder of the BASS zip archive, into your mAirList 3 folder and check if it plays the files correctly. If it does, it’s a somewhat mysterious mAirList problem. If it doesn’t, it’s either a BASS, codec, or system/hardware problem.
On this PC no mAirlist has worked properly as it’s a replacement for an older machine which had less specs, which had exactly the same problem. However, on the old machine mAirlist 2.2.2 DID work – on different sound cards – but 3.0.6 with the M-Audio did not.
I’ve gone to www.un4seen.com and downloaded the latest zip for windows from their web site, which is bass 2.4.3.1 – the zip is called bass24.zip. However, there doesn’t seem to be a bin directory in that zip at all, despite it being listed in the .txt file that comes with it. I’ve tried downloading and looking in the zip on two different machines, both setup to display hidden files as well, but it just doesn’t seem to be there. I also lack all the other .dll’s, like bassasio.dll, which is in the mAirlist directory, but which I cannot upgrade from this zip as it doesn’t have a replacement.
I’ve overwritten the bass.dll with the new bass.dll, nothing more, but that didn’t work. And due to the lack of the other .dll’s and the bin directory in de zip, I’m not able to run the basstest.exe file. Do you have a zip of 2.4 WITH the missing dll’s and bin directory in? I would very much like to have that, so I can either solve the problem, or rule bass out as a cause of the problem.
Recent versions of the add-on DLLs (bassasio.dll etc.) can also be found on www.un4seen.com. But if you use plain WDM hardware mixing output without tempo and pitch support (check your settings in mAirListConfig), those DLLs are not used at all, so there’s no sense in trying that. It’s ok to upgrade only the main bass.dll (as long as you stay inside the v2.4 release) and leave the other add-on DLLs untouched.
The “bin” folder I referred to is contained in another folder called “C” inside the zip (the name refers to the programming language called “C” - not to be confused with your “C:” hard disk drive). So the file to look for is:
(place where you unzipped the archive) -> c -> bin -> basstest.exe
[quote=“Torben, post:8, topic:6200”]Recent versions of the add-on DLLs (bassasio.dll etc.) can also be found on www.un4seen.com. But if you use plain WDM hardware mixing output without tempo and pitch support (check your settings in mAirListConfig), those DLLs are not used at all, so there’s no sense in trying that. It’s ok to upgrade only the main bass.dll (as long as you stay inside the v2.4 release) and leave the other add-on DLLs untouched.
The “bin” folder I referred to is contained in another folder called “C” inside the zip (the name refers to the programming language called “C” - not to be confused with your “C:” hard disk drive). So the file to look for is:
(place where you unzipped the archive) -> c -> bin -> basstest.exe[/quote]
Found it. Boy that was well hidden. Anyway, I’ve ran basstest.exe in the mAirlist directory and tested ‘stream’ and ‘sample’. Both worked fine.
Another thing which comes into my mind, as far as I remember, there’s a setting in the M-Audio control panel named “sync” or so, which must be set to “independent”. I thought that was covered in the document I linked to, but obviously it isn’t.
I’ve tried ALL your suggestions at the same time. File management was already switched off. In the WDM output page only the “use floating point data” option was ticked, so I unchecked that one. Also I renamed my devices.ini file and you were indeed right about the M-Audio control panel. There was an option like that and it wasn’t set to “independent”, so I changed that too.
It is now working fine.
Obviously, as I renamed the devices.ini file, alle players go the one and the same fader on the mixer, as before they were split over three (Player A, Player B, Cartwall). Would I be able to rename the file back again, or would that cause the trouble all over again, do you think?
Right, a little late reply, as something unexpected and even more important came up – timing or what? – but I have reinstated the devices.ini file and I’ve ran a few tests. It had one little wobble in the first test, but after that everything seems to run smoothly now, so it does look like those last tips solved the issue.
Thank you so much for the help! I truly appreciate it.
You’re welcome. Glad to hear that it’s working fine now. In case there is any trouble, don’t hesitate to contact me. But not on Saturday please, because I’ll be on my sister’s wedding then
I’ve finally had another chance to test it and the wobble in the play has returned. However, a few tests revealed that the wobble doesn’t appear when running music files from the hd that mAirlist is on, but does happen when using files over the network. Which is strange as it’s all 100mbps networked… theoretically that should work fine, but it doesn’t. So I need to look into whether it is the network causing trouble, or whether it is something to do with mAirlist. I’m currently guessing the first one, but if anybody has any suggestions I’ll love to hear them.
In theory, due to the CSMA/CD algorithm used by Ethernet, there is no guarantee that a particular packet will reach the destination anyhow. (When two computers start sending at the same time, they will notice the collision, then wait for a random time until they try again, and if they happen to pick the exact same delay, they will conflict again, and so on.)
In practice, it’s a good idea to maintain and use a copy of your audio files on the local harddisk, no matter how fast your network is. There’s too many bottlenecks everywhere, the server and its harddisk and network adapter, the client and its network adapter, and the switch in between. If you’re using mAirListDB Pro, you can redirect a network storage to a local folder (currently only by editing the database.ini file, contact me for details).
The file management included in mAirList 3 can also make a local copy of a file from a network share when it’s loaded into a player (“cache network files” option). However, you will notice a small delay as the file is being copied. In a future version, the next few files from the playlist will be pre-buffered in advance, so the delay should not be noticable then.
However, a local copy is still first choice in my opinion. There are some very good tools which will keep your copy in sync with the server, e.g. DeltaCopy (based on the rsync algorithm).
I’ve seen the stangest things happening on networks… :
One thing that comes up my mind immediately is that your problem might be related to a network switch or the onboard network card that starts switching between 100mbps and 10mbps.
I was able to track this problem down several times with a network analyzer. Mostly involved were Broadcom cards and 3com switches.
The problem is due to tolerances that make a card transmitting with let’s say 99.something mbps and causing the other side to start auto-negotiation. Thus switch between 100mbps and 10mbps back and forth resulting in collisions and packet loss. That’s where the trouble starts…
Hmm, I doubt that you have an analyzer available, but just try to set one side to fix 100FD and leave the other side with auto-negotiation on.
