Topic: BASS_Encode_ServerInit delay

[Ian @ un4seen]

I'm not actually starting it playing. It's being added to a mixer which is a decode mixer so it starts as soon as it is attached if I'm not mistaken on how this works. This mixer is then added to another mixer which is outputting to the No Sound device and playing on that.

When playing through a mixer, there may be an additional delay based on how much data the mixer has buffered. For example, if the mixer has 500ms of buffered data then the new source won't be heard until after that. You can avoid that by disabling buffering via the BASS_ATTRIB_BUFFER option (on the mixer).

What values do you see if you check the stream's pre-buffered data with BASS_StreamGetFilePosition (BASS_FILEPOS_BUFFER) immediately after BASS_StreamCreateURL? It generally shouldn't exceed the BASS_Encode_ServerInit "burst" value.

I'm not making any adjustements with BASS_ATTRIB_FREQ at all.

In that case, perhaps there's some stalling or missed update cycles. What BASS.DLL version are you using? The 2.4.17 release version doesn't give the "No Sound" device much leeway for delayed update cycles and will start dropping them when more than 1 whole cycle late. A dedicated option to configure that will be in the next release, but in the meantime, the latest builds use the BASS_CONFIG_DEV_BUFFER option to determine the leeway.

   www.un4seen.com/stuff/bass.zip

[Chris Oakley]

You can avoid that by disabling buffering via the BASS_ATTRIB_BUFFER option (on the mixer).

Thanks. Yes I've got that set on all mixers.

What values do you see if you check the stream's pre-buffered data with BASS_StreamGetFilePosition (BASS_FILEPOS_BUFFER) immediately after BASS_StreamCreateURL?

I'll see what it says and report back.

What BASS.DLL version are you using?

We currently have 2.4.17.4 but I see the dll version in the download you linked to is 2.4.17.16 - should we give that a spin? If so so I need to set BASS_CONFIG_DEV_BUFFER?

[Ian @ un4seen]

No harm in trying the latest build, but 2.4.17.4 did already have the BASS_CONFIG_DEV_BUFFER support mentioned, so in either case you can try raising that via BASS_SetConfig before initializing the "No Sound" device to give it more leeway.

[Chris Oakley]

In the BASS.NET documentation it says:

This config option is only available on Linux, Android and Windows CE. The device's buffer is determined automatically on other platforms.

This suggests it would make no difference on Windows 10 and 11 which is the platform we develop for. Is this correct?

[Ian @ un4seen]

The BASS_CONFIG_DEV_BUFFER setting has no effect on Windows in the BASS 2.4.17 release version, but it is used (for the "No Sound" device only) in the updates.

[Chris Oakley]

So I've checked the default setting using this:

Code: [Select]

Dim bufLen As Integer = Bass.BASS_GetConfig(BASSConfig.BASS_CONFIG_DEV_BUFFER)
Debug.Print("BufLen " & bufLen.ToString)

It's telling me the value is 30 which I presume, from the documentation, means 30 milliseconds. If I was to raise it, what sort of value are we talking?

[Ian @ un4seen]

The setting is the maximum amount of time that the "No Sound" device is prepared to catch-up after any processing delays, ie. anything beyond that will be dropped. If you want to avoid any dropped update cycles then you can pretty much go as high as you like. I guess 1000 (1 second) should be plenty.

[Chris Oakley]

I've been going through the code and I found an area where the Mixer, which the virtual cable is plugged into, is Split and plugged into the Mixer which is outputting to the No Sound device. I do this with

Code: [Select]

Dim i As Integer = BassMix.BASS_Split_StreamCreate(_PlayerContainer.ContainerID, BASSFlag.BASS_STREAM_DECODE, Nothing)
I then saw the config option BASS_CONFIG_SPLIT_BUFFER which in the documentation says it's default buffer is 2000 ms. Could this be the problem? Could doing a

Code: [Select]

Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_SPLIT_BUFFER, 100)
Go some way to solving this puzzler?

[Ian @ un4seen]

Are there other splitters on the same mixer, and are you currently setting BASS_CONFIG_SPLIT_BUFFER to 100 or just thinking of doing so? If there are other splitters then a short splitter buffer could potentially mean that some of them miss some data, so you probably don't want that in this case. The only reason I see for using a short buffer is when low latency is more important than keeping all data.

[Chris Oakley]

Are there other splitters on the same mixer

Yes, due to the configurable routing approach we have, it's possible that there will be other splitters on the same mixer, but in the current setup where I'm seeing this, there isn't.

are you currently setting BASS_CONFIG_SPLIT_BUFFER to 100 or just thinking of doing so?

Just a thought from what I saw in the documentation.

[Ian @ un4seen]

If there are no other splitters then the BASS_CONFIG_SPLIT_BUFFER setting won't really have any effect, as a single splitter will always be getting fresh data from the source rather than depending on the splitter buffer.

[Chris Oakley]

Okay, good to know. I'll leave it as it. I don't like blindly just changing values as you end up with other issue that become impossible to trace.

I'm just running a test to see if it might be something to do with the No Sound mixer being encoded and casted. I've seen some really weird behaviour surrounding when this is in place. Even using the ENCODE_QUEUE flag. I've got the

Code: [Select]

_VirtualCableId = Bass.BASS_StreamCreateURL(_VirtualCableUrl, 0, BASSFlag.BASS_STREAM_DECODE, Nothing, IntPtr.Zero)
Open on three inputs and one of them is casting to a shoutcast stream. I want to see if the two that aren't stay in sync and the one casting goes out.

[Chris Oakley]

So I expected 2 of the 3 inputs to be in sync, as they were setup exactly the same, but even they went out of sync, and this is in the same application. I've tried setting up a physical input along side them too, each input taking the same record stream, and even they went out of sync. So I'm not sure right now that this is specifically a stream Url issue.

I'm just absolutely stumped at the moment. Something is really odd. Breaking it down in code this is what we have in the class, which we then instance, set up the same, we have the main No Sound mixer:

Code: [Select]

Bass.BASS_Init(0, 44100, BASSInit.BASS_DEVICE_DEFAULT, IntPtr.Zero)
_NodeID = BassMix.BASS_Mixer_StreamCreate(44100, 2, BASSFlag.BASS_DEFAULT Or BASSFlag.BASS_MIXER_NONSTOP)
Bass.BASS_ChannelSetAttribute(_NodeID, BASSAttribute.BASS_ATTRIB_BUFFER, 0F)

We have the mixer which will take a number of different sources like recording / input channels, streams etc:

Code: [Select]

_Mixer = BassMix.BASS_Mixer_StreamCreate(44100, 2, BASSFlag.BASS_STREAM_DECODE Or BASSFlag.BASS_MIXER_NONSTOP)
Bass.BASS_ChannelSetAttribute(_Mixer, BASSAttribute.BASS_ATTRIB_BUFFER, 0F)
_VUMeter = New DSP_PeakLevelMeter(_Mixer, 1) With {.CalcRMS = True,.UpdateTime = 0.08}
Note: The _VUMeter is the DSP we use to monitor the audio. It's from here you can visually see when each input has gone out, since the No Sound mixer doesn't provide any sound.

We have to split this _Mixer so we can plug it into the _NodeId mixer. This is done like this:

Code: [Select]

Dim i As Integer = BassMix.BASS_Split_StreamCreate(_Mixer, BASSFlag.BASS_STREAM_DECODE, Nothing)
Ret = BassMix.BASS_Mixer_StreamAddChannel(_NodeID, i, BASSFlag.BASS_DEFAULT)

Then to take a PCM stream which is at 44100 16bits we do this:

Code: [Select]

_VirtualCableId = Bass.BASS_StreamCreateURL(_VirtualCableUrl, 0, BASSFlag.BASS_STREAM_DECODE, Nothing, IntPtr.Zero)
BassMix.BASS_Mixer_StreamAddChannel(_Mixer, _VirtualCableId, BASSFlag.BASS_DEFAULT)

or if we want a recording channel we do this:

Code: [Select]

_RecordMonitorStream = Bass.BASS_RecordStart(44100, 2, BASSFlag.BASS_RECORD_PAUSE, Nothing, IntPtr.Zero)
BassMix.BASS_Mixer_StreamAddChannel(_Mixer, _RecordMonitorStream, BASSFlag.BASS_DEFAULT)
Bass.BASS_ChannelPlay(_RecordMonitorStream, False)

As you can see, noting too clever, nothing fancy. Can you see anything here that we're doing wrong. It seems like it should be pretty cut and dried.

[Ian @ un4seen]

So I expected 2 of the 3 inputs to be in sync, as they were setup exactly the same, but even they went out of sync, and this is in the same application. I've tried setting up a physical input along side them too, each input taking the same record stream, and even they went out of sync. So I'm not sure right now that this is specifically a stream Url issue.

If you aren't already, please try setting BASS_SYNC_STALL syncs on all mixer sources (including sub-mixers) via BASS_Mixer_ChannelSetSync and see if any get triggered. Also try setting an encoder on the final mixer (feeding the "No Sound" device) to write the mix to file, and then confirm that the file's content matches what you see in your VU displays, ie. you can hear the inputs similarly out of sync in it. Note the encoder should have the BASS_ENCODE_QUEUE flag set to avoid delaying the mixing.

To confirm whether the problem is specific to streaming URLs, you could also try local files instead, ie. BASS_StreamCreateFile instead of BASS_StreamCreateURL.

[Chris Oakley]

Before I do that, what would cause a stall? I would have thought the data through put would be constant.

[Ian @ un4seen]

With an internet stream (or live recording), it could be that the mixer briefly ran out of data to play from it.

[Chris Oakley]

I see. I'm just trying to get this straight in my mind.

So if the stream / recording ran out of buffer data, as the mixer is NON STOP, it would continue to feed silence?

If so I then assume when the stream / recording buffer was available again it would continue from where it stopped?

[Ian @ un4seen]

Yes, that is correct.

[Chris Oakley]

So what would be the best approach to this scenario? Let's assume the data did run out and the mixer is NON STOP because we don't want to lose the mixer if the data does run out? How could that be handled to bring things back into line?

[Ian @ un4seen]

You won't lose the mixer if its source(s) run out of data without BASS_MIXER_NONSTOP set. The mixer would just stall then instead of generating silence, and it'll resume when the source(s) have data available again.

[Chris Oakley]

Oh that's interesting. I could have sworn in the past in my projects, not having the NONSTOP caused the mixer to stop. So there would be no issues just taking the NONSTOP flag off then?

[Chris Oakley]

So I took the NONSTOP flag off the mixer which the stream / record channel is plugged into, but it's made no difference. It's this mixer that the peak level dsp is monitoring. Would removing the NONSTOP rule out the mixer stalling?

[Ian @ un4seen]

I think the NONSTOP flag is unlikely to make a difference to your out-of-sync issue. If one source stalls then it'll be out of sync with the other sources regardless of whether the mixer stalls (without NONSTOP) or generates silence (with NONSTOP). Did you try setting BASS_SYNC_STALL syncs on everything? If not, please try that (make sure you use BASS_Mixer_ChannelSetSync not BASS_ChannelSetSync) to confirm whether there is any stalling. Please also try with local files instead of internet URLs as the sources. The results of these tests should help to narrow down what/where the problem is.

[Chris Oakley]

Sorry for the length of time since the last update on this, it's a bit of a long form issue. I have to try something then leave it. However, I think I've figured out half of the issue. So in removing the NONSTOP from the mixer, it has solved this issue when I'm plugging a handle from a RecordStart into it and I'm also now using my own RECORDPROC to process the data rather than relying on the end mixer assigned to a No Device to deal with it.

So it's one of those steps that has now solved it for the input from a physical device.

The issue with a handle from a BASS_StreamCreateURL still stands though. It's not the source of the URL that's out, it's definately the BASS_StreamCreateURL because each instance of the application, and indeed each instance taking that feed in each application, all wander after a period of a day or so.

The BASS_StreamCreateURL handle plugs into the same mixer which has the NONSTOP removed now, so we can rule that out. I'm also not seeing any SYNCSTALLS from any of the mixers.

Should I process the BASS_StreamCreateURL handle myself in a loop like I have with the RecordStart handle? Would that be a fix?

[Ian @ un4seen]

It's been a while. I had a look at the whole thread for a reminder of what's going on, but it's still a bit of a mystery

As I understand it, you have multiple instances of an app running (on the same system?), all playing the same URL with BASS_StreamCreateURL through a mixer, and they start in sync with each other but drift apart after some time? And the apps are all playing their mixer on the "No Sound" device, not a real device? If so, please confirm how you're detecting that they drift apart, and what BASS version is used (as reported by BASS_GetVersion) and what BASS_CONFIG_DEV_BUFFER setting. Did you also set BASS_SYNC_STALL syncs on the internet streams (via BASS_Mixer_ChannelSetSync), not only the mixers? And did you also try playing a local file (with BASS_StreamCreateFile) instead of a URL, to see if the apps still drift apart then?