? ? 最近想玩玩LINUX,于是雙系統裝了一個Ubuntu13.04。

? ? 在新系統下用著都還好，不過我自己DIY的USB DAC出了問題。在WIN7下能正常工作，但是在Ubuntu下就爆音不斷，很明顯是音頻數據流斷流引起的。

? ? 這說明stm32上的固件與Ubuntu的USB AUDIO驅動程序不太兼容，于是開始檢查。在這個過程中，學到不少調試方法，下面詳細描述下調試的過程：

? 1.? 第一步需要確定USB DAC已經成功連接到PC，這里使用dmesg命令查看內核的信息。

? ? USB DAC連接PC，輸入命令:

? ? ?>> dmesg | tail ?

[ 2148.890771] usb 1-1.2: Product: Ilmen Audio [ 2148.890774] usb 1-1.2: Manufacturer: IlmenTech [ 2148.890778] usb 1-1.2: SerialNumber: 5CDC856933 [ 2150.327668] usb 1-1.2: USB disconnect, device number 83 [ 2151.785785] usb 1-1.2: new full-speed USB device number 84 using ehci-pci [ 2151.880680] usb 1-1.2: New USB device found, idVendor=0483, idProduct=5730 [ 2151.880687] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2151.880692] usb 1-1.2: Product: Ilmen Audio [ 2151.880696] usb 1-1.2: Manufacturer: IlmenTech [ 2151.880699] usb 1-1.2: SerialNumber: 5CDC856933

? ? ?可以看到設備的一些信息，USB設備已經成功的連接到PC。(由于最初我的USB配置描述符有BUG，所以可以從內核的輸出信息里看到USB沒有枚舉成功，以及出錯的原因)

? 2. 第二步是查看這個USB設備的具體信息，這里用到命令lsusb。

? ? >> lsusb

Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 1366:0101 SEGGER J-Link ARM Bus 001 Device 004: ID 0483:5730 SGS Thomson Microelectronics Bus 002 Device 003: ID 046d:c52f Logitech, Inc. Wireless Mouse M305 Bus 002 Device 004: ID 064e:f207 Suyin Corp.

? ? lsusb列出了當前所有可用的USB設備，在上面可以看到jlink設備，我的羅技無線鼠標，而"SGS Thomson Microelectronics"就是stm32的USB設備。

? ? 可以看到這個設備在Bus 001下，Device為004；在知道這兩個地址后，可以用lsusb命令查看更多該設備的信息。?

? ? 于是輸入?>> lsusb -D /dev/bus/usb/001/004?

Device: ID 0483:5730 SGS Thomson Microelectronics Device Descriptor:bLength 18bDescriptorType 1bcdUSB 2.00bDeviceClass 0 (Defined at Interface level)bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8idVendor 0x0483 SGS Thomson MicroelectronicsidProduct 0x5730 bcdDevice 2.00iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1
......

?

? ? ?命令行則會列出設備的描述符，由于很長，所以之列出前面幾行信息。

? ? ?http://www.linuxnix.com/2013/05/find-usb-device-details-in-linuxunix-using-lsusb-command.html這個帖子介紹了lsusb的基本用法，可以參考。

3.? USB設備信息有了，接下來看看系統音頻設備列表里的情況。

? ? ?查看當前可用的音頻設備可以通過命令?>> aplay -l

**** PLAYBACK 硬體裝置清單 **** card 0: MID [HDA Intel MID], device 0: ALC272 Analog [ALC272 Analog]子設備: 1/1子設備 #0: subdevice #0 card 0: MID [HDA Intel MID], device 1: ALC272 Digital [ALC272 Digital]子設備: 1/1子設備 #0: subdevice #0 card 1: Audio [Ilmen Audio], device 0: USB Audio [USB Audio]子設備: 0/1子設備 #0: subdevice #0 card 2: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]子設備: 1/1子設備 #0: subdevice #0

?

? ? 從上面的信息可以看出，此時我的USB ?DAC是card 1，為可用的。

? ? 目錄/proc/asound/下有各種音頻設備，例如我的USB DAC就在/proc/asound/card1/文件夾下，這里可以看到很多音頻設備的信息。

? ? 音頻設備的參數 >> cat /proc/asound/card1/pcm0p/sub0/hw_params ?

access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 1024 buffer_size: 16384

? ? 查看音頻流的當前參數?>> cat /proc/asound/card1/stream0

? ? 如果沒有播放聲音(無音頻流)

IlmenTech Ilmen Audio at usb-0000:00:1a.0-1.2, full speed : USB AudioPlayback:Status: StopInterface 1Altset 1Format: S16_LEChannels: 2Endpoint: 1 OUT (ASYNC)Rates: 44100

? ? 若正在播放

IlmenTech Ilmen Audio at usb-0000:00:1a.0-1.2, full speed : USB AudioPlayback:Status: RunningInterface = 1Altset = 1Packet Size = 196Momentary freq = 43640 Hz (0x2b.a3c0)Feedback Format = 10.14Packet Size = 0Momentary freq = 44100 Hz (0x2c.199a)Interface 1Altset 1Format: S16_LEChannels: 2Endpoint: 1 OUT (ASYNC)Rates: 44100

? ? 上面的信息非常有用，可以看到，此音頻設備是ASYNC(異步模式)，2個聲道，有符號16bit的數據格式。

? ? 再往上看，反饋(feedback)的格式是10.14，這在USB 2.0協議里有詳細說明。當前反饋的采樣率是43640 Hz(會變化)，下面那個44100是此設備支持的采樣率。

? ? 上面這是我成功解決問題后打印出的信息，在USB DAC工作不正常時(斷流)，可以看到第一個Moment freq這一項的參數十分接近48000 Hz且不會變動，這是不正常的。

? ? ?在google了一天也沒找到原因，最后無意間將feedback的范圍從 44.1Khz +- 5Khz 減小到44.1Khz +- 1Khz才工作正常。

? ? ?可見Ubuntu與WIN7的底層音頻驅動有不同，由于沒看過具體代碼，所也目前也只能猜測：當我反饋的采樣率值超過當前設備的“額定采樣率”44.1Khz過多后，就導致了當前采樣率“卡”在了某一固定值，不知道這算不算一個BUG。

? ? ?有關ALSA的東西可以在這里查:?http://www.alsa-project.org/main/index.php/Asoundrc

4. 最后再提一個linux下調試USB十分方便的工具:usbmon

? ? ?這個USB的抓包工具linux自帶，已經編譯進內核。

? ? ?具體使用方法可以參考http://blog.csdn.net/liuqz2009/article/details/7886461

? ? ?不過抓到的數據看起來很不直觀， 例如下面我是一小段用usbmon抓到信息:

ead46c00 3346920735 C Zi:1:003:2 0:16:954:0 1 0:0:3 4 = f0e80b00 ead46c00 3346920736 S Zi:1:003:2 -115:16:954 1 -18:0:3 4 < eddf8600 3346928822 C Zo:1:003:1 0:1:955:0 8 0:0:188 0:188:192 0:380:188 0:568:192 0:760:192 1524 > eddf8600 3346928836 S Zo:1:003:1 -115:1:955 8 -18:0:188 -18:188:192 -18:380:192 -18:572:188 -18:760:192 1524 = a503c8fd 7703c6fd 3f03c3fd 0803c3fd d102c6fd 9102ccfd 5702d4fd 1602dafd ea4cbc00 3346936710 C Zo:1:003:1 0:1:963:0 8 0:0:188 0:188:192 0:380:192 0:572:188 0:760:192 1524 > ea4cbc00 3346936723 S Zo:1:003:1 -115:1:963 8 -18:0:188 -18:188:192 -18:380:192 -18:572:188 -18:760:192 1524 = 08fbf9fa 22fbe5fa 40fbd2fa 5efbc1fa 83fbb9fa abfbb5fa d4fbaffa 03fcb1fa ead46e40 3346936729 C Zi:1:003:2 0:16:970:0 1 0:0:3 4 = f0e80b00

? ? 要看懂上面的信息還需要借助http://www.mjmwired.net/kernel/Documentation/usb/usbmon.txt里面的說明信息，每一項都有它的含義，需要對照來看。

109 Here is the list of words, from left to right: 110 111 - URB Tag. This is used to identify URBs, and is normally an in-kernel address 112 of the URB structure in hexadecimal, but can be a sequence number or any 113 other unique string, within reason. 114 115 - Timestamp in microseconds, a decimal number. The timestamp's resolution 116 depends on available clock, and so it can be much worse than a microsecond 117 (if the implementation uses jiffies, for example). 118 119 - Event Type. This type refers to the format of the event, not URB type. 120 Available types are: S - submission, C - callback, E - submission error. 121 122 - "Address" word (formerly a "pipe"). It consists of four fields, separated by 123 colons: URB type and direction, Bus number, Device address, Endpoint number. 124 Type and direction are encoded with two bytes in the following manner: 125 Ci Co Control input and output 126 Zi Zo Isochronous input and output 127 Ii Io Interrupt input and output 128 Bi Bo Bulk input and output 129 Bus number, Device address, and Endpoint are decimal numbers, but they may 130 have leading zeros, for the sake of human readers. 131 132 - URB Status word. This is either a letter, or several numbers separated 133 by colons: URB status, interval, start frame, and error count. Unlike the 134 "address" word, all fields save the status are optional. Interval is printed 135 only for interrupt and isochronous URBs. Start frame is printed only for 136 isochronous URBs. Error count is printed only for isochronous callback 137 events. 138 139 The status field is a decimal number, sometimes negative, which represents 140 a "status" field of the URB. This field makes no sense for submissions, but 141 is present anyway to help scripts with parsing. When an error occurs, the 142 field contains the error code. 143 144 In case of a submission of a Control packet, this field contains a Setup Tag 145 instead of an group of numbers. It is easy to tell whether the Setup Tag is 146 present because it is never a number. Thus if scripts find a set of numbers 147 in this word, they proceed to read Data Length (except for isochronous URBs). 148 If they find something else, like a letter, they read the setup packet before 149 reading the Data Length or isochronous descriptors. 150 151 - Setup packet, if present, consists of 5 words: one of each for bmRequestType, 152 bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0. 153 These words are safe to decode if Setup Tag was 's'. Otherwise, the setup 154 packet was present, but not captured, and the fields contain filler. 155 156 - Number of isochronous frame descriptors and descriptors themselves. 157 If an Isochronous transfer event has a set of descriptors, a total number 158 of them in an URB is printed first, then a word per descriptor, up to a 159 total of 5. The word consists of 3 colon-separated decimal numbers for 160 status, offset, and length respectively. For submissions, initial length 161 is reported. For callbacks, actual length is reported. 162 163 - Data Length. For submissions, this is the requested length. For callbacks, 164 this is the actual length. 165 166 - Data tag. The usbmon may not always capture data, even if length is nonzero. 167 The data words are present only if this tag is '='. 168 169 - Data words follow, in big endian hexadecimal format. Notice that they are 170 not machine words, but really just a byte stream split into words to make 171 it easier to read. Thus, the last word may contain from one to four bytes. 172 The length of collected data is limited and can be less than the data length 173 reported in the Data Length word. In the case of an Isochronous input (Zi) 174 completion where the received data is sparse in the buffer, the length of 175 the collected data can be greater than the Data Length value (because Data 176 Length counts only the bytes that were received whereas the Data words 177 contain the entire transfer buffer).

? ? 現在就只看下面這一小段

ead46c00 3346920735 C Zi:1:003:2 0:16:954:0 1 0:0:3 4 = f0e80b00 ead46c00 3346920736 S Zi:1:003:2 -115:16:954 1 -18:0:3 4 < eddf8600 3346928822 C Zo:1:003:1 0:1:955:0 8 0:0:188 0:188:192 0:380:188 0:568:192 0:760:192 1524 > eddf8600 3346928836 S Zo:1:003:1 -115:1:955 8 -18:0:188 -18:188:192 -18:380:192 -18:572:188 -18:760:192 1524 = a503c8fd 7703c6fd 3f03c3fd 0803c3fd d102c6fd 9102ccfd 5702d4fd 1602dafd

? ? ?第一行的 “ead46c00” 就是上面說明里提到的URB Tag; "3346920735" 是時間戳，以微秒為單位，這個可以從連續的兩個feedback驗證，

...... ead46c00 3346920735 C Zi:1:003:2 0:16:954:0 1 0:0:3 4 = f0e80b00 ...... ead46e40 3346936729 C Zi:1:003:2 0:16:970:0 1 0:0:3 4 = f0e80b00
......

? ? 兩個包的時間戳之差約為16000,而我的feedback端點的refresh間隔的確是16ms為周期。

? ? 時間戳之后的 C 代表[feedback]事件類型；在這之后是 address項，它由4個部分組成，以符號:隔開，Zi表示同步In端點，1:003代表bus1下的003號設備，2表示該端點號。

? ? 接下來是“URB Status word”， 包括"URB status, interval, start frame, and error count"。

? ? 之后是“Number of isochronous frame descriptors and descriptors themselves“，這部分首先是一個數代表frame descriptor的個數, 接下來以空格為間隔，列出每個frame descriptor的信息，此信息有3個部分“status, offset, and length”，以 : 符號隔開。可以看到，第一行只有一個frame descriptor，數據長度為3。

? ? 最后是數據長度， 緊跟著是 > < 或 =， 然后就是部分的傳輸數據了。

? ? ?

? ? ?

??

?

?

轉載于:https://www.cnblogs.com/Ilmen/p/3451628.html

總結

以上是生活随笔為你收集整理的Ubuntu13下调试USB AUDIO的一些记录的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。