新闻  |   论坛  |   博客  |   在线研讨会
骁龙820A汽车与智能设备间进行USB音频分享方案介绍—UAC篇
车载技术工程师 | 2017-12-14 10:57:33    阅读:5651   发布文章

上一篇《骁龙820A汽车与智能设备间进行USB音频分享方案介绍--USB协议篇》对涉及到的技术关键细节作进一步的详细分析,这一篇是涉及到的UAC篇。


前两篇文章已经可以得到结论,一个控制器需要同时连接多个设备,PC也有很多任务,两者的特点导致了它们具有相对不稳定的传输延迟。USB总线是非常复杂的同时也兼具连 接 灵活,易扩展的特点,但是USB总线并非为音频传输而特别设置的传输方式。

传输机制:

声卡设备需要与主机同步 ,如何解决这种不稳定的传输延迟问题?

为了解决延迟导致的音画不同步问题,因此就有了大家熟知的三种同步方式:SYNC、自适应、ASYNC模式。


SYNC是将输出时钟与每个FrameSOF包同步,但前文可以看到SOF包本身就允许较大的抖动。

自适应是根据Host传送数据的速率调整输出频率。这两种同步方式下USB界面都是被动适应Host端的发送节奏,本身没有反馈机制,产生的JitterUSB总线影响较大。


ASYNC下,USB界面会额外申请一条Feedback传输端口。这里有两种实现,一种是显式Feedback,一种是隐式Feedback


显式Feedback下,USB界面会将单位时间内该传多少Samples回传给Host,让Host计算并知道之后该“补”多少或者该“少”多少采样传给USB界面,这样就能与USB界面主时钟同步并保持不溢出/欠载的缓冲区。UAC1使用数据格式10.14(因为是1ms),UAC2使用数据格式16.16(因为是125us),有所不同

这里以俗知的Amanero界面为例:

Endpoint Descriptor:
------------------------------
0x07        bLength
0x05        bDescriptorType
0x05        bEndpointAddress   (OUT Endpoint) #主机端->USB界面
0x05        bmAttributes        (Transfer: Isochronous / Synch: Asynchronous / Usage: Data) #传输类型Isochronous 同步方式Asynchronous
0x0400        wMaxPacketSize   (1024 Bytes) #最大包大小
0x01        bInterval #传输间隔 2^(1-1) x 125。也就是125us传输一次

Endpoint Descriptor:
------------------------------
0x07        bLength
0x05        bDescriptorType
0x81        bEndpointAddress   (IN Endpoint) #USB界面->主机端
0x11        bmAttributes        (Transfer: Isochronous / Synch: None / Usage: Feedback) #传输类型Isochronous 用于Feedback
0x0004        wMaxPacketSize   (4 Bytes)  #最大包大小4字节
0x06        bInterval #传输间隔 2^(6-1) x 125。也就是4000us(4ms)传输一次

这是一个典型的显式FeedbackASYNC,上行反馈Endpoint,每4ms传输一次,最大包大小是4字节。再来看看LinuxUAC驱动是如何处理反馈的


...
1156         /*
1157          * process after playback sync complete
1158          *
1159          * Full speed devices report feedback values in 10.14 format as samples
1160          * per frame, high speed devices in 16.16 format as samples per
1161          * microframe.
1162          *
1163          * Because the Audio Class 1 spec was written before USB 2.0, many high
1164          * speed devices use a wrong interpretation, some others use an
1165          * entirely different format.
1166          *
1167          * Therefore, we cannot predict what format any particular device uses
1168          * and must detect it automatically.
1169          */
1170 
1171         if (urb->iso_frame_desc[0].status != 0 ||
1172             urb->iso_frame_desc[0].actual_length < 3)
1173                 return;
1174 
1175         f = le32_to_cpup(urb->transfer_buffer);
1176         if (urb->iso_frame_desc[0].actual_length == 3)
1177                 f &= 0x00ffffff;
1178         else
1179                 f &= 0x0fffffff;
1180 
1181         if (f == 0)
1182                 return;
1183 
1184         if (unlikely(sender->tenor_fb_quirk)) {
1185                 /*
1186                  * Devices based on Tenor 8802 chipsets (TEAC UD-H01
1187                  * and others) sometimes change the feedback value
1188                  * by +/- 0x1.0000.
1189                  */
1190                 if (f < ep->freqn - 0x8000)
1191                         f += 0xf000;
1192                 else if (f > ep->freqn + 0x8000)
1193                         f -= 0xf000;
1194         } else if (unlikely(ep->freqshift == INT_MIN)) {
1195                 /*
1196                  * The first time we see a feedback value, determine its format
1197                  * by shifting it left or right until it matches the nominal
1198                  * frequency value.  This assumes that the feedback does not
1199                  * differ from the nominal value more than +50% or -25%.
1200                  */
1201                 shift = 0;
1202                 while (f < ep->freqn - ep->freqn / 4) {
1203                         f <<= 1;
1204                         shift++;
1205                 }
1206                 while (f > ep->freqn + ep->freqn / 2) {
1207                         f >>= 1;
1208                         shift--;
1209                 }
1210                 ep->freqshift = shift;
1211         } else if (ep->freqshift >= 0)
1212                 f <<= ep->freqshift;
1213         else
1214                 f >>= -ep->freqshift;
1215 
1216         if (likely(f >= ep->freqn - ep->freqn / 8 && f <= ep->freqmax)) {
1217                 /*
1218                  * If the frequency looks valid, set it.
1219                  * This value is referred to in prepare_playback_urb().
1220                  */
1221                 spin_lock_irqsave(&ep->lock, flags);
1222                 ep->freqm = f;
1223                 spin_unlock_irqrestore(&ep->lock, flags);
1224         } else {
1225                 /*
1226                  * Out of range; maybe the shift value is wrong.
1227                  * Reset it so that we autodetect again the next time.
1228                  */
1229                 ep->freqshift = INT_MIN;
1230         }


这里主要是处理来自于USB界面的反馈(并且应付一些不按标准做的USB界面),将获取的值保存进freqm。之后这个值会在snd_usb_endpoint_next_packet_size函数被使用。

145 int snd_usb_endpoint_next_packet_size(struct snd_usb_endpoint *ep)
146 {
147         unsigned long flags;
148         int ret;
149 
150         if (ep->fill_max)
151                 return ep->maxframesize;
152 
153         spin_lock_irqsave(&ep->lock, flags);
154         ep->phase = (ep->phase & 0xffff)
155                 + (ep->freqm << ep->datainterval);
156         ret = min(ep->phase >> 16, ep->maxframesize);
157         spin_unlock_irqrestore(&ep->lock, flags);
158 
159         return ret;
160 }

这里将freqm转化为下一次的包大小,并供prepare_playback_urb使用

1451 static void prepare_playback_urb(struct snd_usb_substream *subs,
1452                                  struct urb *urb)
1453 {
1454         struct snd_pcm_runtime *runtime = subs->pcm_substream->runtime;
1455         struct snd_usb_endpoint *ep = subs->data_endpoint;
1456         struct snd_urb_ctx *ctx = urb->context;
1457         unsigned int counts, frames, bytes;
1458         int i, stride, period_elapsed = 0;
1459         unsigned long flags;
1460 
1461         stride = runtime->frame_bits >> 3;
1462 
1463         frames = 0;
1464         urb->number_of_packets = 0;
1465         spin_lock_irqsave(&subs->lock, flags);
1466         subs->frame_limit += ep->max_urb_frames;
1467         for (i = 0; i < ctx->packets; i++) {
1468                 if (ctx->packet_size)
1469                         counts = ctx->packet_size;
1470                 else
1471                         counts = snd_usb_endpoint_next_packet_size(ep);

prepare_playback_urb这个函数主要决定了音频回放的USB请求数据块(URB)准备工作,包括该传多少USB数据给界面,而这里可以看到snd_usb_endpoint_next_packet_size对于包大小很重要。除此之外没有什么其它作用

如果仔细读代码,可以发现ASYNC和别的同步方式的最大区别它如何影响主机发送数据的多少,其它是与对待别的同步方式一模一样的。


ASYNC
的最大好处是,USB界面决定了主机每次Frame中每个包该给多少Samples给它,这样USB界面可以自己决定主时钟并且用这个时钟去“校准”主机发送的数据速率,而不再需要适应Host的发送频率

通常高速需要有125us x 2Buffer,全速需要1ms x 2buffer。这些构成了USB音频的最小延迟。配合一定的USB Buffer以及合适的FIFO Buffer,就可以从根本上对USB总线的不稳定时钟“去耦”了。最多是缓冲区欠载产生播放停顿 或者缓冲区溢出程序没处理好造成程序崩溃。

对于USB界面自身,需要监控自身主时钟与来自主机的SOF包之间的时间,计算出偏差不断给Host反馈。并且因为Host发送速率和实际播放速率并不一致,USB界面自身需要合成与播放相关的Clock,这个合成实现具体做法十分影响最终出来的效果,这对嵌入式开发者是一个不小的挑战。

另外还有一个常见的误区,就是异步每次数据包里包含的“采样数”可以变化很大,实际上并不是这样。USB规范中最多允许每个USB包包含的samples变化在±1[7]。因此如果之前数据错误丢失了采样,也不可以因此“索取”更多的“采样”

6.png

上述就是和USB音频传输相关的一些UAC的基础知识。


参与讨论
登录后参与讨论
419147953  2017-12-14 11:26:32 

谢谢分享

推荐文章
最近访客