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.
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.
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.
This is a first cut at this to evaluate buffer size adjustments on
supported platforms. A final version might limit status bar reports to
>1000 dropped frames or similar.
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.
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.
The tool may be started with either '-o <file-path>' to record or with
'-i <file-path>', where file-path is an existing .WAV file, to
playback audio. Audio output devices may be listed with the '-O'
option and selected by index number using the '-P <device-index>'
option. No format conversions are done for playback by the tool so the
output device must support the format of the input .WAV file. The
playback duration is the duration of the input .WAV file.
The tool '-s <start-second-in-minute>' option is now optional, without
it recording or playback starts immediately. So to playback a .WAV
file:
$ record_time_signal -i wwv.wav
To play back the same file stating at second 55 in the minute:
$ record_time_signal -i wwv.wav -s 55
Use the '-h' option for more help.
The tool record_time_signal is designed to measure the performance of
QAudioInput. The intended use is to record a short period of live
audio from an on-air time signal of known good quaility, the basic
required parameters are an audio input device, an output file name
(.WAV), a start second in a minute, and a duration in seconds. So for
example to record the time signal ticks and fast data at the top of
the minute:
$ record_time_signal -o wwv.wav -s 55 -d 15
will record 15s of audio at 48000Hz sample rate, stereo, from the
default audio input device, starting at second 55. This will use a
separate timer to stop the recording which is likely to leave the
output file a little short due to buffer latency. The buffer size can
be adjusted using the '-b <buffered-frames>' option.
The tool also supoorts a different mechanism to time the recording
which uses the audio progress via a notify signal. This should ensure
at least the requested duration is recorded The shorter the notify
interval the closer teh final size shoould be to the requested
duration. Use the '-d <interval-ms>' option to adjust the notify
interval.
$ record_time_signal -o wwv.wav -s 55 -d 15 -n 100
Non-default audio devices can be selected, use the '-I' option to list
the available input devices with an index number that can be used to
select the device using the 'R <device-number>' option.
Other options are available, use '-h' for details.
These were discovered when running under teh valgrind MemCheck tool. I
have also checked in a suppressions file (wsjtx-valgrind.linux.supp)
suitable for use on Linux when running the valgrind MemCheck tool.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@6755 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
The BWFFile class correctly indicates errors like file access issues
and problems reading or writing headers using the BWFFile::error() and
BWFFile::errorString() operations.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@6751 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Clang++ detected some warnings that g++ did not.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@6409 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
WAV files were written with an incorrect fomat chunk average bytes per
second field. This only effects a few media players like WMP, most
ignore this field.
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@6405 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
Broadcast Wave Format is a backwards compatible superset of teh
Microsoft WAV file format that has been implemented in teh hope that
Windows File Explorer might show the WAV file metadta, as it turns out
that is not the case but as it's done anyway.
It appears to be impossible to write a WAV file such that MS Windows
File Explorer shows any metadata so unless we adopt FLAC format audio
files we will have to show metadata with our own software :(
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@6384 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
WAV files use 32-bit sizes so casts are needed on 64-bit files systems
git-svn-id: svn+ssh://svn.code.sf.net/p/wsjt/wsjt/branches/wsjtx@6340 ab8295b8-cf94-4d9e-aec4-7959e3be5d79
