Topic: No Sound device running too slow on virtual machine

[yps]

Hi,

I have come across cases where the No Sound device (BASS_Init with device=0) is running too slow when the application is running on a virtual machine. Apparently this is caused by a faulty real-time clock implementation (or settings) of the hypervisor or VM.

Ian, would you mind sharing some implementation details of the No Sound device, and how the timing works internally? Are you using GetTicketCount64() or QueryPerformanceCounter()?

I read that the two APIs might not work equally well on VMs (again, depending on the hypervisor etc.). If I knew which one you use, I could try to create my own implementation using the other one and see if it works better.


Thanks,

Torben

[Ian @ un4seen]

It sounds like you're encountering the same issue that another user reported recently (off forum). In their case, it seemed to be that the "No Sound" device output update cycles were sometimes skipped due to erratic CPU given to the process. In the current release, BASS will allow up to 1 update cycle (BASS_CONFIG_DEV_PERIOD setting) delay, ie. it'll catch up 1 late update cycle but drop any later than that. To fix the problem, that was changed to use the BASS_CONFIG_DEV_BUFFER setting to determine the max allowed delay. Here's the update:

   www.un4seen.com/stuff/bass.zip

Please give that a try and see if you still have the problem with it. And if you do still have the problem then try raising the BASS_CONFIG_DEV_BUFFER setting.

[yps]

Thanks for the update. There is an improvement, but it still isn't fully in sync. With the release version, I lost around 2-3 seconds per minute, now it's about one second every two minutes.

I haven't adjusted the BASS_CONFIG_DEV_BUFFER yet. What value would you recommend?

[Ian @ un4seen]

The default is 30ms on Windows. You could try 100ms and see if that makes a difference. Unlike with real devices, the BASS_CONFIG_DEV_BUFFER setting doesn't determine how far in advance output is generated for the "No Sound" device (rather how far back it'll catch up from), so raising it won't affect latency and you can pretty much go as high as you like. Note you need to set it before calling BASS_Init.

[Chris Oakley]

Sorry to jump on this post, but this is interesting as we have recently found that two separate running instances of our app taking the same audio feed from an AXIA device (AOIP) - one of the app instances audio gradually drifts out and can end up with around a 9 to 10 second delay. No VMs here, but we believe this is a clock issue.

If we wanted to see if this latest BASS dll would fix this, how would we use the BASS_CONFIG_DEV_PERIOD as it isn't part of BASS.NET yet, so what would its value be so we could pass it direct?

[Ian @ un4seen]

Are you playing on the "No Sound" device in your case? If so, the BASS update above may indeed help and is worth a try. Note you would set BASS_CONFIG_DEV_BUFFER (not BASS_CONFIG_DEV_PERIOD) with the update, although you can set BASS_CONFIG_DEV_PERIOD too if you like (BASS.Net should support both).

[Chris Oakley]

We're using No Sound, but not in the scenario where we're seeing the issue so perhaps this wouldn't help.

When we see the issue on each app instance we are taking an input feed from the xNode engine and then we feed that through a bass mixer which gets fed to an AXIA LiveWire output. We suspect it could be clocking somewhere as AXIA works only on 48Khz where as we're instancing BASS in the app at 44.1Khz - so maybe something there.

[Ian @ un4seen]

Yes, that does sound like it's unrelated to the "No Sound" device, so would probably be unaffected by the update in this thread.

Are you creating the mixer with a 44100Hz rate while its output device is set to 48000Hz in the Sound control panel? If so, try setting the mixer to 480000Hz instead. If there are input/recording devices involved (eg. in the mix), they should also be set to the same rate in the Sound control panel. Having everything running at the same rate will avoid the need for resampling, and hopefully minimize timing differences.

[Chris Oakley]

Sorry, I know I've hijacked a thread here but we've been running some further tests on this Ian and found that initilising all mixers and devices to 48000 instead of 44100, as you have suggested, has stopped the buffer creep. Don't know if this infomation would help with the original post issue.

I can sort of understand why this might be the case with AXIA as it only deals with 48000, and if a virtual cable is set to 48000 also and the devices are being initialised as 44100 then again I can see why there could be an issue, but not clear on what the official reason for this would be.