[quote=“Torben, post:5, topic:6526”]I have a very vague idea of what’s happening here.
When a file has ended or the Fade Out point is reached, BASS will send a notification to mAirList, which is then passed to the mixdown engine which in turn will start a new file. That notification is passed asynchronously, that is, using the internal messaging system inside mAirList. When the CPU load is rather high (remember that you’re encoding to MP3 at that time), the notification might be delayed a few milliseconds. You won’t really notice that in realtime automated playback (or container playback, which uses the same mechanisms as mixdown does), but during mixdown, which is performed at say 8x speed, the delay increases by factor 8 as well, which might result in the gaps you’re experiencing.
This seems to be a major disadvantage of the current design of the mixdown system. It’s basically a virtual soundcard wired to the encoder, and then a container item is played back into that soundcard - but using the same messaging mechanisms used for realtime playback.
The only solution I could think of is a complete rewrite of the mixdown system. That’s not too difficult, but it will take some time.[/quote]
Thanks. However, it’s the WAV files that seem to experience the issue more, MP3 mixdowns seem to be correlated more to the playout. Let me do a few more shows this way and see what happens before you get bogged down in a mixdown rewrite. It’s possible the WAV export may use more CPU.
Testing, LAME (320k MP3) export,LAME.EXE sits around 50% with mAirlist at 7-10%
WAV export, mAirlist runs around 25-30%.
So LAME does the grunt work I guess on the export, the compression.
This isn’t a showstopper, so I would rather see more work on 3.1 or Voicetracking than fix something that maybe just a few use (just my humble opinion!)
Much appreciated.