DRAFT: Use AudioTools - Githubissues

wsciaroni commented 2 weeks ago

DRAFT: NOTE

This Pull Request currently exists for visibility so that other developers will see this is being worked if they would like to contribute to it. This is very much a work in progress.

Background

There are several variants of KV4P-HT that have varying requirements for audio flow. For instance, some want to allow the audio to flow via Bluetooth to and from the ESP32. In order to accommodate these future improvements, this MR aims to change the ESP32's code design. There are some notable changes in the Pull Request that each need to be considered carefully should they be accepted.

Notable Changes

Updated Serial Protocol for TX audio and Control
Upgrade to ESP32 v3.0.5 from ESP32 v2.0.17 (Recommended by pschatzmann)
Additional dependency on pschatzmann's Arduino Audio-Tools v1.0.0 (Currently using latest for testing)

1. Serial Protocol

The following lightweight protocol has been designed to meet our current needs.

2. ESP32 v3.0.5

This change was recommended by pschatzmann. This upgrade to v3 of the ESP32 bring along with it v5 of the ESP IDF. This includes a re-write of the I2S and an implementation of ADC/DAC Continuous mode.

Using the Audio-Tools library, I experimentally determined that the sampling rate needs to be 53904 Hz. I setup a python script to read the samples from the ESP32's serial from my desktop. I set it up to count the number of characters received over a period of 120seconds. Based on our target sample rate of 44100Hz, we were looking for 5292000 samples / 120 seconds. Based on the requested sample rate of the adc_continuous driver via Audio-Tools of 53904 I received ~5291470 samples. This is an error of about %0.01.

3. Dependency on Audio-Tools

I believe the flexibility of using Audio-Tools outweighs the downside of adding one library dependency. This is of course up for discussion.

Outstanding Issues

The following things have not been completed, but must be completed before this is ready

[x] Configure RX Audio
[ ] Configure TX Audio
[ ] Tweak RX Audio
[ ] Tweak TX Audio
[ ] Tweak App Buffer size to reduce RX Latency
[ ] Tweak The ESP32 TX Buffer size to reduce TX Latency
[ ] Configure Fade in and out using a Fade Stream

gx1400 commented 1 week ago

Is TuneCmdMsg in your diagram missing tone int and squelch int?

gx1400 commented 1 week ago

What do you think about adding an ack response back to the host over serial whenever a command is processed?

Maybe something like a MsgType of ACK = 0x55

gx1400 commented 1 week ago

Would you also consider GetFrequency, GetFilterSettings, etc commands?

wsciaroni commented 1 week ago

What do you think about adding an ack response back to the host over serial whenever a command is processed?

Maybe something like a MsgType of ACK = 0x55

That sounds great, but I'm worried about what that looks like in RX_MODE

wsciaroni commented 1 week ago

Would you also consider GetFrequency, GetFilterSettings, etc commands?

That sounds good to me.

gx1400 commented 1 week ago

What do you think about adding an ack response back to the host over serial whenever a command is processed?

Maybe something like a MsgType of ACK = 0x55

That sounds great, but I'm worried about what that looks like in RX_MODE

I will need to review code more thoroughly

Maybe the expanded proposal could be additional MsgTypes

0x0F is command from host 0xF0 is audio data 0x55 is command acknowledge 0x01 is GetVersion response 0x02 is GetTuningParams response 0x03 is GetFilterSettings response Etc

wsciaroni commented 1 week ago

The RX audio is just a byte stream. This allows us to just use the AudioTools library to put raw data into serial without having to interact with it.

We could use a custom audio encoding to hold the commands as metadata as suggested by the author of AudioTools.

On Fri, Nov 8, 2024, 1:19 PM gx1400 @.***> wrote:

What do you think about adding an ack response back to the host over serial whenever a command is processed?

Maybe something like a MsgType of ACK = 0x55

That sounds great, but I'm worried about what that looks like in RX_MODE

I will need to review code more thoroughly

Maybe the expanded proposal could be additional MsgTypes

0x0F is command from host 0xF0 is audio data 0x55 is command acknowledge 0x01 is GetVersion response 0x02 is GetTuningParams response 0x03 is GetFilterSettings response Etc

— Reply to this email directly, view it on GitHub https://github.com/VanceVagell/kv4p-ht/pull/89#issuecomment-2465582026, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGK2CWWB4HL6CY6WHEZ7XL3Z7UFE7AVCNFSM6AAAAABRMO5YWCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGU4DEMBSGY . You are receiving this because you authored the thread.Message ID: @.***>

wsciaroni commented 1 week ago

@thaaraak

Do you have any wisdom that would help me get the AudioTools portion of this PR configured? It looks like you've got a really cool SDR Transceiver project working with that already