A debate rages in automotive audio — and it all started with a seemingly insignificant chip. For years, the CS2000 reigned supreme as the industry-standard phase-locked loop (PLL) chip. This tiny eight-pin part underpinned countless applications across industries for precise clocking, including audio product design and in-car systems, efficiently creating the heartbeat that kept our infotainment systems in perfect rhythm.
But as with all technology, change was inevitable. The manufacturing line that produced the CS2000 became obsolete, setting off a chain reaction that positioned audio engineers at a crossroads: stick with the familiar or embrace the new ZL30253 — a more complex chip that could sync with a frame sync signal, not just a simple bit clock.
But this powerful new part presented new challenges to audio engineers and software development teams. Building on our introduction to PLLs and their evolving role in wireless technology systems, we now venture into how a simple change in clock signals has raised concerns in an age when cars are increasingly connected to the internet — and software’s crucial role in managing system complexity.
Contents
gPTP and PLL Interaction: Driving Precision Timing
Modern automotive software systems must look good to the eyes and sound pleasing to the ears. Consequently, these systems depend on software to manage the intricate relationship between gPTP and PLL to eliminate buffer overflow or underflow.
Part one of this series covered what a PLL is, how they work and typical applications, whereas gPTP is an enhanced version of PTP, the precision time protocol. gPTP can handle larger network topologies by introducing hierarchical clock domains, allowing for efficient synchronization across multiple levels of the network hierarchy. gPTP also incorporates advanced fault tolerance mechanisms to ensure robust synchronization even during network disruptions or device failures.
The PLL generates a signal that drives the entire audio processing chain, but the gPTP ensures that the frame remains perfectly synchronized with the incoming audio data to keep buffers appropriately filled. The head unit sends audio data packets over the vehicle’s communication bus (e.g., A2B digital audio bus, ethernet bus, etc.), each stamped with precise timing information. The amplifier’s system compares these timestamps with its local clock, driven by the PLL. Based on this comparison, the system makes minute adjustments to the PLL’s frequency, speeding it up or slowing it down as needed.
These adjustments are far from trivial and require sophisticated software to interpret the gPTP data, calculate the necessary corrections and apply them to the PLL without disrupting ongoing audio processing. Within this continuous feedback loop, the amplifier also sends its gPTP signals back to the head unit, ensuring both ends of the system remain tightly synchronized.
The challenge is that the new chip is significantly more complex, picking up that frame synchronization signal at a higher level than just a regular clock pulse going up and down. Plus, it has its own built-in EEPROM that must be flashed to work successfully.
Walking the Buffer Management Tightrope
The primary goal of these minute PLL adjustments is maintaining proper buffer levels in the amplifier. The size of the audio buffers affects both the latency and the audio performance.
Generally, the smaller the buffer size, the lower the latency. However, working with small buffers can be demanding for the system.
Think of these buffers as a reservoir that needs to be kept at an optimal level. If the PLL runs too slow, the buffer could overflow, potentially causing data loss. If it runs too fast, the buffer could underflow, leading to gaps, clicks or glitches in the audio/video data.
Software helps in-vehicle systems balance this concern, constantly monitoring buffer levels, predicting potential over/underflows and adjusting the PLL accordingly. This functionality requires not just reactive measures but predictive algorithms that can anticipate changes in data flow and preemptively adjust the system.
Solving Real-World Challenges with Software Expertise
The gPTP specification — while comprehensive at 421 pages long — presents unique challenges when translating it into working code. Unlike many protocols that leave implementation details to the developer, gPTP’s specification is unusually prescriptive, almost reading like a software implementation itself. While helpful in ensuring consistency across implementations, this characteristic requires a deep understanding of the protocol and efficient software coding practices to balance adherence to the specification with optimal performance for the specific hardware platform.
PLL adjustments — although seemingly localized — have systemwide implications. A slight change in clock speed affects not just buffer management but everything from audio processing algorithms to power management systems. Software must manage these interdependencies, ensuring that adjustments made for synchronization don’t adversely impact other system components.
Cardinal Peak’s holistic approach to system design and coding and deep understanding of how various components interact help us address various engineering challenges throughout the project life cycle.
- One particular challenge we addressed in a recent project involves race conditions in gPTP data handling. When multiple processes read and write timing data asynchronously, the risk of data corruption or misinterpretation surges.
- Another challenge involved a bug causing buffer overflows and underflows over time. The root cause was a lack of proper software resource protection when writing the gPTP time-based clock signal, allowing downstream readers to access partially updated data. Our team’s solution involved implementing robust locking mechanisms. Before any process reads or writes gPTP data, it must first acquire a lock. This tactic ensures that critical operations are atomic, preventing scenarios where one process might read partially updated data.
- We encountered a third challenge when another team supplied software for an audio data delivery that our team had to integrate into the final product. The other team had elected not to solve many underflow/overflow problems within the software but instead kill the process and restart it from scratch — essentially the software equivalent of turning the device off and back on again to start it fresh. This approach created an even longer audio downtime, about 250 milliseconds. Initially, our team optimized the code to reduce the delay to about 32ms, but that’s still a perceptible sound loss. Rearchitecting the software to eliminate the restart as an error-handling mechanism wasn’t feasible within the time and cost limits of the project. Instead, we focused on getting the normal running state to behave cleanly, making a restart unnecessary.
Syncing Automotive Audio Success
The seemingly simple task of playing audio in a car demands a complex dance of precision timing, data synchronization and buffer management. As automotive systems continue to advance, software’s role in managing these intricate processes will only grow in importance.
Experienced software teams truly shine in this challenging environment, turning complex specifications into smoothly functioning systems. Our expertise in handling the intricate interplay between GPTP and PLL, managing systemwide complexity and solving real-world problems ensures the highest data quality. After all, when you turn on your car’s infotainment system, you want to hear nothing but crystal-clear, perfectly timed sound and see the highest-quality video.
Let our engineering experts know how we can help you navigate the road ahead!
If you’ve ever wondered about the security implications of peripheral devices in modern automotive systems, this post explores the risks, the debate between hardware and software teams and proven strategies for protecting these critical components. Check out part three of this series, navigating embedded memory security challenges in connected car systems.