VT bug

English mAirList 5.x
1

I’ve just tried VT with V5 and I am getting problems. Please see bug reports.
It works OK with V4.4 the only message I get is Bass Update period (100) is too large for buffer size (100) for device (2) decreasing.

For V5 the VT playback stutters, then continues and then stutters. There does not seem to be a Mic signal when this happens, however, the mic peak meter responds prior to starting the VT process. The message Direct Sound Sound Blaster: timeout waiting for data after 11000ms. When I try to restart VT that’s when the errors are reported, I think there could be several issues so here are 2 bug reports.

bugreport2.txt (44.4 KB)

bugreport3.txt (44.3 KB)

2

I’ve just tried the latest build and there is the same issue of the VT stuttering/freezing the message about the soundblaster time out is still coming up. However, I can restart VT and it does the same thing. What has gone are the cascade of error reports.

3

The errors you saw were because the DirectSound record devices wasn’t unitialized properly when you closed VT, and when you reopened VT, mAirList was unable to initialize it again.

“Timeout waiting for data” means that mAirList has opened the record device, but did not receive any data from it within reasonable time.

Some cards don’t like operating in floating point mode. Try setting it to 16 bit (uncheck the BASS_SAMPLE_FLOAT options in mAirListConfig -> Audio Settings -> DirectSound -> Recording tab - make sure to select the Audigy card from the list first).

The other message you see, update period is too large, means that you should decrease the BASS update period (mAirListConfig -> Audio Settings -> General) so it is about half of the lowest “hardware buffer size” or “mixer buffer size” value of all DirectSound playback devices (mAirListConfig -> Audio Settings -> DirectSound -> Playback tab).

When you have a buffer size of 100ms, and the is only updated every 100ms, you will likely suffer dropouts from time to time because the update may happen 1ms or 2ms too late. The update period should be at most half the buffer size, e.g. 50ms for a buffer size of 100ms. You can also use a lower value (I think 10ms is the default), it may result in a little more CPU load, but hardly noticable.

4

Last things first. I’ve set the update to 50ms and that has stopped the message in V4.4 - Thanks

In V5
I set the update as above.
“Some cards don’t like operating in floating point mode.” It was not set to Bass_Sample_Float anyway.
I tried a different input for the VT, namely CH3-4 from my ESI sound card and it suffers the same problem i.e. stutter/freezing and the Timeout message.

Is V5 audio fundamentally different to V4.4, as this works fine?

5

Yes, the audio engine has changed a lot.

Perhaps it is because you are mixing ASIO and DirectSound? I see in the bug report that the default record device, as well as the encoder Line input, are set to ASIO? Is there any particular reason for that?

6

I originally started the ESI in Asio mode but there were some clicks on the players which I could not really eliminate by changing the latency settings. So I changed the players to direct sound and that cured the problem. I guess the record input was overlooked at the time, as everything sounded fine. [I wonder if reducing the update to 50ms, might solve that…but one problem at a time]

I have changed V5 all to direct sound inputs and outputs. VT still gives the same problem.

7

I’ve just changed everything to ASIO via the ESI card and the VT audio just buzzes and the screen virtually freezes.

8

Hm, no problems whatsoever here, all works fine.

I assume you see the same error message when you try to use the record device for another function, e.g. for a Live Feed or as the encoder line/mic input?

9

Here’s a debug version to try (for DirectSound). It writes a log file debug-.txt in the program folder. Please post that file here.

The debug file will grow very large when it runs for too long, so only make a very brief test (opening and closing VT, or wait for the timeout error to occur).

10

I’ve repeated everything afresh this morning, still the same problem using all ASIO and all direct.
The encoder works OK. I can’t see the debug version!

11

Sorry, forgot to include the link:

https://www.dropbox.com/s/0n92rfajmvcq19s/setup.exe?dl=0

12

File should be here.

https://www.dropbox.com/s/53qdasqmjfyn64b/debug-20141118-10.txt?dl=0

13

Thanks. Just for clarification - “U46 Ch34” is now used for VT mic?

I also see “U46 Ch12” being used, that’s for an encoder input then I assume?

14

Yes, that’s correct. I thought to eliminate the soundblaster at this stage.

15

Another question, when you say that the sound starts to crackle when you open VT, which audio do you refer to?

It appears that you have set the VT Mic Monitor to “no playback”, so your Mic signal should not be audible at all. Do you have any active players at that time?

16

On opening the VT, both players load OK. The mic peakmeter responds to any sound present.
On clicking the record button, player A starts but stutters (repeats same note), there is some evidence of mic waveform but that freezes too. The stuttering then stops, and the song continues, and then stutters again.

I monitor the mic signal via PFL on my mixer.

Both players are active.

17

I have updated the debug build, can you please try and send me the debug output? Also generate and send a bug report (from the About menu), so I can review your current audio settings.

https://www.dropbox.com/s/0n92rfajmvcq19s/setup.exe?dl=0

I found one issue where it can happen that a record device doesn’t deliver the data fast enough to keep in sync with the playback device. I was able to reproduce it by choosing the DirectSound microphone input (on my Parallels virtual machine, which is somewhat slow wrt. audio), and the WASAPI speakers output with a fairly low buffer setting (50ms). You could hear crackle, and see the “want: xxx, got: yyy” messages at the same time.

mAirList uses an adapting algorithm that tries to synchronize the record and playback devices with the lowest possible latency. When the recording is started, and there is not enough recorded data for playback, mAirList would insert null samples (that’s the crackle you hear) until the devices are eventually in sync.

That algorithm has already existed in v4.4, there haven’t been any changes to it.

The only change between v4.4 and v5.0 is that v5 is now using BASSmix splitters to distribute the recorded data to multiple “listeners” (monitor device; peakmeter; recorded WAV file), while v4.4 had my own code for that job (which I developed when BASSmix splitters didn’t exist).

What puzzles me a bit is that there is an effect on the playback devices you use for VT, although they aren’t connected to the record source in any way (record data goes to the “no playback” sink, not to any device).

And then I noticed something

10:26:59.121 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:26:59.121 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:26:59.136 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=3528
10:27:04.292 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:04.292 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=6552
10:27:04.308 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=6552

“HandleRecordData” means that the sound card is passing recorded sample data back to the application. You can see that there is an average of 10ms between two calls, and the data length is 1764 byte (which happens to be exactly 10ms worth of audio data with 44100/16bit/stereo).

Now in the above excerpt from the log file, there is suddenly a 5 second gap where no audio data is provided at all!

And here, again:

10:27:39.006 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:39.006 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:39.021 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:44.287 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:44.287 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=6552

In other words, the entire recording process stops for 5 seconds. Do you think this is the point where you clicked the record button?

18

The latest debug file. I set up VT and clicked the record button at 16:25:10.

If you want to see this happening there is always teamviewer.

debug-20141118-16.txt (1.17 KB)

bugreport4.txt (40.1 KB)

19

Hm, the debug file looks rather short… Uploaded the wrong one?

Here’s another update to try:

https://www.dropbox.com/s/0n92rfajmvcq19s/setup.exe?dl=0

By the way, does it also happen when you choose a “real” device as the VT Mic Monitor output?

20

Made another change. If you downloaded the version from last night, please get this new one now:

https://www.dropbox.com/s/0n92rfajmvcq19s/setup.exe?dl=0