TestTuner and TestTunerController implementations. This implementation
only has support for channels that are completely centered within a
channelizer output. Two output slice stitching to form a composite
channel will be implemented next.
Initial profiling indicates that the FFT function within the polyphase
channelizer is now the dominant processing workload - 28% cpu loading
when channelizing a 10 MHz sample rate input into 800 channels running
at 25.0 kHz each. This is ideal for offloading to an OpenCL kernel and
running on a GPU.
complex buffer listeners. Removes complex buffer broadcast support from
the source manager and renames it to channel source manager to convey
that it's only responsible for providing channels from the tuner.
calculator must be updated immediately any time the tuner's center
frequency changes so that a channel can be allocated immediately. So,
I changed source event handling to two parts where the channel calculator
is immediately updated and the channelizer configuration is deferred so
that it can happen on the buffer processor execution thread and we can
avoid any sync() locking on the channelizer or polyphase channel
sources.
messages and events can be accurately timestamped, and more importantly,
allocated traffic channels can request to be pre-loaded with buffered
samples to ensure that traffic channels don't miss any samples that
are currently missed due processing latency inherent in current buffer
sizing. This should reduce the clipping of starting messages or voice
on the traffic channels.
Restructures processing path for tuner frequency and sample rate change
events. The tuner now embeds these events in the sequence of buffers
that are generated immediately after the event occurs since those are
the buffers that will be impacted by the change. Previously, the change
event would be broadcast throughout the system and would impact any
buffered/cached buffers. This also reduces the number of source event
change listeners that have to be managed. Note: this change is not yet
implemented in all tuners ... only in the TestTuner implementation.
Updates the polyphase channelizer to now buffer channel results and then
dispatch the buffer to the channel output processors to improve efficiency
of using float arrays versus single value complex float processing.
center frequency each time we allocate a new DDC/channel. Adds
support for broadcasting channel count change source events so that the
tuner can accurately convey sourced channel counts via tuner events.
Completes changeover of polyphase channel manager to support arbitrary
bandwidth channels. The new approach provides greater compatibility
across any tuner sample rates. Likewise, all decoders will have to be
updated to adapt to any channel sample rate, although channel bandwidths
will be at least 12.5 kHz and likely no more than 25.0 kHz, with a 2x
oversampling that produces channel sample rates in range 25.0 - 50.0
kHz.
Updates wave writer to add the metadata LIST and ID3 chunks to the end
of the recording so that the file contains the final/complete set of
metadata that was accumulated over the call lifecycle.
controllers manager sample buffer processing and channel management.
General cleanup across all modules to remove the executor from each
of the start() methods. Removed the B100 tuner class since it's not
yet implemented.
controllers manager sample buffer processing and channel management.
General cleanup across all modules to remove the executor from each
of the start() methods. Removed the B100 tuner class since it's not
yet implemented.
Updates Icecast TCP broadcaster to correctly handle content type:text/html
message that normally follows mount point in use error received from
broadcastify.
Changes mount point in use broadcast state to be a temporary error so that
the stream will attempt to reconnect after receiving this error.
Updates logging to include memory allocation/usage metrics with each
logging entry in order to support debugging issues related to high
memory usage situations. Updates initial application logging to better
identify the host system operating environment.
occured when the ChannelProcessionManager was allocating a new channel
causing the tuner to invoke the updateLOFrequency() method that was
trying to find a center tune frequency that would accommodate all of the
channels, specifically in the instance where the distance between the
highest channel and the middle channel was exactly one-half of the
tuner's bandwidth. This situation would cause the calculated adjustment
to be zero and would cause an infinite loop, locking all channels from
accessing the any channel startup/teardown events and causing running
channels to block with buffer overflows. Added 1 to the adjustment to
ensure that the initial adjustment placed the center overlapping channel
fully to the left of the center DC spike so that on the next iteration
that channel would no longer be overlapping.
