CC8520: Receiver interrupts I2S clocks when transmitter is powered on

Markus,

Your issue sounds similar to the issue here: https://e2e.ti.com/support/wireless-connectivity/other-wireless-group/other-wireless/f/other-wireless-technologies-forum/702978/cc8520-pop-click-from-receiver-audio-output-when-power-to-transmitter-is-removed 

Can you give some details about your power on and off sequence?

Also, please refer to the section titled "Volume Control in State Transitions" in the "Audio Device Definition Files" section of the PPW Configurator help for some more troubleshooting tips: 

Regards,

Daniel

Thanks, but the issue has nothing to do with power transitions or states. The receiver does not change the power state at all, but still interrupts the I2S clocks when the transmitter repowers. Only the transmitter changes power, but the receiver creates the pop noise due to the interrupted clocks. That´s also why I cannot do anything (like muting the output) by configuring power transitions in the receiver, because the pop noise also happens when the receiver does not change power state at all.
Hope this clarifies.

In other words: Receiver is left in ALONE state, when Transmitter is switched off. When Transmitter repowers and reconnects to Receiver, Receiver interrupts its I2S clocks, which it shouldn´t.

Sample rates are not changed, Transmitter is fixed at 48kHz sample rate as default value.

Actually, there was a fix/feature introduced in FW 1.3.0: "Continuous audio clock generation at protocol slaves to be able to drive external circuitry while not connected to a network". I am using 1.4.2, so either something is broken here or the implementation in 1.3.0 was not clean during reconnect?

Markus,

I'm not able to recreate this issue on my end using the CC85XXDK EVM. I can reset and toggle power to the transmitter, and the receiver MCLK continues without interruption.

From the datasheet:

Protocol slaves will generate audio clock from power-up to power-down except during short periods when switching sample rate.

Is it possible that the receiver is somehow trying to change sampling rate when the master re-joins?

Can you verify you have the FW version of your device using PPW Commander? (Device Manager > "Get Chip Info")

Then, can you share your system configuration and driver for your DAC?

I linked to the other e2e thread in my previous post because of the note in the last comment that the PPW device mutes the last 32 samples when the Master device is lost to avoid pops. 

Regards,

Daniel

Daniel,

thanks for your response. Attached are the FW version information, the receiver configuration and the .ppwadd model.

I have excluded sample rate switching as much as I could, i.e. the transmitter sample rate is default 48kHz and never changed, also I reduced in a test both receiver and transmitter .ppwadd models to just this one sample rate so there is no other choice, but it made no difference. However, I can of course not be sure what the firmware does in ALONE state. 

One more note to the configuration files: Ignore the mute pin of the CC8520, it´s being used for something else. However, I have verified the mute pin of the PCM1754 and it does not mute the pop noise generated by the missing MCLK clock, so unfortunately not an option.

The muting of 32 samples when the connection is lost is not a problem, as long as the clock continues to run uninterrupted.

6116.Receiver.zip

Found one thing in the receiver configuration file:

<name>Audio Streaming Master Static</name>
<attr>
<name>Default sample rate</name>
<value>44100</value>
</attr>

I tried changing this to 48000, but no effect. It´s probably only used for a transmitter.

Markus,

Thanks for testing out the different sample rates. 

I don't see anything out of the ordinary with your receiver + DAC setup that would cause the clock to stop. I did some more tests on my EVM and I'm still not able to create what you are observing. 

Can you also share your Master configuration and hardware setup?

Regards,

Daniel

Markus,

I'm glad you figured out the issue! I agree that this behavior isn't what I would expect to happen, but I guess the master configuration is overriding the default behavior.

Regards,

Daniel

I don´t know exactly what you mean by overriding the default behavior. The receiver should - according to the documentation - only interrupt the I2S clocks for a short period of time when there is a sample rate change. However, there is no sample rate change, no matter how much delay I configure in the "OFF to SR-SWITCH" of the transmitter.
It would be probably good to at least document this behavior, so others don´t fall into the same trap.