TAS2563: Plop when audio playback stops

Hi Ivan,

Can you also share the initialization script and the PPC3 file you used to generate the configuration files?
I'll review the reg dump for now and see if there's any clue regarding boost configuration.

What is the voltage level used for PPVBUS?
If you reduce this voltage, does it affect the "plop" loudness?

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan to you too,

Here is our current PPC3 file.

DVT 4-22-25.zip

PPVBUS voltage is 9V. 

The "plop" sound doesn't decrease amplitude if the voltage of PPVBUS is lower (5V).

Do you have any next steps in mind?

Hi Ivan,

I'll try to replicate the behavior using EVM, your described power connections and the provided PPC3 configuration file.
I'll have further comments by second half of this week.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

Is there any update in this issue? Have you been able to replicate it?

Best,

Hi Ivan,

I was not able to replicate the problem. Do you have an EVM and have you got the same effect when using the EVM for testing?

If this only occurs in your custom system, perhaps what happens is that input clocks (SBCLK and FSYNC) are suddenly stopping during playback stop. The clocks should be present whenever the device is Active through register 0x02. This would not explain the sound during mute command though.

One important thing I noticed in your PPC3 file is that the boost controller was set to Always On, but it must be set to Always Off. The Boost ON/OFF control is still Off, so that's OK, but the boost controller should still be set to Always Off.

You can try increasing the volume ramp rate, although this would help during mute and SW shutdown sequence, don't think this would affect the playback stop sequence.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan, 

Current Findings:

I have been doing some trial and error with the parameters you're describing on our device. So far, I haven't seen any impact.

Setting the Boost to Always Off had no effect either.

I ran another test with interesting results: I've played a "silence" audio file in the background. While it was playing, I ran all procedures that normally trigger the undesired sound, and there were no signs of the issue. Afterwards, I stopped the silent playback and ran the procedures once again, in all cases I've heard the sound.

This suggests a problem in the output stage. Would you agree with that?

About the troubleshooting:

From what I understand, your suggestions are meant to enforce best practices and rule out confounding factors, not because we already have a clear root cause. Is that correct?

From the schematic, do you see anything that could be causing this issue? If yes, is there a way to improve it?

EVM Test:

The EVM is not in my hands. I will request a team member to execute this test. Is there anything specific you'd like us to try or watch for?

We are close to production, and since this issue has a mid-to-high impact, we're ready to do whatever we can to resolve it. Please let us know what are the next steps.

Hi Ivan,

You're correct that root cause is not identified yet. This is a debugging process and there are several things could be the root cause; we're trying out what could be related to the problem.

Based off your test results, I still think the issue could be related to the sequence followed by the host during playback start and stop. As I mentioned you should check that SBCLK and FSYNC are running still running before sending the command for SW shutdown when audio stops.
On EVM the clocks are always running, so I don't think you'll be able to replicate the problem (as I couldn't either). Playing the silence audio file in the background would make the host to keep the clocks running while the silence is playing, making it more similar to EVM functionality.

I think you should analyze the sequence your system follows when audio stops.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

I have continued experimenting with the device, and I've designed a test to check whether the root cause is an early interruption of clock or sync signal. While audio was playing, I attempted to set registers on the amplifier through the driver's sysfs interface, and once again I heard the undesired "plop". This suggests the problem lies elsewhere.

Here are the details of my procedure for you to double check.

1. Check PWR_CTL. Value: 0x0C -> Mode bits: 00
2. Set Mute by writing 0x0D to PWR_CTL-> Noise is audible when switching from Active to Mute.
3. Write 0x0C again, playback resumes.
4. Set Software Shutdown by writing 0x0E to PWR_CTL -> Noise audible again.

Notably, the issue does not always reproduce; it occurs in roughly 60% of cases.

An interesting finding is that when I set the AMP_LEVEL field of PB_CFG1 to 0, the "plop" becomes noticeably subtler.

What would you recommend as the next steps? Can you help us rule-out a hardware-related root cause?

Hi Ivan

I'll analyze your latest updates and get back to you in a couple more days.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

We were testing our application and observed a new behavior. Could you confirm whether it is related to the issue we've been discussing?

Procedure:

1. Play an audio track
2. Raise the digital volume to maximum while keeping the amplifier gain at 16.0dBV.
3. Wait for 5 seconds.
4. Reduce the digital volume to 0.
5. Listen closely near the speaker to check if a ~60Hz hum is present.

Additional observation:

The behavior also occurs when the device is powered from a laptop with no other cables attached.

hi Vidal

as our team is on US holiday this monday.

we will reply you asap after getting back to office.

thanks

jesse

Hi Jesse,

Thanks for the update, understood.

We are launching MP this week. Smooth audio playback is the last milestone on our side. We'd appreciate your team's support in prioritizing this issue so we can resolve it together in time.

Hi Ivan,

The 60Hz you mentioned is the pilot tone used for the real-time speaker IV sensing. Perhaps your speaker is still particularly sensitive to this frequency, and the pilot tone on/off sequence is causing the sound.

Have you characterized your speaker? Are you using the speaker protection feature?
If not, we can try disabling the pilot tone altogether and check if that helps getting rid of the unwanted sound.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

Yes, the speaker has been characterized. The amp has 4 speaker protection features, are you referring to any of them in particular?

As far as I know, none of them is currently active. If you believe disabling them might influence the pilot tone or the "plop" noise, I'm willing to test that. Could you share the procedure?

We can also try disabling the pilot tone as you suggest, please provide the necessary steps.

Thanks

Hi Ivan,

By speaker protection I mean the "Smart Amp" block within "Tuning and Audio Processing".

Attached are a couple options to try, one is pilot tone frequency reduced to 16Hz from original 60Hz, and the second one is using feed-forward mode (conservative speaker protection mode) and disabling the pilot tone completely.

DVT 4-22-25__TI090325.zip

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

Both configurations resolve the humming noise, but the original issue persists.

Can you share your thoughts on the speaker protection features? Do you see a solution that avoids disabling them?

What additional tests or information would be most useful to help analyze the plop artifact? 

Best

Hi Ivan,

If the feedforward mode didn't solve the original issue, I don't think it's worth disabling the protection.

At this point the thing that still puzzles me is that you don't get the plop sound if you play silence continuously in the background.

You can try toggling either the Spread Spectrum to be OFF or Sync mode to be ON. This helped with some noise issues in the past when using external PVDD mode (boost OFF). Although your problem doesn't seem to be the same.

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

I cleared BST_SYNC in BOOST_CFG2 and AMP_SS in MISC_CFG1, the artifact persists.

Is this sufficient for your test plan? Also, which tool are those screenshots from?

If my procedure is correct, what would you recommend I should try next?

Best

Hi Ivan,

In my previous message I missed requesting instructions on how to set the PT to 16Hz in the upcoming DSP configuration.

Could you share a that describes the necessary settings?

Thanks in advance

Hi Ivan

We start mass production next week and need to ship the MP firmware end of this week.

We appreciate your help on these urgent items:

• Plop artifact: next steps + resolution estimate
• PT: instructions to set 16Hz after DSP register changes

Thank you for the continued support with these urgent items.

Hi Ivan,

My reply from 7 days ago has the PPC3 file with the 16Hz pilot tone included, can you use that to make any changes you need?
Unfortunately, this setting is hidden and the manipulation has to be made within TI. If you have a new PPC3 file where you want to change the pilot tone frequency you can send it to me and I'll change it.

Can you double confirm the feedforward configuration without pilot tone I shared did not solve the plop sound issue?

Best regards,
-Ivan Salazar
Applications Engineer

Hi Ivan,

Clear about the pilot tone settings.

I confirm the feed-forward configuration didn’t solve the plop issue. I’m attaching an audio file for reference, where you can hear the artifacts each time playback stops.

Is there anything else I can provide or test to help you?

Best,

Hi,

Ivan is out today on work related travel. He will respond to your inquiry ASAP. Thanks for your patience! 

Regards,
Sydney Northcutt