▲

[Ian @ un4seen]

Here's an update for you to try, with the aforementioned support for "file://" URLs in BASS_StreamCreateURL, allowing local network files to be handled like internet files without resorting to BASS_StreamCreateFileUser.

    www.un4seen.com/stuff/bass.zip

You should just need to put "file://" in front of your existing paths. For example:

Code SelectExpand

stream = BASS_StreamCreateURL("file://127.0.0.1/...", 0, flags, null, null);

If you still have the problem when doing that, we can then try a debug version to get more info. In that case, also confirm where you're making the BASS_StreamCreateFile/URL calls. If they're in mixtime SYNCPROCs then that could explain stalling, as the host channel/mixer can't continue processing until the SYNCPROC returns.

[Chris Oakley]

Thanks Ian, but we've been running some more tests today and we thought targeting the files direct via C:\ instead of via \\127.0.0.1 might reveal something, but it didn't. We still had a stall playing the file direct from the local disk.

We've only just recently got this information, but it clearly shows it's nothing to do with the network.

I believe the debug version may be the only way to go.

[Ian @ un4seen]

I think it was always unlikely to be a network issue, given that your network share is actually on the same PC (127.0.0.1). But it is possible for local drives to be slow at times. What type of drive is it in this case?

The point of trying BASS_StreamCreateFileUser or BASS_StreamCreateURL is to see if the "buffered" file system prevents or at least reduces the problem. When using the "buffered" file system, the decoder doesn't wait for file reads - it just decodes whatever is currently available. So a slow file read won't delay the mixer, and only the decoder will stall instead of the entire mix.

[Chris Oakley]

How do I get it to load a file like C:\Audio\file.mp3?

[Ian @ un4seen]

The URL of that file would be this: file:///C:/Audio/file.mp3

So basically a "file:///" prefix. More info can be found here: https://en.wikipedia.org/wiki/File_URI_scheme

[Chris Oakley]

Okay so while it works, as in will load the files, it's not a direct replacement and it's having trouble with fast segues, so we can't deploy this to the clients machine.

Could we please have a debug DLL?

[Ian @ un4seen]

OK. I've sent a debug BASS version to your registered email address, to get more info on what's happening.

[Chris Oakley]

Thanks Ian, but nothing has come through. I did check the junk. When did you send it?

Also, out of interest, the file:// method - does that add any delay when opening and playing local files?

[Chris Oakley]

It's okay, it came through.

Again though re. the file:// method - does that add any delay when opening and playing local files?

[Ian @ un4seen]

Good to hear the email got through.

Opening local files with BASS_StreamCreateURL shouldn't take any longer than BASS_StreamCreateFile. If you call BASS_ChannelSetPosition immediately afterwards, before BASS has downloaded/buffered the required file position, then that may delay/stall playback until the download reaches the position. Or the call may fail (BASS_ERROR_POSITION), depending on the file format/decoder. But the download would usually be very quick when the file is local.

[Chris Oakley]

Just an updated for anyone else who might be following this thread with a similar problem.

We discovered that increasing the thread count using the BASS_CONFIG_UPDATETHREADS config option stopped the problem in general, but one of the machines was being stubborn.

We did a disk check with an app that stress tests the disk and found it was broken on the write with 1% of expected performance.

We then tried Ian's suggestion of using a modified BASS library which supported the playing of files but via the BASS_StreamCreateURL call. This then allowed files to play without issue when we stress tested the disk.

So the culprit here is a poor performing disk. It's not the first thing you would go to - everyone likes to blame the software.

Big thanks to Ian for all his input.