Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 31 replies
  • Answers 3 answers
  • Subscribers 32 subscribers
  • Views 586 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

SRC4392: SRC4392: How does the interrupt mode: "level active" function?

SRC4392: AES RXAMLL

Ben Alexander
Prodigy 20 points
Part Number: SRC4392
Other Parts Discussed in Thread: SRC4192

Tool/software:

Hi,

We are using an  SRC4392 and trying to set the RXAMLL (Receiver Automatic Mute for Loss of Lock) bit to get the device to mute when there is a loss of lock.

However, when soing this we recieve a periodic thumping. Does anyone have any idea of why this may be? I can provide audio/digital bits if needed.

Thanks,

Ben

  • 0
    TI__Mastermind 23920 points

    Hello Ben,

    Sounds like you lose the lock periodically for a very short  period of time and thus  it triggers the mute momentarily . By itself the mute provides a pop-less  muting by forcing the SRC output data low by stepping the output attenuation from the current setting to an all-zero data output state, however if muting starts but immediately stops,  it might not be pop free.

    Are you monitoring the LOCK function ? I was wondering if you  provide a different settings for input /outputs clk,  does this issue  get worse or better? That is , are you working in Slave or Master mode and can you try with a different setting?

    Regards

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 20 points

    Hi Arash,

    No this happens when we pull the XLR from the input, and we monitor that the lock is lost during this time.

    It seems to send out about a buffer of ~640us of whatever was sent over AES before the lock was lost. This seems to repeat once every ~700ms with the same buffered information. For example, I can send 7kHz sine wave, and then pull the plug, and I can see that the ~650us buffered information is also 7kHz sine wave.

    I wonder if this helps to narrow down what it is?

    We can't change the clock unfortunately but I will look at master/slave mode tomorrow.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hi Ben,

    I discussed this with my colleagues as a thumping noise usually is coming from a speaker connected in the system and a DC input.  So one test that I would do is  to remove the SRC in the system and you would still hear the thumping. 

    Once you unplug the input the data inside the SRC  still needs to go through the buffer inside the device  and that probably is the 650us  of input data carried over.

    Usually  in a system, with digital input you go through a DAC or a D Amplifier to speaker, you need to find the source of thumping  but in general most of the DACs will react with a pop noise whenever there is a loss of clks or input to them.

    Regards,

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 20 points

    Hi Arash,

    Unfortunately if I leave everything else untouched and move from an AES to analogue input, the thumping is no longer present. This happens periodically and I can see there is no lock. We are getting this thumping from the AES when I monitor within the DSP chip. It could be that this spitting out of previous information periodically is in handling of the incoming audio the DSP side, but this thumping only occurs when the AES has lost lock when data was being parsed previously, not in any other manner (for example using Dante, or Analogue in or when AES is used it has lock).

    Here is an example of whats happening, I'm passing the AES through to the input of the DSP, it then bypasses all processing and then goes to the DAC (it's worth noting that I can see that this thumping happens before the DAC in the DSP code).

    Here is the output audio in a scope of when the AES has lock:

    And here is the output when the AES has lost lock with the repeating bursts of audio (left shows repeated bursts, right shows zoomed in part of these bursts):

    If you would like any more information regarding register settings, I can give these also.

    I will try and look at the master/slave today, but I am quite busy so it may be more likely it is tomorrow.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 32825 points

    Hi Ben,

    Arash is out of office today, so he will take a look at your reports and give his feedback tomorrow. If you end up with any new information please share it.

    Thanks,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 20 points

    Hi Jeff and Arash,

    Thank you. Unfortunately, we cannot change the SRC clock  to generate the CLK in master mode as this is given from another board.

    I'll let you know if I stumble across anything else.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hi Ben,

    If it is losing lock at some point, the only thing  i can think of is to either change the source of clks and re-check or as suggested before, operate in a different combination of  Master/Slave clks so you can get a better indication of the source of issue. From my past experience, this usually is the issue of clks.

    Regards,

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 20 points

    Hi Arash,

    The problem is not the SRC losing lock during operation. The problem is when we have no lock it will repeatedly parse out the previous data in the way stated before. It is only losing lock when I pull the connection (as we use XLR cables for the input, I can just remove this to get a loss of lock). When this  happens, the lines into the SRC (RX1+ and RX1-) have no information on.

    This does not happen during normal operation when a locked signal is coming into the SRC.

    As stated before, I don't think I can change the master/slave/clock source for this part. I can have a look on the scope at our input clock and verify that these clock sources are correct?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    Prodigy 20 points

    Hi Arash,

    I can confirm the input clocks are all correct.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hi Ben, 

    if it doesn't happen during normal operation and when lock is not lost , then I believe it is doing its operation. If this happens only when it loses lock, I don't think there is anything we can do. How it parses the information ( 650us of data ) after it losing the lock or XLR is unplugged and repeat itself every 700ms , datasheet doesnot tell us what to expect when XLR S/PDIF is unplugged probably needs to review the internal structure and I don't have access to be able to explain it.

    Regards,

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 20 points

    Hi Arash,

    Thank you for your help. It's not just when the XLR is unplugged, it is even when I turn off the device transmitting AES data to the input but the XLR being pulled was an example. It happens when whatever way I try and force a loss of lock.

    That's okay, is there anyone that you know of that may have access and can help me further?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 32825 points

    Hi Ben,

    Arash is out of office again for this week.

    Unfortunately the designers for this part are not at TI any longer so we cannot get meaningful insight into why this is happening. As Arash said, this is probably the device's intended functionality and the effect you're seeing is just a limitation.

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 20 points

    Hi Jeff and Arash,

    So the SRC4392 feature of muting when a loss of lock occurs has the limitation of not muting?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 32825 points

    Hi Ben,

    Sorry I didn't that was the original concern. 

    I did find this info from a previous e2e that may help:

    The only IP in the SRC4192 that will automatically mute with loss of signal is the DIR, and this is done by setting the RXMLL bit in register 0E. This will make the DIR mute itself if it loses lock on the input signal. All other mutes done in software are manual mutes that must be set by a host controller. This is why we have the LOCK, RDY, and MUTE pins. if lock is lost in the DIR, then the lock pin will change, this signal can be connected to the MUTE pin for an automatic mute all outputs, not just the DIR output.

    You might be able to use the LOCK or MUTE pins as a work around if the thumping can't be tracked down. If possible I would try other test input frequencies. I see in your plots the thumps and the intended signal are close in frequency but not the same. That may give some clue as to what's happening if the two frequencies follow each other.

    Also reading the RXMLL function again, it does not mute the preamble, P, V, U, or C bits on the AES3 line. Is it possible the DSP is mishandling these other bits when the lock is lost?

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 20 points

    Hi Jeff,

    Yes, the DIR is all that we want to mute, so it seemed like using RXMLL would do this for us. We only want to mute the DIR when a loss of lock occurs, so if the MUTE pin (or reg 0x2D - MUTE) disables all outputs, this is not the functionality that we want.

    Setting the MUTE register gets rid of any thumping, but again, if this disables the DIT also, this is not what we would like.

    The two frequencies are the same and follow when changing the input frequency, it is just the scope's output frequency that is slightly off in the burst picture, I have confirmed this.

    I'm unsure what you mean by the preamble bits? Does the SRC not convert AES to digital audio over serial?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 32825 points

    Hi Ben,

    Sorry, I'm not as a familiar with these parts. You're measuring the I2S data after being converted from AES right? Then disregard my comment on the status bits.

    Is the LOCK pin showing any thumping or is it consistently high?

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 20 points

    Hi Jeff,

    That's okay. Yes, I2S from AES I believe, and as that comes into the DSP, we can see/hear the thumping.

    There's no thumping on the LOCK or READY pins when this happens. I can see also that the RXCLKO when enabled is pulled low when there is a loss of lock.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 32825 points

    Hi Ben,

    If you turn off the RXAMLL bit to turn off the mute function, what happens on the output? If the whole AES input is gone I would expect no output. I would also try to see if anything changes by removing the clocks.

    I think this mute function is designed to mute the output when the clocks are faulty, not the AES input itself but I can get confirmation on that from Arash when he gets back Monday.

    Best regards,
    Jeff McPherson

  • 0 in reply to Jeff McPherson
    Prodigy 20 points

    Hi Jeff and Arash,

    Sorry for my radio silence, I wasn't in the office last week.

    If I turn off the RXAMLL bit, I get the same output.

    What do you mean by removing the clocks? And if this is only designed to mute the output when the clocks are faulty, this would make sense as to why I am getting the same output with or without this bit enabled.

    Thanks,
    Ben

  • 0 in reply to Ben Alexander
    Prodigy 20 points

    Hi Jeff and Arash,

    In the datasheet RXAMLL states: "This bit is used to set the automatic mute function for the DIR block when a loss of lock is indicated by both the AES3 dcoder and PLL2." Under what condition is this loss of lock detected, as the /LOCK pin is set low when the cable is pulled?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hi Ben

    Not providing the clks, grounding the clk are among examples of what can be considered as " removing the clk" that Jeff mentioned. My understanding is that when clks are faulty the mute function is kicked in, which explains your observation too.

    When the  REF clk to PLL  and FB clk are phase locked, the lock indicator goes high . That is when the PLL is in steady-state, it is locked.  In general it is possible for excessive jitter to cause a loss-of-lock indication, even if REF and FB are locked and no system-level error exist.

    Regards,

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 20 points

    Hi Arash,

    I'm assuming, that the clk you are talking about is not the recovered clock coming in on the AES line?

    So when the PLL is not in a steady state, is this the only indication of this loss of lock being the /LOCK pin?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hi Ben,

    Recovered clk is an output clock, he meant clks that are coming externally. For all PLL that I have seen, loss of lock is the only indication . Of course internal to PLL you can monitor some voltages to see when they reach steady state but for this case seems /LOCK pin is the only indication.

    Regards,

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 20 points

    Hi Arash,

    Sorry I think I used the wrong word for "recovered clk". What I meant by this was the loss of the encoded input clock coming in on the AES line along with the data. As the loss of this clock causes the /LOCK pin to react. I was just wondering why this clock doesn't count as a RXAMLL loss of lock condition, and therefore doesn't mute, as it has lost lock?

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hi Ben,  I would expect a loss of  clk to the PLLs  in Figure 67 would trigger /LOCK and would count toward muting. This is a matured device (20 years ) and without the actual design I can not really comment on what or why a specific clk (whether internal or external clk )  is not triggering the mute. It might be designed such a way that it mutes with faulty external clks. Unfortunately can not add any comment .

    Regards,

    Arash

  • 0 in reply to Arash Loloee
    Prodigy 110 points

    Hi, I can confirm this behaviour. There is a constant "thumb" sound, after the LOCK of any DIR input is lost.

    In my application, monitor the LOCK and the Receiver Status Registers (can either be done by I2C or by GPIO support). In case of loss of audio signal I mute the PORT that is connected to my host controller. This is the only valid work-around I found.

    Somewhere in my main IO routines:

// This routine helps to prevent unwanted noise from SPDIF inputs.
if(SRC4392AudioStreamValid())
{
	SRC4392AudioMute(0, 0);	// PortA, unmute
}
else
{
	SRC4392AudioMute(0, 1);	// PortA, mute
}
		
		
		
/*********************************************************************
 * Function:        uint8_t SRC4392AudioStreamValid(void)
 *
 * PreCondition:    None
 *
 * Input:			None
 *
 * Output:          Returns 1, in case an SPDIF signal is locked
 *
 * Side Effects:    None
 *
 * Overview:		None
 *  
 * Note:         None
 ********************************************************************/
uint8_t SRC4392AudioStreamValid(void)
{
    uint8_t ret_val = 0;
    uint8_t ReceiverStatus[2];
    // If dir is not locked, no need to check with I2C
    // In case, the IO is not available, completely reply on SW polling
    #ifndef SRC_LOCK_GetValue
        #define SRC_LOCK_GetValue 0
		if(1)
	#else
		if(SRC_LOCK_GetValue() == 0)
    #endif
		{
			// Page 0
			I2C1_Write1ByteRegister(REG_PAGE_SELECTION, 0x00);
			ReceiverStatus[0] = I2C1_Read1ByteRegister(REG_RECEIVER_IRQ_STATUS_0);
			ReceiverStatus[1] = I2C1_Read1ByteRegister(REG_RECEIVER_IRQ_STATUS_1);
			
			if(ReceiverStatus[0] & 0x03){
				// Clockrate is valid
				if((ReceiverStatus[1] & 0xF4) == 0){
					ret_val = 1;
				}
			}
		}
		return ret_val;
}

  • 0 in reply to Stefan Dreyer
    Prodigy 20 points

    Hi Stefan,

    Thanks for this code, is there any reason you are not using the /LOCK pin directly? As we do not want to poll this, and would rather have an IRQ.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    Prodigy 110 points

    Hi,

    the simple reason is that I have only I2C and the LOCK\ pin is not connected, as the host controller has very little IO's. So I build the routine in a way that I can use it in products with and without LOCK\ pin connected. Currently, every 50ms the status is requested by I2C.

    I also tried to use the RXAMLL (its set by default in my appication), but it does not work as expected and i get this weird "pfffffftttt" noise.

    Referring to your other thread, with this method you can easily determine which one of the SRC4392 has reported the LOCK error.

    e2e.ti.com/.../src4392-src4392-how-does-the-interrupt-mode-level-active-function

    FYI:

    #define REG_RECEIVER_IRQ_STATUS_0       0x13
    #define REG_RECEIVER_IRQ_STATUS_1       0x14

    /*********************************************************************
 * Function:        void SRC4392AudioMute(uint8_t port)
 *
 * PreCondition:    None
 *
 * Input:			channel
 *					0 = PORTA, 1 = PORTB, 2 = ASRC
 *
 * Output:          None
 *
 * Side Effects:    None
 *
 * Overview:		None
 *  
    * Note:         None
 ********************************************************************/
void SRC4392AudioMute(uint8_t port, uint8_t mute)
{
	uint8_t srcdata;
	switch(port)
	{
		case 0:
			srcdata = I2C1_Read1ByteRegister(REG_PORT_A_CONTROL_1);
			if(mute)
			{
				srcdata |= PORT_CONTROL_MUTE(1);
			}
			else
			{
				srcdata &= ~PORT_CONTROL_MUTE(1);
			}
			I2C1_Write1ByteRegister(REG_PORT_A_CONTROL_1, srcdata);
			break;
		case 1:
			srcdata = I2C1_Read1ByteRegister(REG_PORT_B_CONTROL_1);
			if(mute)
			{
				srcdata |= PORT_CONTROL_MUTE(1);
			}
			else
			{
				srcdata &= ~PORT_CONTROL_MUTE(1);
			}
			I2C1_Write1ByteRegister(REG_PORT_B_CONTROL_1, srcdata);		
			break;
		case 2:
			srcdata = I2C1_Read1ByteRegister(REG_SRC_CONTROL_1);
			if(mute)
			{
				srcdata |= SRC_CTRL_MUTE(1);
			}
			else
			{
				srcdata &= ~SRC_CTRL_MUTE(1);
			}
			I2C1_Write1ByteRegister(REG_SRC_CONTROL_1, srcdata);
			break;	
		default:
			break;	
	}
}

  • 0 in reply to Stefan Dreyer
    Prodigy 20 points

    Hi Stefan,

    That makes sense, thank you! We have spare IO's so may just end up doing a software AND of the /LOCK and /READY signals.

    I'm glad that it's not just us getting the weirdness coming out using RXAMLL.

    Thank you for this code, and your help.

    Thanks,

    Ben

  • 0 in reply to Ben Alexander
    TI__Mastermind 23920 points

    Hello Ben,

    Seems the  work around that Stefan suggested solves your issue I close the thread, Thanks.

    Regards,

    Arash