Sometimes when starting a song, the first second or two will play over and over again repeatedly - almost as if mAirList has incorrectly guessed how long it should be, has said that it is longer than it actually is, and is doing this to compensate. It sounds dreadful on-air and happens often enough to warrant mentioning it here.
I dunno - it could be something I’m doing this side - but mAirList and our news downloader program are usually the only things loaded on the computer.
Thanks - and do keep up the good work, this is absolutely excellent
When a small portion of a song is played repeatedly, this usually means that the BASS.DLL buffer has run empty and couldn’t be filled in time. BASS then repeats the current contents of the buffer until the next data has arrived from disk.
It’s almost impossible to guess the reason without further observation.
Do you use BASS.DLL hardware mixing? If so, try to adjust the BASS.DLL buffer and update period settings. (Larger buffer, smaller update period.)
I have no idea about BASS.DLL - And haven’t touched the config of it where thats concerned, so it’s pretty safe to say that it’s on the default settings.
This happens both at home and in the studio, so I’m guessing its something in common with the config of those machines that’s causing it.
Switch on BASS_MP3_SETPOS on the BASS.DLL config page. If the problem is related to wrong guessing of the duration (which I doubt, but who knows), this flag should cure it. It makes BASS scan all of the file when opening it. This is extremely useful when you have VBR MP3s.
If you have a multi-channel sound card, make sure that each player output is set to a specific speaker pair. Do not use the “default speakers” setting, but select “front (1/2)” instead.
By the way, I guess the issue occurs randomly, and is not reproducable with any specific files, is it?
Increasing the buffer size and reducing the duration seems to have worked - but as you say, it’s not any specific files, it’s totally random.
I’ll leave mAirList running some playlists, along with news events etc for a while - and let you know if anything happens. All OK at the moment though.
I had this problem, too - On the studio machine (pro M-Audio soundcard). It was usually only 1 Player (of 3) that did it, but never able to replicate it. I’ll have a tinker with the DLL settings and see what I get.
The audio effect that I’d hear would be when starting a Player, it’d “spew out” the first .5s of the audio, then re-start and continue… This actually happened in DPS (another playout app), but was attributed to poor M-Audio drivers. Interesting to see/hear it happening on other machines…
I’ve just recreated the problem again. I think I know what it is.
Here was the sequence:
JAMES BLUNT - GOODBYE MY LOVER
BREAK BUMPER (6sec)
SHEILAS WHEELS AD (30sec)
James Blunt had a very slow ending, so the break bumper kicked in with 15 secs left on the song. Then the ad started playing - and the song was still fading out.
So mAirList has three things playing out at the same time, and is wrestling with shuffling the playlist, etc.
So mAirList has three things playing out at the same time, and is wrestling with shuffling the playlist, etc.
This is one of several reasons that I use [b]two[/b] playlists: a two-player 'main' one for music, and a three-player 'mini' one for ads., promos, etc.
I know that this is an almost heretical suggestion to some people (!), but it really does work well. It’s surprisingly easy to automate a two-playlist setup if that’s how your station works (we’re live-assist most of the time), and you can use a totally separate Event List to load your ad breaks etc., which I find a big benefit. Also, if you want to run a ‘sequence’ of jingles etc., you have a (usually!) empty Playlist to put them into.
I think running two playlists would have to be done on two monitors in our situation - because some of our presenters aren’t gifted with amazing eyesight, and insist that we make it as easy as possible for them. We don’t, unfortunately, have the budget for the graphics card or monitor required at the moment - we’ve got something like £20 in the bank, as I went impulse buying yesterday and decided we needed some more voiceovers!
mAirList violently crashed this morning - at the start of an ad break.
First of all, you should not use the development release in a production environment unless you know what you’re doing. As mentioned earlier, it might be full of bugs
Thanks for the files. I have already downloaded them, but I won’t be able to examine the situation until tonight when I’m back home.
I’m not using it in a production environment this week, I’ve got a week off
I’ve been running a station off this comp since yday, to bug test and customise it for studio use - I must say, the more I use it, the more I love it!
It took me the best of 10 minutes, alongside station playlist creator, to set the station up for the next month, with ad breaks, timed news events and even different news bulletins depending on if the hour is odd or even! Aren’t I clever?
set the station up for the next month, with ad breaks, timed news events and even different news bulletins depending on if the hour is odd or even! Aren't I clever?
Good stuff... If you get time, please add any info to the Wiki pages - It may help others.
Ant, I’m sorry to say that I cannot reproduce the error with the files you provided me. There must be other criteria that have an effect on that behavior: System load, hardware configuration, …
mAirList 2.1.16 will include an optimization which may have positive influence on this issue. At the moment, each file is internally opened twice when loaded into a player: once for ordinary playback, once for PFL - even if it will never be PFLed. As of mAirList 2.1.16, the PFL “source” will only be opened when you PFL the item for the first time. In an automated environment where no item is PFLed ever, this decreases the BASS file open/close operations by 50%.
Your mAirList.ini file had the standard BASS buffer and update period settings (500/100) set. Which other settings did you try?
I’ve had a play with the BASS DLL buffer settings, and I’m convinced that Player2 (of 3) is the problem… I seem to get the little “glitch” almost always on the second Player.
- If you have a multi-channel sound card, make sure that each player output is set to a specific speaker pair. Do not use the "default speakers" setting, but select "front (1/2)" instead.
I have just found that there is another BASS flag - BASS_SAMPLE_SOFTWARE - which might cure this kind of problem. I will add a corresponding option into mAirList 2.1.17.
- If you have a multi-channel sound card, make sure that each player output is set to a specific speaker pair. Do not use the "default speakers" setting, but select "front (1/2)" instead.
On my M-Audio Delta410 card, I tried this - the dropdown box offers “default” or “1/2 Front”, so I tried Front and when you load items into the Player, you get an error box and you have to close mAirList via TaskMan.