我们的客户在陕西DMB-T（DTMB）网络环境下测试机顶盒，发现个别节目偶尔出现没有声音的情况，并且期间换台操作容易发生类似死机的现象(音视频均不能播放，其它操作正常)。
  由于需要前往现场解决该问题，也有幸游览西安，后面几天前往周至县，那里的节奏比深圳不知道要慢了多少，在那里出差感觉像休假一样，很好的放松。
  很快就发现，没有声音的时段，节目的同步信息完全不正确。由于我们的软件，默认设置Audio decoder工作在pts locked模式下，根据码流中的pcr调整的stc，和Audio PES中的pts差异太大，无法match，导致Buffer 溢出。我们的软件在这种情况下采用复位Audio模块，包括Buffer，但是最终结果还是溢出。这个时候换台，由于有时需要复位整个Audio decoder，需要处理的事件过于频繁 --- 最终导致部分Task的消息队列溢出，出现类死机现象。
  我尝试该状态下用pts free running模式进行播放，估计是由Audio decoder维护一个独立的STC，源于pes包中的ESCR，当stc与pts匹配后，解码Buffer中的音频数据。但是也未奏效 --- 由于无法录制码流进行分析，估计ESCR缺失或者pts完全不正确)
  最后，采用sw control 模式(类似Buffer control模式),当Audio Buffer到一个阀值，读取Buffer中的数据解码。声音能够解出来。
  但是，该模式完全不考虑音视频同步的问题，所以合理的解决方案是在无法进行同步的情况下，切换到sw control 模式。而能够同步的情况下采用pts locked模式。
  解决方案中唯一的不妥是，由于无法分析码流，无法确诊问题原因，所以采用Audio decoder反馈的Buffer full event为契机，切换的sw control 模式。因为导致Buffer full的情况较多，有些时候复位Buffer之后，同步还能实现，如果通通切换到sw control 模式，同步问题可能发生。
  然而，现场的测试效果不错，类死机的现象没有复现，同步问题也没有出现，因此该解决方案为客户所接受。