Commit Graph

15 Commits

Author SHA1 Message Date
Bill Somerville
60792182ad
Environment variables to set audio buffer sizes and fix Windows Rx timing
The two environment variables:

    WSJT_RX_AUDIO_BUFFER_FRAMES
    WSJT_TX_AUDIO_BUFFER_FRAMES

each can  be defined to  an integer number which  will be used  as the
suggested audio  buffer size for  Rx and Tx respectively.  Not setting
the variable  or setting  it to  zero or less  will cause  the default
buffer size to be used, which should be a good choice for most, if not
all, systems.
2020-12-07 20:34:56 +00:00
Bill Somerville
ad8c33bee7
Try not setting low-latency audio category 2020-12-03 14:31:46 +00:00
Bill Somerville
50d0543c03
Test version with environment variable to set Tx audio buffer size
WSJT_TX_AUDIO_BUFFER_FRAMES takes the following values:

 -1          - use Qt/system default
 0           - use 200 mS (WSJT-X default)
 +ve integer - value is number of frames at 48 kHz

-1 is  likely to  be a  good choice on  Windows and  may macOS.  0 has
proven to be good on Windows. On Linux  0 may be OK but we need to try
other values.

The value is only a hint, the  actual value used along with the period
size (the  size of each chunk  of samples requested by  the system) is
printed  in an  info level  diagnostic message  at the  start of  each
transmission.
2020-12-03 01:49:21 +00:00
Bill Somerville
5f85dfac61
Looking for a Tx audio buffer size that works on macOS. 2020-12-01 21:24:41 +00:00
Bill Somerville
041c6b68fe
Reduce non-Windows Tx audio buffer size 2020-12-01 21:05:01 +00:00
Bill Somerville
6214cc9835
Use same user defined audio out buffer sizes on all platforms 2020-12-01 20:55:10 +00:00
Bill Somerville
f12f481955
Remove unused member variable that breaks the Raspberry Pi build 2020-09-26 17:47:38 +01:00
Bill Somerville
542ffe8311
Improve audio device handling and error recovery
where possible  audio devices that  disappear are not  forgotten until
the user selects another device, this should allow temporarily missing
devices or forgetting  to switch on devices before  starting WSJT-X to
be  handled more  cleanly. If  all else  fails, visiting  the Settings
dialog and  clicking OK should  get things  going again. Note  that we
still  do not  have  a  reliable way  of  detecting  failed audio  out
devices, in that  case selecting another device and  then returning to
the original should work.

Enumerating  audio devices  is expensive  and on  Linux may  take many
seconds per  device. To avoid  lengthy blocking behaviour until  it is
absolutely necessary,  audio devices are  not enumerated until  one of
the "Settings->Audio" device drop-down lists is opened. Elsewhere when
devices  must be  discovered  the  enumeration stops  as  soon as  the
configured device is  discovered. A status bar message  is posted when
audio devices are being enumerated as a reminder that the UI may block
while this is happening.

The message box warning about  unaccounted-for input audio samples now
only triggers when  >5 seconds of audio appears to  be missing or over
provided. Hopefully this will make the warning less annoying for those
that are  using audio sources  with high and/or variable  latencies. A
status  bar message  is still  posted for  any amount  of audio  input
samples  unaccounted for  >1/5 second,  this message  appearing a  lot
should be considered as notification that  there is a problem with the
audio sub-system, system load is  too high, or time synchronization is
stepping the PC clock rather  than adjusting the frequency to maintain
monotonic clock ticks.
2020-09-20 18:20:16 +01:00
Bill Somerville
65f994ce90
Improved audio stream error handling 2020-08-16 00:55:29 +01:00
Bill Somerville
e69226b29a
Avoid enumerating audio devices until absolutely necessary
Enumerating  audio  devices with  QAudioDeviceInfo::availableDevices()
takes  a  long  time  on  Linux  with  pulseaudio.  This  change  only
enumerates  up  to  the  selected device  when  configuring  and  only
enumerates the whole list when the Settings->Audio tab is current.

This change also warns  with a message box when Tx  is started with no
audio output device configured.
2020-08-12 02:33:15 +01:00
Bill Somerville
4f68dfda40
Only tune audio buffer sizes on Windows 2020-08-11 14:27:46 +01:00
Bill Somerville
0cf14dfcc9
Remove user adjustable audio buffer sizes from Settings
Fixed buffer sizes are  used. Rx use s 3456 x 1st  downsample rate x 5
audio  frames  of  buffer  space.  On Windows  this  means  that  each
chunk (periodSize())  delivered from the  audio stream is  our initial
DSP processing chunk size, thus  matching audio buffer latency exactly
with WSJT-X's  own front  end latency. This  should result  in optimal
resilience to high system loads that might starve the soundcard ADC of
buffers to fill and case dropped audio frames.

For Tx  a buffer sufficient for  1 s of  audio is used at  present, on
Windows  the period  size will  be  set to  1/40 of  that which  gives
reasonably low latency  and plenty of resilience to  high system loads
that might  starve the soundcard DAC  of audio frames to  render. Note
that a 1 s  buffer will make the "Pwr" slider slow  to respond, we may
have to reduce the Tx audio buffer size if this is seen as a problem.
2020-08-11 13:48:01 +01:00
Bill Somerville
6ea62d9476
Remove default audio devices from audio configuration
This enforces  an audio input device  in the settings dialog  since we
can't do anything  without an input device. A nil  audio output device
is allowed with a warning.
2020-08-08 16:57:51 +01:00
Bill Somerville
a0ceace5b4
User configurable audio device buffer sizes
Adjusting these may help with  audio drop-outs, particularly on slower
CPU systems or heavily loaded systems. Smaller buffer sizes leave less
margin for  process interruptions,  larger sizes waste  resources that
could impact other processes.
2020-08-08 16:25:14 +01:00
sirhc808
1f57ba5fec improve physical structure 2019-07-02 12:45:05 -05:00