¿ªÔÆÌåÓý

  1. Direwolf
  2. Topics

Significance of #define ONE_BUF_TIME 40 #define

 

¿ªÔÆÌåÓý

Kind of asking John WB2OSZ

What please is the significance of?

// Originally 40.? Version 1.2, try 10 for lower latency.
#define ONE_BUF_TIME 10

in audio.c (also in the portaudio and windows audio code)

Reason I ask is that I have used pulseaudio under direwolf for years that has seen on average 1 in 10 TX packets audio buffer underruns. Changing this from 10 to 40 (Along with some other buffering and CPU speed changes) seems to have resolved them.

Yes I am aware that pulseaudio is not good with direwolf, but I am stuck with it.

With these changes I am not having any TX>RX delay problems that stop decoding of the next 1200AFSK packet.

Cheers Bob VK2YQA
 

ONE_BUF_TIME is roughly the number of milliseconds of audio samples in one audio input buffer.
So, in this case, there would be about 1000 / 10 = 100 buffers per second from the operating system to the application.
?
It works fine on a Raspberry Pi model 1 with USB audio.
?
Too long means more latency.? Too short means more overhead of shoveling more smaller things.
?
I did hear one report that a certain type of non-USB RPi audio interface did well with some buffer sizes and not with others.?
?
What direwolf version, computer model, audio interface type, and OS version are you using?
?
73,
John WB2OSZ
 

¿ªÔÆÌåÓý

Hi John

- Latest "get checkout dev", "git pull" by git etc

- Toshiba i5 laptop 8GB RAM, orig p/n Satellite P500/003 PSPGSA-024003

- Debian Bookworm up to date patched. I do a lot of build from source, mainly radio related. but pulseaudio is as per distro. The high and realtime priorities are still at default.

- USB audio inside Icom 9100 (PCM2901)

Okay thanks for that. After some longer term testing I'll try reducing?ONE_BUF_TIME to 20 and the pulseaudio buffer/latency size.

Cheers Bob


On 11/1/25 07:20, WB2OSZ via groups.io wrote:

ONE_BUF_TIME is roughly the number of milliseconds of audio samples in one audio input buffer.
So, in this case, there would be about 1000 / 10 = 100 buffers per second from the operating system to the application.
?
It works fine on a Raspberry Pi model 1 with USB audio.
?
Too long means more latency.? Too short means more overhead of shoveling more smaller things.
?
I did hear one report that a certain type of non-USB RPi audio interface did well with some buffer sizes and not with others.?
?
What direwolf version, computer model, audio interface type, and OS version are you using?
?
73,
John WB2OSZ

1 - 3 of 3