_sndraw Delay

[NeverMind]

Hi folks,

recently i´ve been trying to do some sort of sound synthesis by using the _sndraw command and i´m quite stuck in case of the audible delay that is happening before the playback starts (at least more than 200 msec). I´m aware of the fact that the documentation for the _sndraw command talks about this delay unless the buffer holds a certain amount of samples, but i´m stuck about the question about which buffer is meant.

As i´m using Win7, my question is, if this is the caused by the Soundcard driver/buffer or a buffer function implemented into the QB-Sourcecode/c-Parts. I´ve seen in internal/c/parts/audio/out/src.c a parameter called "int32 snd_buffer_size", but changing it to a smaller size (and recompiling the hereby used QB64 developement package) has no effect regarding a faster audio response and i´m not quite sure if this source file is also compiled when running "setup-win.bat" - or if i´m complete wrong.

 Somewhere in a c-Source in the "AL" Source File Folder they talk about a  4*50msec buffer, but i suppose that this folder is there for ALSA.

I would not have any problem to switch over to QB64 on Linux if this "issue" can be solved by using ALSA/Pulseaudio, but i ask myself if the audio delay would still exists there.

I would be glad about any suggestions or tips !

Kind regards
 

[Petr]

Did you try to put the synthesis in the array and play it back? (make mixing sound in the array before use SNDRAW?) It's just my tip.

[NeverMind]

Thanks for the Tip, yep, i´ve created a small buffer which is been filled on one segment wile the other segment is being played back. The _sndraw command sits in its own routine, called repeaditly by a 5 msec Timer, and this routine is not leaved unless the current "buffer" has been played back (not waiting yields to a constantly rising memory usage of the entire process; i guess because of a race condition between buffer output and input) and doesn´t help either on the delay issue).

This works quite well except for the audible delay when initiating the "playback". I know that _sndraw is designed for continuous playback, but otherwise i cannot imagine how to hold _sndraw in playback state while it does circulate through memory boundaries by itself - and modifying the memory contents by another routine - and if this could solve the problem. Knowing the current playback position is also vital for calculating the waveform...

I´d like to keep the all buffers as short as possbile, to react on changes (caused by the waveform generation routine) as quick as possbible. It hasn´t to be in the area of ASIO or JACK/ALSA-like Latencys, but a 20-30 msec delay (at least if that could be handled by the hardware and drivers) would be great.