skipping on start

I’ve tried disabling and enabled BASS options. I’ve tried increasing and decreasing audio buffer times however I keep getting this little tiny quick skips on the start of audio. Not all the time, but most of the time.

On the same sound card, I can open the file in windows media player, with the same response time but not skipping on start what so ever.

I’m only use tightly edited linear PCM wave files on a P4 machine. mAirList otherwise runs great. It’s just this anoying skip it does with audio right at the start… like 20ms of audio if that.

I’m running Windows 2000 Pro, SP4, Ensoniq Audio PCI card, I have another sound card but it stutters with anything and is a bad card. The Audio PCI works stutter less with media player, winamp etc…

I’ve got directx 9.0c loaded and the default media player 6.4.09.1125. I never upgrade media player because I don’t like it, and I only use wave files so I don’t worry about codecs etc…

Gavin.

edit: I’ve tried setting software mixing instead of hardware, however it introduces a huge delay, well as in 300-400ms delay starting wave files that otherwise start instantly in other applications. This solves the jitter but the delay is annoying. That’s why I gave up on codecs and use wave files.

Gavin, have you tried enabling the option which loads the entire file into RAM? That would be my first suggestion, and don’t forget to change the figure beside the option so that the file will load entirely into RAM.

You didn’t say how much free system RAM you typically have in your Win2K machine after mAirList is loaded, but I am assuming you do have enough available to be able to load all of a typical WAV file of a music track into RAM? Remember also that this figure needs to be multiplied by number of players (i.e. number of players × typical music track size, should ideally be less than the amount of free system RAM).

I agree that software mixing is to be avoided if at all possible ;).

You don’t say whether this problem affects short tracks like jingles: does it? Also, does the stutter happen in Cartwall players, main playlists’ players, or both?

Hope this helps, or at least gives you some more ideas or clues!

BFN
CAD

Have you tried to replace the BASS.DLL, as suggested in this thread?

Thanks for the input guys.

Well, I only have 256MB of ram, 400MHz RAMBUS stuff. mAirList chugs along nicely at about 120MB mem usage all up with windows. I tried to load the whole audio to ram, but it seems to go to the hard drive as a swap file rather than the available system ram come down. I don’t really see why it would help as the start is still instantaneous to me on wave files, appart from the 10ms jitter or whatever its exact amount is now and then when starting. I realise it’s quicker starting from ram, but it’s not a hard drive problem, or it would happen with any other player.

I just replaced the bass.dll with the latest. Still happens. It doesn’t appear to happen when you load mAirList for the first time, and start the song the first time. It’s like there’s 5-10ms of audio left in a buffer somewhere next time it goes to start the file from stop/idle. It doesn’t always happen, but it’s still enough to be annoying.

More about my setup. It’s a P4 1.5GHz, 256MB of 400MHz RAM which I never use more than 160MB unless audio editing. It’s an Intel board/processor/rambus etc… Simple 32MB video card. A couple of western digital drives, the audio drive being on the second IDE by its self (D:). DMA all ultra mode 5 etc… the audio drive is partitioned in large allocation size for audio files, no indexing (service disabled), fixed swap file size on C: of 768MB (to avoid delays with dynamic swap file sizes) which I never used more than 160MB physical ram unless audio editing etc…

This machine does it’s job just fine, doesn’t run out of RAM, doesn’t hesitate when playing back audio, especially as I’m using uncompressed linear PCM files which the sound card handles without the need for CPU decoding etc…

Audition runs on this PC fine for editing and playback of multiple tracks at once without the jitter on start.

The CPU hits maybe 30% when I start 1-3 players in mAirList. About 5% if I start it in media player or just the cart player in mAirList.

Since I use wave files, everything’s in metadata files as far as additional information goes.

I use short file names (7 characters) so less long file name look up conversions etc… all those sort of tweaks you could think of.

I just tried playing a quiet -70dB tone in a cart player, while starting the song I know it jitters at the start quite often on in another cart player. Perfect, no jitter on start and re-starting it over and over. Yet, as soon as I use the players, there’s a 50/50 chance almost it’ll jitter a split second of audio and a real quick split second before it starts. Almost like the tinest error on a scratched CD.

So why would it do this in the players with hardware mixing, yet it’s fine in the cart player with other audio running at the same time etc…?

I don’t have any onbeforeplayerstart scripts loaded at the moment either.

It’s just a little anoying. Perhaps everyone else uses mp3’s with the inherent 30-40ms codec delay and my files are to tightly edited for mAirList? Usually there’s 5-15ms on the start of the audio files and they all start at infinity, not part way through a sine wave etc…

I could always email a 2 seconds of the wave file for someone else to load 10 times or so in a playlist and stop/start it in the players to check on their mAirList?

Gav.

Seems like it’s really the BASS.DLL not flushing a buffer or something. I will investiage it. Send me a copy of your mAirList.ini for reference please.

Thanks Torben.

I’ve emailed the ini file and I hope you don’t mind, about 350KB of wave file. This is the file that causes the slight jitter when re-started from stop after beign played. A lot of other songs it doesn’t do it on, so I’m guessing that’s because there’s a few more milliseconds of audio silence on others so you don’t hear that little jitter being caught in a buffer anywhere.

There are others that do it to though. At first I thought, cheap sound card, bad drivers, or something to do with the sound card not being initialised when ready, but nope, doesn’t do it in the cart players or any other playback software.

Thanks heaps for looking at it for me.

Gavin.

edit: I’m off to bed, late night, early start. Will wake in anticipation in the morning :o)

Thanks for the files, the WAV sample might be helpful.

At first glance, I noticed that you use the “default speakers” settings on all soundcards. Try to select a specific speaker pair (1/2) instead. I have experienced similar problems when mixing the “default speakers” and specific speaker settings on the same soundcard - maybe it’s related.

I will investigate the problem either tonight or on Sunday (I’m turning 30 tomorrow, no time to work mAirList then ;).

Have a good night “down there”!

Torben

If I select 1/2 front (it’s only a stereo output card not surround) it just doesn’t work.

It’ll work on my 5.1 card but the 5.1 card has clicks and pops when it initializes so unfortunately unsuitable for testing this problem with. I only use the 5.1 for PFL.

Ah 30, you’re just under a year ahead of me. That would also make you 30 already by my time zone :o) Congrats! Hope you have a good day/night.

Gavin.

Well, let the 51-year-old here suggest one or two more things to you bright, thrusting youngsters :wink:

Gavin: I would seriously suggest adding some system RAM to your PC if at all possible, no matter how well it works right now with Audition or anything else. I wouldn’t use a PC with as little as 256MB for any audio purposes, especially if you are using WAV files. My main PC here is similar spec to yours but has 1GB of system RAM (the RAM cost me about £50 here in the UK, dunno about NZ prices). If you can even ‘borrow’ some RAM temporarily, you can at least determine whether it is part/all of the problem, yes?

Secondly, do you have absolutely the latest Windows drivers for your audio and video cards? If either of them are on the motherboard, then still look for and install the latest drivers for the chipsets: this did make a difference for me here. Ditto obtain the latest Windows drivers for your CD drives (if any?): again, this made a difference for me, even though the CD drives aren’t used in my PC except for ripping.

Sorry I can’t immediately think of anything else to suggest.

BFN
CAD

Hi CAD.

Thanks for the tips. It’s been a little while since I updated the video drivers (6 months or something ago). So I’ll go do that once I’ve finished typing this.

I have no on-board video or sound. I use an older 32MB AGP TNT2 RIVA card and usually keep up to date with the latest nvidia all on one drivers. I do have the latest drivers for the sound cards (one’s an crystal media which clicks and pops, the other an Ensoniq Audio PCI, before Creative took them over so I believe it still plays 44.1KHz files without resampling to 48KHz clocks like in the Creative cards).

The motherboard chipset drivers are also up to date. I always keep the chipset ones as new as possible since Windows 2000 always has an unknown devices in my experience without chipset drivers.

I was thinking if it was a driver issues, I’d kind of expect the same problems with any other audio application, which all run fine and have done for 3-4 years.

Yes I agree on the ram comment aswell, 256MB is on the low side these days. Hey, I still remember 128MB with an Antex MP2 sound card was more than ample for automation :o) This was in the days of 500MHz PIII’s and AMD 850MH’z athlons! Or even 233MHz Pentiums if you were only use wave files. This of course was before everything went software mixing and decoding, and operating systems became bloated!

Unfortunately though, to throw another 256MB of rambus in this machine is about $250NZ second hand ($100US). The stuff is hard to come by now. I noticed DDR has only just caught back up after 4 years with the bus speed of the original 400MHz intel stuff when they first brought the P4 out.

Gavin.

Gavin,

providing me the wav file was a good idea. I was able to reproduce the problem and track it down. Here is what’s happening:

Each playlist item keeps a list of “client objects” which receive notifies whenever the item changes. For example, one of the client objects is the player the item is currently loaded into. When you change e.g. the cue in value from the Extra PFL dialog, the item will notify the player that something has changed, and the player will update itself accordingly, in particular, when in “idle/loaded” state, it will set the current position of the (paused) BASS.DLL stream to the new cue in value so that the file will play from that position once you start the player.

Moreover, when starting an item, the player will first send the Play command to BASS.DLL and then enter the current date and time into the sttReal-StartTime field of the playlist item, which is later used for the backtiming display by the playlist object. Entering that value triggers the above mentioned notification loop, while the player is not yet switched into “playing” state but still in “loaded” state. Just like any other client object, the player itself will then receive the notification, consider that it’s still in “loaded” state, and set the BASS.DLL stream position back to cue in, that is, to the beginning of the file. Go figure.

The solution is to include extra information into the notification about which part of the item data has changed. If it’s only the backtiming information, the player will not manipulate any stream positions anymore.

I will provide an update later this day. I hope it will solve the similar errors reported in that other thread.

Torben

Just downloaded 2.1.31.

My email seems a little temperamental, sometimes I get forum reply notifications sometimes not. Might be my ISP’s spam filter.

I had to re-read your reply a few times to make it sink in. I now understand what exactly you were saying though.

The 30-40ms of MP3 or lossless audio encoding was obviously enough to make this not noticeable to the masses using mp3 etc… as it was only looping silence basically.

Glad I was of some help, and now glitch free :o)

Gavin.

*** THIS ERROR IS NOW BACK AS OF 2.1.35 ***

I doubt that it is exactly the same error, because the faulty logic behind it was removed for good back then.

Perhaps there is a different reason for the skipping you encounter?

Perhaps!

Either way - I’m getting skipping again.

Ok, let’s wait and see what the others say.

I don’t face any problems like that! :wink: