In order to support other issues such as #17, #29, #80 etc, we need to be able to handle both audio data and control signals over one data channel. Some suggested channels are:
Serial (Currently the only channel)
Bluetooth
UDP
The tricky part about the KV4P-HT embedded code is that it is designed to be simple for its signal processing (It doesn't do any signal processing). However, it is tricky to control it over the same channel as the audio stream. In order to support this uniformly over many different channels, it was suggested that we use the AudioTools library.
Possible Implementation
The AudioTools library has a very open design for the use of source and sinks. This means that the library wouldn't care whether the audio was coming from a UDP stream, a Bluetooth connection, or a Serial connection. We would be able to start up and configure with whatever logic we would like. We would just need to design the custom metadata class.
Background
In order to support other issues such as #17, #29, #80 etc, we need to be able to handle both audio data and control signals over one data channel. Some suggested channels are:
The tricky part about the KV4P-HT embedded code is that it is designed to be simple for its signal processing (It doesn't do any signal processing). However, it is tricky to control it over the same channel as the audio stream. In order to support this uniformly over many different channels, it was suggested that we use the AudioTools library.
Possible Implementation
The AudioTools library has a very open design for the use of
sourceandsinks. This means that the library wouldn't care whether the audio was coming from a UDP stream, a Bluetooth connection, or a Serial connection. We would be able to start up and configure with whatever logic we would like. We would just need to design the custom metadata class.Documentation of Possible Implementation