▲

[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?

[Chris Oakley]

Yes, it's an involved little issue. I think there are so many "moving parts" so to speak with what we're doing that it's easy to be distracted to where the problem actually is.

So I'm fairly certain now that the issue is localized to the BASS_StreamCreateURL stream. My reasoning is since putting the record onto a RECORDPRC it's absolutely bang on. It never drifts from application instance to application instance. The channel doing the RecordStart is plugged into the same mixer setup as the BASS_StreamCreateURL channel so all is good there. I know it's not the mixer setup, else the record would drift.

There were some issues around when the app starts and it initializes all its inputs and outputs that would cause a delay on the BASS_StreamCreateURL, but I've sorted that now and I've taken one last step to try and remove any buffering issues caused by the BASS_StreamCreateURL channel being plugged into a mixer.

So what I've done is I open the BASS_StreamCreateURL on a No Sound device and play it, so I know it's being consumed / played at the correct rate. I then make a DSP_StreamCopy of that channel and set the TargetMixer to be the mixer I want to plug into.

This works and seems to keep the streaming PCM data pretty much in sync from app to app. I do see an ever so slight difference in the level meters, but we're talking something like 200ms from time to time. Now there may be something that can be changed when that ServerInit is raised as I'm currently using a buffer of 64000 and a burst of 64000 also.

I should also add that I'm not getting any Sync Stalls on the mixers or the BASS_StreamCreateURL channel, so I'm confident the data is being consumed without issue. The BASS_CONFIG_DEV_BUFFER is 30 and the BASS version is 2.4.17.4

[MB_SOFT]

i would suggest you BASS_CONFIG_DEV_PERIOD=50 and BASS_CONFIG_DEV_BUFFER=100  this si what i'm using on No Sound device and zero problems with it.

[Chris Oakley]

So just this:

Code SelectExpand

Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_DEV_PERIOD, 50)
Bass.BASS_SetConfig(BASSConfig.BASS_CONFIG_DEV_BUFFER, 100)

immediately after I initialize BASS or can I do it before? In other words do I need to do a:

Code SelectExpand

Bass.BASS_Init(0, g_DeviceFrequency, BASSInit.BASS_DEVICE_DEFAULT, IntPtr.Zero)

first or can I do it before this?

[MB_SOFT]

me i'm using it just before to call BASS_Init

[Chris Oakley]

Ian, what's your thoughts on this and what I wrote above? I'd like to understand why changing these values would have an effect.

[Ian @ un4seen]

With BASS_CONFIG_DEV_PERIOD=50 and BASS_CONFIG_DEV_BUFFER=100 set on the "No Sound" device that means it'll generate/mix 50ms of data in each update cycle and allow delays of up to 100ms before it starts dropping them (with BASS 2.4.17.4). BASS_CONFIG_DEV_PERIOD/BUFFER changes take effect from the next BASS_Init call, so you should set them before calling BASS_Init. In the next BASS release, the "No Sound" device will have a dedicated delay allowance option (instead of using BASS_CONFIG_DEV_BUFFER), which will allow realtime adjustment (without calling BASS_Init again).

Regarding the problem, as you say, there seem to be a lot of parts. I think the best way to find the cause of the problem is to try removing/disabling things until it goes away, so I still think it'd be a good idea to try with a local file (with BASS_SAMPLE_LOOP set so it's never-ending) instead of a URL, to confirm that it only happens with URLs.

[Chris Oakley]

Thanks Ian. As per my info, it's fair to say the problem isn't at the mixer. If it was I'd be seeing the RecordStart drifting, which I no longer do since I put a RECORDPROC on the RecordStart. This drifting is purely on the BASS_StreamCreateURL now.

What I've now done is, as per your suggestion, told it to play on loop via a local file rather than a stream, to see what the result of this is. This is done with a very simple:

Code SelectExpand

Bass.BASS_StreamCreateFile(_File, 0, 0, BASSFlag.BASS_SAMPLE_LOOP)
This is plugged into the same mixer and treated the same as the stream when playing a URL.

I don't expect it will drift, but we will have to wait and see what happens in a few days.

[Chris Oakley]

So playing a local file using

Code SelectExpand

Bass.BASS_StreamCreateFile(_File, 0, 0, BASSFlag.BASS_SAMPLE_LOOP)
instead of streaming using

Code SelectExpand

Bass.BASS_StreamCreateURL(_VirtualCableUrl, 0, BASSFlag.BASS_DEFAULT, Nothing, IntPtr.Zero)
is fine. I've got 3 inputs using the stream and 4 using the local file and all 4 local files are perfectly in sync. However, the stream ones are now all out of sync. This is all in the same instance of the app and playing via the No Sound device.

So by my deductions there has to be something wrong in BASS when playing a stream. If it was an mp3 encoded stream and it was coming across the network I could probably understand it, but this is being streamed in PCM 44.1Khz Stereo and it's on the same PC, so no network involved, and the same stream is coming into the same application - so how 3 instances of the BASS_StreamCreateURL in the same app can start all in sync and then all be so different after a day or two is beyond me.

[MB_SOFT]

you could use one single call to BAS_StreamCreateURL and the split in 3 different streams with BASS_Split_StreamCreate

[Chris Oakley]

I did think of that, but the problem is that we have multiple instances of the application running, not just one. Plus the problem would cause that one stream to drift - it wouldn't be correct, and it's stream needs to be solid.