Recovery and restoration service:frontea online,corp.

Recovery and restoration service:frontea online,corp.

Deep Abyss Audio (8) CCC Core: Pro‑Audio Spec PopoDAC (USB DAC) DIY

‹ 2026/01/02 ›

Hello again. Welcome to Episode 8 — the long‑awaited chapter on the DDC Central Control Center (the core body).

(We’ve finally arrived at the shopping mall you’ve all been waiting for!)


I imagine many of you have reached this point with a lingering doubt:

“Can this philosophy really run on an ESP32‑S3?”

Some of you may still be thinking:

“This feels impossible…”

Let me state the conclusion first.

PopoDAC’s completeness has already exceeded 100% at the time of this writing.

On Windows systems, PopoDAC now operates with such precision that it can sense and control not only the OS‑level timing behavior, but even the subtle reaction errors and micro‑stresses occurring inside individual applications such as YouTube, Winamp, and VLC.

Even Lightning‑generation iPhones now show about 99.5% compatibility.

(To be honest, I myself was shocked — so this is what happens when you install the real thing?

And it’s running on an 800‑yen ESP32‑S3!)

What is the DDC Central Control Center?

Let’s compare the role of the CCC with an ordinary design, using an updated version of the bicycle diagrams from the previous chapter.

DDC-CCC (ordinary)

This diagram represents what a typical CCC is expected to do.

The job of a normal CCC is simply “transfer management.”

  • - Receive data
  • - Send data
  • - Perform SRC if necessary

This is what the CCC of a typical USB‑DAC “does.”

Or perhaps more accurately, “thinks it is doing.”


PopoDAC DDC-CCC

As explained previously, PopoDAC’s CCC is responsible for controlling an extremely unstable bicycle.

The role of PopoDAC’s CCC is Harmony itself.

And this harmony extends continuously from:

Host → DDC → I2S → DAC → Space → Listener,

binding them into a single moment of time.

This is a realm invisible to ordinary CCCs.

But PopoDAC can lock the world through its MASTER TIMELINE.

Once the lock is complete, PopoDAC’s CCC begins to reach into realms beyond both ends of the chain — places normally impossible to perceive.

It gains the ability to govern everything from the audio source to the human listener, unifying them into one moment.

This is the completed form of a CCC born from Pro‑Audio design philosophy.


The Essence of the CCC

To summarize, the final mission of the CCC is simply this:

“To perfectly align the worldlines of USB and I2S, and keep them permanently STUCK (fixed).”

The moment this STUCK state is achieved,

PopoDAC becomes a manipulator of time.

And the listener enters a world guided by the performer.


Defining the CCC

Concretely, the CCC defined here resembles something like the PAXA Space Command Center.

  • - UAC rocket
  • - I2S rocket
  • - Launch preparation
  • - Pre‑roll control
  • - Orbit and attitude control
  • - Balancing time and space

All instruments and control interfaces required for actual launch are prepared here.

Of course, this includes all controls needed after entering the ballistic trajectory (MASTER TIMELINE).

Everything required for command and control must be housed within this CCC.


ddc_control_t Structure

Now, let’s define the DDC Central Control Center.


typedef struct {

    // audio stream settings

    audio_quality_t uac_quality;


    // USB-side state management

    bool usb_mounted; // USB mount state

    bool uac_alt1_active; // Out EP open/close (speaker stream)

    uint8_t uac_alt1_muted; // mute state

    int16_t uac_alt1_volume; // volume


    // Feedback pre-roll: reduce drift during startup

    int16_t uac_fb_inverval_count; /* align TX interval to (1 << (UAC_EXPLICIT_FB_INTERVAL - 1)) ms */

    bool uac_fb_started; // FB launch signal

    bool uac_fb_start_pending; // FB launch preparation signal

    bool uac_fb_locked; // FB lock state

    int16_t uac_fb_lockcount; // FB unlock counter

    int32_t uac_long_err_mHz; // long-term accumulated error (mHz)


    // I2S pre-roll: absorb drift immediately after ALT1 activation

    bool i2s_starting; // I2S launch preparation signal

    uint32_t i2s_start_ms; // I2S launch countdown timer


    // I2S ASRC controller (SRC and Killer)

    bool i2s_src_enabled; // ASRC enable/disable (debug)

    bool i2s_src_inited; // SRC pre-roll completed flag

    bool i2s_src_locked; // SRC locked

    int16_t i2s_src_lockcount; // SRC unlock counter

    int32_t i2s_pcnt_delta_hz; // delta Hz passed to SRC

    float i2s_src_phase_ratio; // resampler phase ratio (USB/I2S)

    float i2s_src_smooth_ratio; // SRC smoothing rate

    float i2s_src_phase;      // ASRC internal phase (interpolator state)

    int i2s_src_in_idx; // interpolator input sample index

    

    // counter pre-roll

    bool counter_warmup_rollout; // counter warm-up completed


    // monitoring — health status

    int16_t ddc_ring_looses; // DDC ring starvation, quantization noise, jitter noise source

    float ddc_ring_wl; // DDC ring water level

    int16_t ddc_rx_size; // UAC receive buffer size

    int16_t ddc_tx_size; // I2S transmit buffer size

} ddc_control_t;


How does it look?

It really does feel like a mission control center, doesn’t it?

It’s hard to believe this is the control tower of a DIY USB‑DAC built on a tiny toy‑class MPU module — it’s absolutely packed.

To the point where you might think:

“Isn’t this just over‑complicated?”

And honestly, that reaction is natural.

But PopoDAC has a DDC that truly captures quantum‑level (minimum unit) timing, so this level of structure is necessary.

And despite how dense the structure looks,

the actual operational code is not that complex.

In fact, it’s clean, orderly, and elegant.


audio_quality_t Structure

At the beginning of the DDC control block, you’ll find this structure.

It’s not part of the command/control system — it simply holds the current preset.

typedef struct {

    int32_t sample_rate; 

    int8_t channels;

    int8_t resolution_bits;

    int8_t sample_bytes;

    int16_t frame_size;

    int16_t mclk_multi;

    float rms_max;

} audio_quality_t;


Here, PopoDAC performs actual pulse counting, so sample_rate and mclk_multi are both placed under CCC authority.

rms_max is a fixed value used for display purposes.

A common point of confusion is the difference between sample_bytes and frame_size.

  • - sample_bytes is treated here as resolution_bytes
  • (I know — I should rename it, but it’s a hassle.)
  • - frame_size is the per‑1ms byte count, and therefore reflects the number of channels.

clock_counter_t Structure

Detailed PCNT‑related information has been separated from the DDC and placed into its own structure.

typedef struct {

    int src;

    int mclk;

    int16_t mclk_multiple;

    int16_t lrck;

    int bclk;

    int bclk_divn; // integer part = mclk / bclk

    int bclk_divi; // fractional part = mclk % bclk


    // Counters

    int16_t pcnt_diff;

    int16_t pcnt_cur;

    int16_t pcnt_last;

    int32_t pcnt_fs;

    int16_t pcnt_warmup;

    int32_t pcnt_fs_history[3]; // 3‑point median filter

    int16_t pcnt_fs_factor;


    // ASRC-related

    uint32_t last_fb;        // Q14

    int32_t acc_q14;        // fractional accumulator (Q14)

    int32_t delta_fb_q;

    float source_clock_ratio;

} clock_counter_t;


You might be thinking:

“Wait, isn’t bclk_divi unnecessary?”

Yes — it is unnecessary.

It exists purely for program error detection.

The middle section is used for counter measurement,

and the final section is used for compensation.


log_entry_t Structure

This structure is used for log monitoring entries.

typedef struct {

    bool uac_fb_started;  // after UAC FB has started

    bool uac_fb_locked;   // UAC FB locked

    bool i2s_inited;      // I2S initialized

    bool i2s_locked;      // I2S locked

    bool pcnt_countdown;  // startup countdown

    bool pcnt_rollupped;  // counter in actual operation


    int16_t delta_fb_q;    // UAC Feedback (10.14)

    int32_t delta_hz;      // ASRC input

    

    int16_t pcnt_diff;       // raw PCNT value

    int32_t pcnt_fs;        // PCNT Hz

    int32_t fs_raw;          // raw PCNT → raw Hz

    int32_t long_err_mHz;    // long-term FB error

    float   ratio_clock;     // control loop (I2S/USB)

    float   ratio_phase;     // resampler (USB/I2S)

    float   ratio_smooth;    // ASRC internal smoothing

    

    float i2s_src_phase;      // ASRC phase (interpolator internal state)

    int i2s_src_in_idx; // interpolator input sample index


    uint64_t tick_us;   // added: log timestamp (microseconds)

    call_position_e call_position; // caller position

} log_entry_t;


What this structure really is

As the name suggests, this is simply a snapshot of the DDC control instruments.

Its purpose is to create a history of these snapshots.

It is used only for debugging, and therefore is not required in Release builds.


Why is it necessary?

Because the DDC must maintain strict real‑time behavior, even during debugging.

The developer cannot “interrupt” or “peek inside” the DDC control loop while it is running.

During debugging, the cause of instability is often known only to the gods.

So the only viable method is:

Run → record logs → analyze afterward → repeat

It’s exactly like investigating a rocket launch failure after the fact.

You cannot stop the rocket mid‑flight to check what’s going on.

You can only analyze the telemetry afterward.


ddc_log_print_detail Function

This is the actual log output formatter.

int32_t ddc_log_print_detail(ddc_control_t *ddc, int32_t start, int32_t count)

{

    if (start >= MAX_DDC_LOG)

        return 0;


    // Header

    if (start == 0) {

        ESP_LOGI(TAG,

            "DDC cfg rate=%u bits=%d ch=%d mclk_multi=%d",

            ddc->uac_quality.sample_rate,

            ddc->uac_quality.resolution_bits,

            ddc->uac_quality.channels,

            ddc->uac_quality.mclk_multi

        );

    }


    int tail = start count;

    if (tail > MAX_DDC_LOG)

        tail = MAX_DDC_LOG;


    for (int i = start; i < tail; i ) {

        log_entry_t *L = &g_ddc_log[i];


        // ---- Phase detection ----

        const char *phase =

            (!L->i2s_locked)        ? "PHASE0(I2S_INIT)" :

            (!L->pcnt_rollupped)    ? "PHASE1(PCNT_WARMUP)" :

            (!L->uac_fb_started)    ? "PHASE2(FB_WAIT_START)" :

            (!L->uac_fb_locked)     ? "PHASE3(FB_WAIT_LOCK)" :

                                      "PHASE4(LOCKED)";


        // ---- STUCK detection ----

        bool fs_stuck     = (L->fs_raw == ddc->uac_quality.sample_rate);

        bool pcntfs_stuck = (L->pcnt_fs == ddc->uac_quality.sample_rate);

        bool dhz_stuck    = (L->delta_hz == 0);

        bool dfb_stuck    = (L->delta_fb_q == 0);


        ESP_LOGI(TAG,

            "idx=%d tick=%u part=%d %s\n"

            "  I2S: init=%d lock=%d\n"

            "  PCNT: warm=%d up=%d diff=%d fs_raw=%ld%s fs=%d%s dhz=%ld%s\n"

            "  FB: start=%d lock=%d dfb=%d%s long=%ld ratio clock=%.6f\n"

            "  SRC: ratio phase=%.6f smooth=%.6f",

            i,

            (uint32_t)(L->tick_us & 0xFFFFFFFF),

            L->call_position,

            phase,


            // I2S

            L->i2s_inited,

            L->i2s_locked,


            // PCNT

            L->pcnt_countdown,

            L->pcnt_rollupped,

            L->pcnt_diff,

            L->fs_raw,     fs_stuck     ? " (STUCK)" : "",

            L->pcnt_fs,    pcntfs_stuck ? " (STUCK)" : "",

            L->delta_hz,   dhz_stuck    ? " (NO-MOVE)" : "",


            // FB

            L->uac_fb_started,

            L->uac_fb_locked,

            L->delta_fb_q, dfb_stuck ? " (NO-MOVE)" : "",

            L->long_err_mHz,

            L->ratio_clock,


            // SRC

            L->ratio_clock,

            L->ratio_smooth

        );

    }

    return tail - start;

}


What you can see from this

You can clearly trace the transitions from PHASE0 to PHASE4.

At this point, you begin to grasp that the DDC control system is truly acting as a mission control center, and you can observe its internal state with remarkable clarity.


CCC Structure Summary

To summarize:

  • - audio_quality_t → nominal configuration
  • - clock_counter_t → real clock observation & compensation
  • - ddc_control_t → central state & control core
  • - log_entry_t → flight recorder (black box)

This is the division of roles.


Entering Real CCC Control

With all of these components in place, the CCC can finally perform practical mission control.

What matters most is the organized, actionable information produced by these structures:

  • - Phase
  • - Current Sample Rate
  • - Plateau Position (Stuck point)
  • - Water Level (Ring buffer level)
  • - SRC Rating (ASRC activity rate)

Once you can read and interpret these, you can evaluate how well the CCC is performing its mission.

And when these values align with their ideal states,

PopoDAC is in full control of time.


Next Time

In the next chapter,

you will finally witness how the heart of PopoDAC actually moves.

The moment you see it,

your understanding of digital audio will be completely rewritten.

You will understand how PopoDAC becomes a “Manipulator of Time.”

Stay tuned.