https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1392617/src4392-aes-rxamll
器件型号:SRC4392主题中讨论的其他器件: SRC4192
工具与软件:
您好!
我们将使用 SRC4392并尝试设置 RXAMLL (锁丢失时的接收器自动静音)位、以便使器件在失锁时静音。
然而,当这种刺激,我们收到一个定期追击。 有人知道为什么会出现这种情况吗? 如果需要、我可以提供音频/数字位。
谢谢!
本
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.
https://e2e.ti.com/support/audio-group/audio/f/audio-forum/1392617/src4392-aes-rxamll
器件型号:SRC4392工具与软件:
您好!
我们将使用 SRC4392并尝试设置 RXAMLL (锁丢失时的接收器自动静音)位、以便使器件在失锁时静音。
然而,当这种刺激,我们收到一个定期追击。 有人知道为什么会出现这种情况吗? 如果需要、我可以提供音频/数字位。
谢谢!
本
Ben、您好!
听起来你周期性地失去锁很短的一 段时间,因此 它会立即触发静音。 静 音功能本身 通过将输出衰减从电流设置步进至全零数据输出状态来强制 SRC 输出数据为低电平、从而提供了 无爆音静音功能。但是、如果静音开始但立即停止、则可能无法实现无爆音。
您是否在监视锁定功能? 我想知道、如果您 为输入/输出时钟提供不同的设置、 这个问题 会变得更糟还是更好? 即、您是在"从属"模式还是"主"模式下工作、是否可以尝试使用不同的设置?
此致
Arash
尊敬的 Arash:
当我们从输入中拔出 XLR 时不会发生这种情况、并且我们会监视在这段时间内锁丢失的情况。
在锁丢失前、似乎会发送大约~640us 的缓冲器、即通过 AES 发送的任何内容。 使用相同的缓冲信息、这似乎每~700ms 重复一次。 例如、我可以发送7kHz 正弦波、然后拔下插头、可以看到~650us 缓冲信息也是7kHz 正弦波。
我想知道这是否有助于缩小它的范围?
遗憾的是、我们无法更改时钟、但明天我将查看主/从模式。
谢谢!
本
尊敬的 Ben:
我曾与同事讨论过这个问题、因为敲击噪声通常来自系统中连接的扬声器和直流输入。 因此、我 要做的一个测试是 移除系统中的 SRC、 您仍然会听到追号。
一旦您拔下输入、SRC 内部的数据 仍需要通过 器件内部的缓冲器 、而这可能是650us 的输入数据。
通常 在系统中、通过数字输入经由 DAC 或 D 放大器进入扬声器、您需要找到追击声源 、但一般来说、 只要 CLKS 丢失或输入发生、大多数 DAC 都会产生砰砰噪声。
此致、
Arash
尊敬的 Arash:
不幸的是,如果我把其他一切都保持不变,并从 AES 移动到模拟输入,追击不再存在。 这会定期发生、我可以看到没有锁定。 当我在 DSP 芯片内进行监控时、我们正从 AES 收到这个追击。 这可能是、这种定期从以前的信息中分离出来用于处理 DSP 端的输入音频、但这种追击仅在 AES 在以前解析数据时丢失锁定时发生、而不是以任何其他方式(例如使用 Dante、模拟输入或使用 AES 时、它已锁定)。
这是一个发生情况的示例、我将把 AES 传递至 DSP 的输入、它接着绕过所有处理、然后进入 DAC (值得注意的是、我可以看到这个追击发生在 DSP 代码中的 DAC 之前)。
以下是 AES 锁定时范围内的输出音频:

这里是 AES 由于重复的音频突发失去锁定时的输出(左侧显示重复的突发、右侧显示这些突发的一部分放大):


如果您想了解更多有关寄存器设置的信息、我也可以提供这些信息。
我今天会试着看看主/从,但我很忙,所以可能明天更有可能。
谢谢!
本
尊敬的 Arash:
问题不是运行期间 SRC 失去锁定。 问题是、如果没有锁定、它将按照前面所述的方式重复解析出先前的数据。 它只是失去锁当我拉连接(因为我们使用 XLR 电缆作为输入,我可以移除它,以获得锁丢失)。 发生这种情况时、进入 SRC (RX1+和 RX1-)的线路没有任何信息。
当锁定信号进入 SRC 时、正常运行期间不会发生这种情况。
如前所述、我不认为我可以更改这部分的主/从/时钟源。 我可以看看输入时钟的示波器、并验证这些时钟源是否正确?
谢谢!
本
尊敬的 Ben:
对不起、我没有原来的问题。
我在之前的 e2e 中发现此信息可能会有所帮助:
SRC4192中唯一一个能够在信号丢失时自动静音的 IP 是 DIR、这是通过设置寄存器0E 中的 RXMLL 位来实现的。 如果 DIR 在输入信号上失去锁定、这将使其自身静音。 软件中完成的所有其它静音都是必须由主机控制器设定的手动静音。 这就是我们具有 LOCK、RDY 和 MUTE 引脚的原因。 如果在 DIR 中失去锁定、则 LOCK 引脚将发生变化、该信号可连接到 MUTE 引脚、以自动使所有输出(而不仅仅是 DIR 输出)静音。
如果不能跟踪追击、您可能可以使用锁定或静音针作为解决方案。 如果可能、我可以尝试其他测试输入频率。 我在您的图中看到追击和预期信号的频率接近、但并不相同。 如果两个频率彼此相邻、这可能会给出一些有关所发生情况的线索。
同时再次读取 RXMLL 函数也不会使 AES3线路上的前导码、P、V、U 或 C 位静音。 在失锁时、DSP 处理这些其他位的方法是否可能是不正确的?
此致、
Jeff McPherson
尊敬的 Jeff:
是的、DIR 是我们想要静音的全部、因此看起来使用 RXMLL 会为我们做到这一点。 我们只想在发生失锁时使 DIR 静音、因此、如果 MUTE 引脚(或寄存器0x2D - MUTE)禁用所有输出、这不是我们想要的功能。
设置静音寄存器可以摆脱任何追击、但再次说明、如果这也会禁用 DIT、这不是我们想要的。
这两种频率是相同的、当改变输入频率时也是遵循、在突发图中略有偏离的只是示波器的输出频率、我已经确认了这一点。
我不确定前导码位的含义是什么? SRC 是否不会通过串行方式将 AES 转换为数字音频?
谢谢!
本
你(Ben)好
Jeff 提到、如果不提供 CLK、将 CLK 接地便是可被视为"移除 CLK "的示例之一。 我的理解是、当 CLKS 发生故障时、静音功能开启、这也解释了您的观察。
当 REF 时钟到 PLL 和 FB 时钟被锁相时、锁定指示器变为高电平。 也就是说、当 PLL 处于稳定状态时、它 被锁定。 通常、过度抖动可能会导致失锁指示、即使 REF 和 FB 被锁定且不存在系统级错误也是如此。
此致、
Arash
您好、我可以确认此行为。 任何 DIR 输入失锁后、都会发出恒定的"拇指"声。
在我的应用中、监视 LOCK 和接收器状态寄存器(可以通过 I2C 或 GPIO 支持来完成)。 如果音频信号丢失、请将连接到主机控制器的端口静音。 这是我找到的唯一有效的解决方法。
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;
}您好!
原因很简单、我只有 I2C、未连接 LOCK\引脚、因为主机控制器的 IO 非常少。 因此、我构建此例程、使其能够在连接和不连接 LOCK\引脚的产品中使用。 目前、I2C 每50ms 请求一次状态。
我还尝试使用 RXAMLL (在我的应用中默认设置)、但它不能按预期工作、我收到了这种奇怪的"pffffffttt"噪声。
参考您的另一个线程、使用该方法可以轻松确定哪个 SRC4392报告了锁定错误。
e2e.ti.com/.../src4392-src4392-how-does-the-interrupt-mode-level-active-function
供参考:
#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;
}
}