Im getting a problem in that it does as i said in the title, suddenly just speeds up for a couple of seconds, then it returns to normal for around a minute. its as if it’s trying to load or something.
I haven’t changed any buffer settings, the only thing i did try was to do with file management and loading into RAM, something that i have since disabled via the configuration. However i still get this problem, i dont believe that i had this problem though before i experimented with loading into RAM (of which i had plenty any way).
Could this be a possible case of, like i had before with the cartwall, it not actually deleting the config.ini?
I did flick through it briefly and couldn’t seem to find an appropriate line - any thoughts?
As an additional note, i just checked the configuration and the “enable file management” box was ticked when it loaded up, i had previously unticked it.
To make sure i hadn’t made a mistake i tested and if you untick the box, save and then re-open the config it re-appears ticked!
Ah, just as another point!! Just checked the config.ini
Not sure whether they are all like this or whether it is just something i have done accidentaly but there is a spelling typo in the “ENABLED” is “ENABLDE”
As soon as i typed it properly the config then displayed how it should do. Will try it out now to see if i still end up with songs speeding up!
I don’t think it’s related to the config. I also don’t think the mistake is inside mAirList. Because once the file is started, complete control is given to BASS. Unless you use file management, there is no interaction with mAirList code until the file stops or reaches a cue point (in which case BASS would send a notification to mAirList).
Does this happen with MP3 files? If so, you should use the ordinary BASS.DLL from www.un4seen.com instead of the “mp3-free” one that comes with mAirList. The latter uses the Windows built-in/installed MP3 codec which might cause the problem.
Another thing to cosider is driver issues. From what I know, BASS first establishes a link to the driver, sets the audio parameters (sample rate, etc.) and then feeds the data into the driver as fast as it accepts it (which is usually at the speed determined by the parameters). If the driver happens to change the parameters, e.g. the sample rate, in the middle of playback, data would be fed into too fast (e.g. 44.1kHz samples transmitted at 48kHz). Some soundcards have buggy drivers which do so when you load another file with a different sample rate. Sometimes, this can be cured by enabling BASS_SAMPLE_SOFTWARE or disabling BASS_SAMPLE_FLOAT.
If you get you right, this does only happen with v3.0 and not with v2.2. This could be because they use different versions of BASS (2.3 vs. 2.4) which might interact differently with the driver or codec.
Oh, and you could take a look into the BASS forum at www.un4seen.com. Perhaps someone else has reported this kind of problem. I’m a little busy at the moment, so I cannot look myself.