When we look at a compass or a map, we divide our world into four distinct directions. If North and South sit on the vertical axis, East and West make up the horizontal—the side-to-side axis defining sunrise and sunset, longitude, or the starboard and port sides of a ship.

Because we are so used to this four-point system, it is natural to look at a magnet and wonder: if there is a North and a South pole, where are the East and West? The answer lies in understanding that magnetism is not a grid; it is an active, continuous circuit.

The Nature of the Dipole
Magnets do not have East or West poles. They are strictly what physicists call “dipoles,” meaning they have exactly two opposite ends.

These poles earned their names from the Earth itself, which is a giant magnet. If a bar magnet is suspended freely, one end will naturally orient itself toward the Earth’s geographic North Pole. Hundreds of years ago, navigators called this the “North-seeking pole,” eventually shortening it to just “North,” leaving the opposite end as “South.”

The “Send and Return” System
Instead of a static force, a magnetic field is best understood as a closed loop—a continuous “send and a return” circuit.

The Send (North): The magnetic field lines act as an emitter, pushing the magnetic force out into the surrounding space from the North pole.

The Return (South): After curving through the air, those invisible lines act as a receiver, pulling the force back into the magnet at the South pole.

The Internal Loop: The circuit doesn’t stop at the surface. The magnetic field travels back through the inside of the magnet from South to North, completing the loop exactly like a plumbing system pumping water back to its source.

The Myth of the “Null” Sides
Since all the intense pushing and pulling happens at the poles, it is easy to assume the sides of a magnet (the “East” and “West” zones) are simply dead zones, or “nulls.”

While the magnetic pull is overwhelmingly strongest at the poles where the invisible lines are tightly bunched, the sides are not null. To get from the North “send” to the South “return,” the magnetic field takes the scenic route, curving and looping around the outside of the metal. Because the force is constantly flowing past and through these sides, a weak but active magnetic field still exists there—enough to hold onto a small paperclip.

The Hidden Engine: Synchronized Spin
What actually powers this invisible “send and return” system? The answer is spin.

Inside the metal, atoms are packed with tiny particles called electrons, and these electrons are constantly spinning. In a normal piece of iron, this microscopic activity is chaotic. Some electrons spin clockwise, while others spin anti-clockwise. Because they are working against each other, their forces cancel out, resulting in a magnetically “null” piece of metal.

A magnet is created when order is forced onto this chaos. In a magnetized piece of metal, the atoms are aligned so that the vast majority of their electrons are spinning in the exact same direction. When all of those microscopic clockwise (or anti-clockwise) spins are synchronized, their tiny individual forces combine into one massive, unified magnetic force.

The North and South poles we interact with are simply the two ends of that highly synchronized, spinning microscopic army.

The Ground Zero of UX: Why ‘Undo’ is the Ultimate Stage Gate for Good Software

It is a familiar corporate ritual: the procurement of a new, mission-critical software system. There are steering committees, endless evaluations, competitive bidding, feature matrices, vendor presentations, rigorous testing phases, and finally, deployment accompanied by copious amounts of training.

Yet, for all the red tape and administrative hoops, the most sophisticated enterprise evaluations can completely overlook the most vital feature of all.

Working for a large corporate broadcaster in Canada, I witnessed this firsthand. We had just gone through this exact, agonizing process to purchase a mission-critical “smart” PDF sheet viewer. It had checked every box the committees could think of. But no one at any point in the entire process realized it was missing one thing: the Undo command.

The Four-Hour Epiphany

You don’t realize a software lacks a safety net until you are already falling. For me, that moment came after four straight hours of meticulous markup work. I made a mistake—a routine, everyday slip of the mouse—and instinctively reached for Ctrl + Z.

Nothing happened.

After frantically clicking through menus trying to revert my changes, the grim reality set in. The work was gone. The software and I instantly became mortal enemies. It didn’t matter how “smart” the sheet viewer claimed to be; a program that does not forgive human error is fundamentally hostile to the user.

The Ultimate Litmus Test for UX

That single, agonizing experience fundamentally changed how I evaluate technology. From that day forward, “Undo” became my number one criteria when writing Requests for Proposals (RFPs) and Requests for Information (RFIs).

It sat right at the top of the mandatory requirements, shoulder-to-shoulder with the holy trinity of clipboard commands: Ctrl + C, Ctrl + V, and Ctrl + X. If a vendor couldn’t provide these basic functions, they were instantly disqualified.

Undo wasn’t just a feature request; it became my stage gate. It was the ultimate filter to eliminate software that would inevitably deliver a terrible user experience. If developers didn’t care enough to let users fix their mistakes, you could guarantee the rest of the application was riddled with similar anti-patterns and user-hostile design choices.

Ground Zero for Software Makers

Now, as someone who builds software, I have no excuses. The lessons learned from that disastrous PDF viewer dictate my entire development philosophy.

“Undo” is effectively the ground zero of all that I do. It is not a feature you bolt on at the end of a sprint, and it is not an afterthought you add to the backlog. It is the architectural bedrock of the application. Designing a system that remembers state and allows a user to step backward requires fundamental, structural planning from day one.

Good software starts with empathy for the user, and nothing says “I respect your time and your humanity” quite like a robust Undo function.

Looking back, the realization is incredibly clear: that “sheet that was smart” wasn’t actually smart at all. True software intelligence isn’t just about complex algorithms or flashy features; it’s about anticipating human behavior, accommodating our inevitable mistakes, and giving us the power to seamlessly make things right.

The Fall of Unified Operations

In the era of baseband video and SDI (Serial Digital Interface), operations were unified by the laws of physics and strict hardware standards. A Grass Valley switcher, a Sony camera, and a Chyron graphics engine all spoke the exact same physical language. You plugged in a BNC cable, and it worked. The operation was cohesive because the infrastructure forced it to be.

As broadcasting transitioned to IP, cloud playout, and software-defined infrastructure, that unity shattered. The hardware standards were replaced by software ecosystems, and every vendor decided their platform should be the brain of the facility.

The “Million Vendor” Trap

In a modern, fragmented broadcast facility, vendor ego creates absolute chaos:

The Finger-Pointing Protocol: When a stream drops or frames tear in a multi-vendor IP facility, Vendor A blames Vendor B’s packet pacing, Vendor B blames Vendor C’s network switch, and Vendor C blames Vendor A’s API.

Proprietary Walled Gardens: Instead of adhering to pure open standards, broadcast vendors often take a standard (like ST 2110 or NDI) and wrap it in proprietary control layers or licensing models. They want to trap you in their orchestration software.

The Integration Tax: Broadcast engineers now spend more time writing custom middleware to force competing APIs to talk to each other than they do actually producing television.

The “No Vendor” Reality

Your conclusion—that the solution isn’t a million vendors working together, but no vendor—is exactly where the bleeding edge of broadcast engineering is heading.

“No vendor” doesn’t mean building cameras from scratch; it means entirely stripping vendors of their architectural authority. It looks like this:

Commodity IT Hardware (COTS): Moving away from proprietary “black box” broadcast gear and routing everything through standard Arista or Cisco enterprise switches and generic compute servers.

Open Source & Microservices: Leveraging open-source media frameworks (like FFmpeg or GStreamer) and containerized microservices instead of monolithic broadcast software suites.

In-House Orchestration: The facility owns the logic. Instead of buying a master control system from a massive broadcast corporation, the internal engineering team writes the API calls and user interfaces that control the raw hardware.

By eliminating the traditional “broadcast vendor” as the middleman dictating the workflow, operations can finally become unified again under the facility’s own terms.

As a third-generation engineer, I view the “shop” as more than a workspace; it is my laboratory for the human psyche. Whether I am performing “open-heart surgery” on a national intercom network, refactoring a proprietary database tool, or restoring legacy broadcast hardware, I know that my success relies on more than technical proficiency—it stems from my self-efficacy.

As Albert Bandura established, self-efficacy is my belief in my own capability to organize and execute the actions required to manage any situation. In my world of broadcast infrastructure and technical restoration, this belief is what separates a system that fails under pressure from one that stands the test of time.

My Psychology as a “Maker-Fixer”
I don’t hesitate when faced with a 700-port expansion or a complex ST 2110 migration because I draw from the Four Sources of Efficacy, tailored to my technical craft:

Mastery Experiences: My 25-year track record of successful multimillion-dollar deliveries is my most powerful driver. Every time I commission a new IP-based audio core or automate a wiring schematic, I am “banking” psychological evidence of my competence.

Vicarious Experiences: My self-efficacy is rooted in my lineage. As a third-generation engineer, I carry a legacy of problem-solvers. This foundation makes complex challenges feel like my natural domain rather than a threat.

Social Persuasion: When international standards bodies like the AES or AMWA validate my expertise, they reinforce my internal “I can” narrative. This professional feedback gives me the resilience to face “one-in-a-million” errors that might stop a novice in their tracks.

Physiological States: When my heart rate climbs during a “live” migration, I interpret that stress as focus and readiness rather than fear. I’ve learned to view these “butterflies” as my own system powering up for a critical task.

Cross-Domain Application: From Code to Carbon Steel
I’ve found that self-efficacy is a transferable meta-skill. It manifests differently across my disciplines, but it always stems from the same core belief:

In Software Tooling: I’ve shifted from being a “user” to a “maker.” I build my own tools because I believe I can improve the very environment I work in.

In Machining and Restoration: I see through the rust to the logic of the original design. I don’t see a broken, obsolete part as “dead”—I see a component waiting for the correct sequence of operations to be revived.

In Home Repair: I approach a house as a series of interconnected subsystems—HVAC, electrical, plumbing—much like a broadcast facility’s signal flow. Because I have mastered complex IP networks, a residential circuit feels entirely manageable.

What Drives Me: The “Internal Architect”
From my work with Ward-Beck legacy support to leading-edge SMPTE 2110 deployments, I am driven by The Complexity Reward. I am rarely satisfied by “easy wins”; I seek out the Zero-Failure Requirement of national broadcasting. Succeeding where failure is not an option provides a cognitive reward that simpler tasks cannot replicate.

Ultimately, I am an Industrial Steward. By maintaining legacy archives while pushing for new IP standards, I ensure that the wisdom of the past and the technology of the future remain compatible. In software, machining, and restoration, I am doing more than just fixing things; I am validating my own agency. Every time I diagnose a complex RF issue or restore a vintage console, I reaffirm a core truth: there is no system so complex that I cannot understand it, and no break so deep that I cannot mend it.

20 Tips for Great Database Creation and Best Schema Practices

1. Normalize for integrity, but denormalize for performance. Start by structuring your database in 3rd Normal Form to reduce redundancy, but introduce denormalization selectively if specific joins are proven bottlenecks.
2. Every table must have a Primary Key. This is a strict requirement, as it acts as the unique identifier for a row, allows you to reliably update or delete records, and helps the database engine organize data efficiently.
3. Use surrogate keys over natural keys. Natural keys (like a Social Security Number or email) can change, forcing you to update every related foreign key. Surrogate keys (like UUIDs or auto-incrementing IDs) are immutable and safer.
4. Use NOT NULL by default. Allowing NULLs introduces complex “three-valued logic.” Forcing columns to be NOT NULL ensures data quality at the point of entry and simplifies application logic.
5. Enforce proper data types. Never store dates or numbers as strings. Proper data types allow the database to validate information, compress storage, and let you utilize built-in functions.
6. Standardize your naming conventions. Pick a consistent format (like snake_case), choose either singular or plural for your table names (e.g., user vs. users), and never mix them.
7. Always use Foreign Keys. Foreign keys are the only way to guarantee that a parent record actually exists before creating a related child record, which prevents orphaned data from breaking your application.
8. Maintain a “Single Source of Truth.” Do not store calculated values (such as a total price derived from quantity * price) directly in a table unless extreme performance requires it, to avoid the risk of values falling out of sync.
9. Include created_at and updated_at timestamps. Without these audit columns, you cannot properly troubleshoot data corruption or sync effectively to external analytics tools.
10. Version your schema. Never run manual ALTER TABLE commands in production. Track every change using migration tools (like Flyway or Liquibase) and version control.
11. Isolate Personally Identifiable Information (PII). Store sensitive data like passwords and addresses in heavily restricted, separate tables to apply stricter access controls.
12. Use Check Constraints. Constraints like CHECK (price > 0) act as a final line of defense against application bugs, ensuring your data remains logically sound.
13. Design for the “Delete.” Clearly define what should happen when a parent record is removed using ON DELETE CASCADE (to remove children) or SET NULL (to keep them), preventing database errors and garbage data.
14. Index your Foreign Keys. Most databases do not index foreign keys automatically. Since almost every join uses a foreign key, failing to index them is a massive cause of slow performance.
15. Utilize Partial Indexes. If you frequently query a specific subset of data (like WHERE status = 'active'), create a partial index to keep it tiny and incredibly fast compared to indexing the entire table.
16. Prefer BIGINT over INT. A standard INT caps out at around 2.1 billion rows. For high-traffic tables, use BIGINT from the start to avoid catastrophic system failures when the database runs out of IDs.
17. Use schemas and namespaces. Keep your database organized by grouping related tables into schemas (like billing, audit, and public) rather than dumping hundreds of tables into one space.
18. Document your columns. Add comments directly to the database columns (e.g., COMMENT ON COLUMN) so that the “living documentation” stays intimately tied to the data itself.
19. Use BOOLEAN instead of INT(1). Using proper true/false boolean flags is far more semantic and prevents invalid integers (like “99”) from entering a binary field.
20. Design in three tiers. Create a conceptual data model for business scope, a logical data model for detailed attributes without technical compromise, and a physical data model tailored to your specific database software.

10 Things People Constantly Do Wrong

1. Creating “The God Table.” Cramming 150+ columns into a single table makes the database slow to query, difficult to reason about, and implies multiple entities were improperly mashed together.
2. Using SELECT *. Fetching every single column wastes network I/O, prevents the database from using highly optimized “covering indexes,” and risks breaking the application if a massive new column is added.
3. Storing files or images directly in the database. Pushing large BLOBs into relational tables makes backups massive and painfully slow. You should store the actual files in an object store (like S3) and only save the file path in the database.
4. Falling for the “N+1 Query Problem.” Fetching a list of 100 records and then looping through your application to run 100 separate queries for their related data is a top application killer. You should use a JOIN to fetch it all in one network trip.
5. Overusing “Soft Deletes.” Adding an is_deleted column to everything breaks unique constraints and forces developers to clutter every single future query with WHERE is_deleted = false.
6. Performing math inside WHERE clauses. Wrapping an indexed column in a function or calculation (e.g., WHERE YEAR(date) = 2023) completely blinds the database to the index. Keep the column “naked” on one side of the operator.
7. Abusing EAV (Entity-Attribute-Value) patterns. Storing your schema as rows of attributes and values might seem infinitely flexible, but it makes even basic queries require dozens of joins, turning data retrieval into a nightmare.
8. Never testing backups. Believing you have a backup strategy when you have never successfully practiced a “Point-in-Time Recovery” (PITR). A backup is useless until you prove you can restore it.
9. Sorting with ORDER BY RAND(). This command forces the database to assign a random number to every single row, sort the entire massive table, and then pick one, acting as a massive performance bottleneck.
10. Using the database as a Message Queue. Treating a relational table as a high-volume “to-do list” for background jobs causes massive bloat and lock contention. Dedicated tools like RabbitMQ or Kafka should be used instead.

In the corporate world, a quiet epidemic often goes unnoticed by senior leadership: The Slippery “I” Disease. This occurs when managers or directors systematically replace “we” with “I” when presenting successes, effectively sliding into the spotlight on the back of their team’s hard work. It is a subtle form of professional erasure that can demoralize high performers and stall careers.

Recognizing the Symptoms

The disease manifests through “linguistic slippage.” During a high-stakes meeting, a manager might say, “I developed this strategy,” when they actually only approved a slide deck created by their subordinates. This behavior isn’t always malicious; often, it is a survival mechanism used by middle management to appear indispensable to executives. However, the result is the same: the true architects of the work become invisible.

How to Combat the “Slippery I”

To protect your career and ensure your contributions are recognized, consider these three tactical shifts:

1. The “Pre-Emptive Paper Trail”

The best way to combat credit theft is to make your ownership undeniable before the final presentation.

* The Progress Update: Send regular, high-level email updates to your manager and CC relevant stakeholders.

* The Metadata Defense: Ensure your name is on the “Properties” of every document and the “Version History” of every shared file.

2. The “Technical Pivot” in Real-Time

If you are present when a manager takes credit, don’t stay silent. Use a technical follow-up to reclaim the floor.

* The Tactic: Wait for them to finish, then add: “To expand on the point I built into that specific model, the reason I chose that data set was…”

* The Result: This demonstrates that while the manager may have “presented” the idea, you are the one who actually understands the mechanics behind it.

Strategic Visibility

Don’t rely on your manager to be your only spokesperson. Cultivate “sideways” relationships with peers in other departments and “upward” visibility by participating in cross-functional committees. When more people know what you are working on, it becomes much harder for a single director to claim your output as their own.

The “We” Culture

Ultimately, leadership is about multiplication, not subtraction. Healthy organizations reward leaders who say, “I am proud of what my team achieved,” because it shows they can build talent. If you find yourself in a culture where the “Slippery I” is the norm, it may be a sign of a deeper systemic issue regarding how performance is measured.

The promise of the decoupled architecture—the “Open Air” philosophy—is an engineer’s dream. You separate the physical control surface from the processing engine, granting yourself the ultimate agility. A fader isn’t just a volume slider anymore; it’s a universal, assignable control vector.

But as you start wiring the system together, Anthony, a dark reality quickly rears its head. You push the motorized fader up. The software volume goes up. Then, the fader violently twitches, fights your finger, and shoots back down, sending the software volume spiraling into a chaotic blur before crashing the network with a flood of packets.

You haven’t just built a control system. You’ve built an infinite feedback loop.

Here is the story of the hardest obstacles in decoupling hardware from software, and the technical gauntlet the Splinker must run to maintain order.

Obstacle 1: The “Ghost Touch” and the Infinite Echo

The Analogy: Imagine two people standing in an infinitely reflective hall of mirrors, trying to communicate with walkie-talkies that have their buttons permanently taped down. Every word one person says is immediately echoed back by the walls, and that echo is picked up by the other radio, which transmits it back again.

The Technical Reality: In a bi-directional system, devices are incredibly literal.

1. The human finger moves a motorized fader to 0.7.

2. The fader’s sensor detects this and fires an MQTT message: SET VOLUME 0.7.

3. The software engine receives it, updates its internal state, and faithfully broadcasts the new state to the network: VOLUME IS NOW 0.7.

4. The physical fader receives this state update. Its motor physically drives the fader to the 0.7 position.

5. The Fatal Flaw: The fader’s sensor feels the motor moving it, assumes a human just pushed it, and fires a new control message: SET VOLUME 0.701.

The Overcome: This is why the origin_source and msg_guid are strictly necessary. The Splinker acts as the bouncer at the door, forcing every device to wear a nametag. When the hardware receives a state update, it must check the origin. If it sees its own ID, it applies a digital mute to its sensors: “I started this action, so I will update my motor to match the state, but I will ignore the resulting sensor twitch.”

Obstacle 2: The Physics of Meat and Metal (Inertia)

The Analogy: You are driving a massive cargo ship, but your steering wheel is connected to a laser pointer. The laser moves instantly to wherever you point it (digital software), but the ship takes five agonizing seconds to actually turn (physical motors). If you keep aggressively turning the wheel back and forth before the ship catches up, you snap the rudder.

The Technical Reality: Software updates in microseconds. Motors, gears, and belts take milliseconds or even tenths of a second to physically arrive at their destination. Furthermore, human hands are jittery. When you slide a fader, you aren’t sending one command; you are sending hundreds of granular micro-adjustments (0.61, 0.63, 0.68).

If the Splinker tries to force the motorized fader to physically track every single micro-bounce of a feedback loop while the human is still holding it, the motor will burn out or the fader will aggressively stutter against the user’s finger.

The Overcome: This requires a sophisticated Debounce and Settling protocol. The Splinker must recognize an active “Splice” stream. While a flood of commands is coming from a single source, the Splinker flags them as is_settled: false. It instructs the receiving hardware: “Do not fight the human. Let them move.” Only when the stream goes quiet for a predefined window (e.g., 50ms) does the Splinker send the is_settled: true command, signaling the physical motors to cleanly snap to their final resting position.

Obstacle 3: The Time-Warp of the Network

The Analogy: You are mailing a series of letters to a friend with instructions for a recipe. You mail Step 1 on Monday, Step 2 on Tuesday, and Step 3 on Wednesday. But because of chaos at the post office, your friend receives Step 3 on Thursday, Step 1 on Friday, and Step 2 on Saturday. If they follow them in the order they arrive, the cake explodes.

The Technical Reality: Networks are unpredictable. In an IP-based MQTT system, packets can take different routes. This causes network jitter. A user might quickly slide a fader from 0 to 10. The system generates:

• Packet A: Value 2

• Packet B: Value 7

• Packet C: Value 10

If a micro-bottleneck occurs, the software might receive them in the order: A, C, B. The volume goes to 2, jumps correctly to 10, and then disastrously jerks back down to 7, where it stays.

The Overcome: Relying on the network to sort out the echo is a losing battle. The solution requires an Interaction Lock (The “Do Not Disturb” Protocol) built directly into the hardware and UI widgets.

When a human finger touches a motorized fader, the controller engages a strict hardware-level lock (is_locked = True). While the human is touching it, the fader violently deafens itself to the network. It drops all incoming LINK_FEEDBACK messages into the void, refusing to update its visual position or fire its motor, while simultaneously blasting its own SPLICE_ACTION commands out to the software.
The infinite loop is severed because the hardware is physically incapable of reacting to its own network echo. Only when the human lets go does the lock disengage, allowing the fader to listen to the network once again.

By: Anthony Kuzub. A Confused Broadcast Engineer

I’ve spent the last twenty years in OB vans and broadcast control rooms. In my world, “latency” is a dirty word. (production offsets is what I like to call them) If a signal is one frame out of sync, we panic. If a host hears their own voice in their IFB (earpiece) with even a 10ms delay, they stop talking and start shouting at us. You can judge an in ear mix by how far they throw the beltpack.

So can you imagine my confusion when I recently stepped into the commercial AV world to help commission a high-end boardroom.

I opened a clients DSP file—a standard configuration for a room with ceiling mics and local voice lift—and I saw something that made me think I was reading the schematic wrong.

There were Acoustic Echo Cancellation (AEC) blocks on everything.

Not just on the lines going to the Zoom call (where they belong), but on the microphones being routed to the local in-room speakers. I turned to the lead AV integrator and asked a genuine question:
“Why are we running the podium mic through an echo canceller just to send it to the ceiling speakers five feet away?”
His answer was, “To stop the echo.”
And that is when my brain broke.

The Chicken, The Egg, and The Latency

In broadcast, we follow a simple rule: Signal flow follows physics.

If I am standing in an empty room and I speak, there is no electronic echo. If I turn on a microphone and send it to a speaker with zero processing, there is still no echo—there might be feedback (squealing) if I push the gain too high, but there is no distinct, slap-back echo.

So, I looked closer at the AEC block in the software.

• Processing Time: ~20ms to 50ms (depending on the buffer and tail length).
Suddenly, the math hit me. By inserting this “safety” tool into the chain, we were effectively delaying the audio by nearly two video frames before it even hit the amplifier.

Here is the loop I saw:

1. The presenter speaks.
2. The DSP holds that audio for 50ms to “process” it.
3. The audio comes out of the ceiling speakers 50ms late.
4. The microphones at the back of the room hear that delayed sound.
5. Because 50ms is well beyond the Haas Effect integration zone, the system (and the
human ear) perceives this as a distinct second arrival. A slap-back. An echo.

Creating the Problem to Fix the Problem

I realized that in this room design, the AEC wasn’t curing the echo; it was the source of it.
Because the system was generating a delayed acoustic signal, the other microphones in the room were picking up that delay. The integrator’s solution? “Oh, just put AEC on those back mics too.”
It felt like watching a doctor break a patient’s leg just so they could bill them for a cast.
In the broadcast world, we use “Mix-Minus” (or N-1). If a signal doesn’t need to go to a destination, you don’t send it. If a signal doesn’t need processing, you bypass it. You strip the signal path down to the copper.

The “Empty Room” Test

I proposed a crazy idea to the team. I asked them to imagine the room completely empty. No Zoom call. No Microsoft Teams. Just a guy standing at a podium speaking to people in chairs.
• Is there a remote caller? No.
• Is there a far-end reference signal? No.
• Is there a need to cancel anything? No

If we simply bypassed the AEC block for the local reinforcement, the latency dropped from 50ms down to about 2ms. At 2ms, the sound from the speakers arrives at the listener’s ear almost simultaneously with the actual voice of the presenter. The “echo” vanishes.

The system became stable not because we added more processing, but because we stopped fighting physics.

A Plea from the Control Room
I’m still learning the ropes of AV, and I know that VTC calls are complex. But I can’t help but feel that we are over-engineering our way into failure.
If you have to use an Echo Canceller to remove an echo that you created by using an Echo Canceller… maybe it’s time to just turn the Echo Canceller off.