I often see a large (50k) recorder buffer from the start...
Is that 50k from the recording buffer alone, not including the mixer's output buffer? If so, that translates to around 140ms of data in the buffer, which is strange given that the mixer and recording appear to be started at about the same time in the code above (so no time for excess data to build up in the recording buffer). Perhaps the order of the BASS_ChannelPlay and BASS_Mixer_StreamAddChannel calls is influencing it (see the LIMIT/NONSTOP comments below).
The recorded data will be delivered by Windows in blocks, usually of around 31ms on Vista/7. To confirm how the data is arriving there, you can do something like this...
hRecord = BASS_RecordStart(44100, 2, BASS_SAMPLE_FLOAT, NULL, 0);
printf("%d: start\n", timeGetTime());
DWORD avail=0, c=0;
while (1) {
DWORD a=BASS_ChannelGetData(hRecord, NULL, BASS_DATA_AVAILABLE);
if (a!=avail) {
printf("%d: %d\n", timeGetTime(), a-avail);
avail=a;
if (++c==10) break;
}
}
Please copy'n'paste the output from that.
I thought setting the BASS_MIXER_LIMIT flag synced the mixer to the recorder channel?
The BASS_MIXER_LIMIT flag will just limit the amount of data that the mixer produces to the amount available from the recording channel, eg. if there is nothing in the recording buffer then the mixer won't produce any output.
Note the BASS_MIXER_NONSTOP flag tells the mixer to produce silence (instead of nothing) when there is no data available from its source(s). The BASS_MIXER_LIMIT flag will override that, but the mixer is started (via BASS_ChannelPlay) before the recording is added in the code above, so the BASS_MIXER_NONSTOP flag will have effect initially, ie. the mixer's output buffer will initially be filled with silence.
I need to have a predictable (and low) latency
Is using ASIO a possibility for you, eg. BASSASIO? That is better suited to predictable full duplex latency, as the driver's input and output processing is synchronised.
