◆ BARKLY LABS
DOCUMENTATION
BARKLY / KNOWLEDGE

Functional Requirements fursuit monitoring voice system

Generated documentation produced by Barkly Docs.

SOURCE: C:\Users\nickk\Documents\Funcitonal-Requiremnts\Functional Requirements (your “fursuit monitoring voice system”).docx

Functional Requirements fursuit monitoring voice system

Think of this like you’re designing a real-time wearable audio OS module.

🎤 Core Audio Requirements

FR1 — Real-time microphone capture

System must capture audio from a microphone in real time

Target latency: < 30ms end-to-end

Sample rate: 44.1kHz or 48kHz

Mono input preferred (saves CPU)

FR2 — Live DSP processing pipeline System must support chained effects:

Minimum pipeline:

Noise gate / suppression

Pitch shift (identity change / character voice)

Optional formant shift (important for “non-chipmunk” voices)

Gain normalization

FR3 — Low-latency streaming output

Processed audio must be output continuously

No file buffering allowed

Must support Linux ALSA / PulseAudio AND Windows WASAPI

FR4 — Modular effects system You should be able to do:

set_pitch(1.3f);

set_formant(-0.2f);

enable_glitch_mode(true);

🌐 API / Network Requirements (your future suit brain idea)

FR5 — Remote control API

REST or WebSocket server running on Pi or companion device

Must allow live parameter updates:

pitch

distortion level

EQ curve

“character presets”

Example:

{

"pitch": 1.2,

"formant": -0.3,

"glitch": true

}

FR6 — Stream control endpoint

Start / stop DSP stream remotely

Switch profiles instantly:

“normal”

“crasher glitch mode”

“juice world haze mode” (your aesthetic presets fit here really well)

🧠 System Architecture Requirement

FR7 — Separation of concerns Your system should be split like:

[Audio Input]

↓

[Ring Buffer]

↓

[DSP Engine (C++)]

↓

[Output Device]

AND

[API Server] → updates DSP parameters live

🧩 Future Suit Monitoring Extensions

Since you said “fursuit monitoring system”, we can extend later with:

temperature sensors

heart rate / stress detection

movement tracking (IMU)

mic-based “crowd reaction detection”

battery/power state reporting

But we’ll keep v1 audio-only.

🧪 2. Minimal C++ DSP Prototype (cross-platform idea)

We’ll use:

🎧 Library choice (important)

For your goal:

👉 SoundTouch = easiest cross-platform pitch shifting 👉 PortAudio = cross-platform audio I/O

This combo is basically the “starter Voicemod kit”.

🔧 Install deps

Linux:

sudo apt install portaudio19-dev

Build SoundTouch:

git clone https://gitlab.com/soundtouch/soundtouch.git

Windows:

vcpkg:

vcpkg install portaudio soundtouch

🧠 Minimal real-time voice changer (concept code)

This is simplified but functional architecture:

#include <portaudio.h>

#include "SoundTouch.h"

using namespace soundtouch;

SoundTouch soundTouch;

#define SAMPLE_RATE 48000

#define FRAMES_PER_BUFFER 256

static int audioCallback(const void* inputBuffer,

void* outputBuffer,

unsigned long framesPerBuffer,

const PaStreamCallbackTimeInfo* timeInfo,

PaStreamCallbackFlags statusFlags,

void* userData)

{

float* in = (float*)inputBuffer;

float* out = (float*)outputBuffer;

SoundTouch* st = (SoundTouch*)userData;

st->putSamples(in, framesPerBuffer);

int received = st->receiveSamples(out, framesPerBuffer);

// if not enough samples, fill silence

for (int i = received; i < (int)framesPerBuffer; i++)

out[i] = 0.0f;

return paContinue;

}

int main()

{

Pa_Initialize();

soundTouch.setSampleRate(SAMPLE_RATE);

soundTouch.setChannels(1);

soundTouch.setPitch(1.2f); // voice shift

soundTouch.setTempo(1.0f);

PaStream* stream;

Pa_OpenDefaultStream(

&stream,

1, // input

1, // output

paFloat32,

SAMPLE_RATE,

FRAMES_PER_BUFFER,

audioCallback,

&soundTouch

);

Pa_StartStream(stream);

while (true)

{

// later: API updates go here

Pa_Sleep(1000);

}

Pa_StopStream(stream);

Pa_CloseStream(stream);

Pa_Terminate();

}

🌐 3. Where your API system plugs in

Later you add something like:

cpp-httplib (tiny HTTP server) or

WebSocket server

Then:

soundTouch.setPitch(newPitch);

soundTouch.setTempo(newTempo);

So your suit can literally do:

phone → sends JSON → voice instantly changes in helmet

⚡ Key insight (this is the Voicemod secret)

What you’re building is NOT:

“audio processing program”

It is:

a real-time state machine controlling a DSP pipeline

That’s why latency matters more than features.

🐾 If you want next step

I can help you level this up into:

🧠 “Fursuit Brain v1”

Raspberry Pi audio pipeline

WebSocket control server

Preset system (“modes”)

glitch/crash voice effect layer (your aesthetic fits PERFECTLY here)

overlay monitoring system (temp + stress + audio reactive LEDs)

Just tell me and I’ll help you turn this into a real modular system instead of just a