? ? 最近想玩玩LINUX,于是雙系統(tǒng)裝了一個(gè)Ubuntu13.04。

? ? 在新系統(tǒng)下用著都還好，不過(guò)我自己DIY的USB DAC出了問(wèn)題。在WIN7下能正常工作，但是在Ubuntu下就爆音不斷，很明顯是音頻數(shù)據(jù)流斷流引起的。

? ? 這說(shuō)明stm32上的固件與Ubuntu的USB AUDIO驅(qū)動(dòng)程序不太兼容，于是開(kāi)始檢查。在這個(gè)過(guò)程中，學(xué)到不少調(diào)試方法，下面詳細(xì)描述下調(diào)試的過(guò)程：

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

? ? 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

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

? 2. 第二步是查看這個(gè)USB設(shè)備的具體信息，這里用到命令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列出了當(dāng)前所有可用的USB設(shè)備，在上面可以看到j(luò)link設(shè)備，我的羅技無(wú)線鼠標(biāo)，而"SGS Thomson Microelectronics"就是stm32的USB設(shè)備。

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

? ? 于是輸入?>> 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
......

?

? ? ?命令行則會(huì)列出設(shè)備的描述符，由于很長(zhǎng)，所以之列出前面幾行信息。

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

3.? USB設(shè)備信息有了，接下來(lái)看看系統(tǒng)音頻設(shè)備列表里的情況。

? ? ?查看當(dāng)前可用的音頻設(shè)備可以通過(guò)命令?>> aplay -l

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

?

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

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

? ? 音頻設(shè)備的參數(shù) >> 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

? ? 查看音頻流的當(dāng)前參數(shù)?>> cat /proc/asound/card1/stream0

? ? 如果沒(méi)有播放聲音(無(wú)音頻流)

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

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

? ? 再往上看，反饋(feedback)的格式是10.14，這在USB 2.0協(xié)議里有詳細(xì)說(shuō)明。當(dāng)前反饋的采樣率是43640 Hz(會(huì)變化)，下面那個(gè)44100是此設(shè)備支持的采樣率。

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

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

? ? ?可見(jiàn)Ubuntu與WIN7的底層音頻驅(qū)動(dòng)有不同，由于沒(méi)看過(guò)具體代碼，所也目前也只能猜測(cè)：當(dāng)我反饋的采樣率值超過(guò)當(dāng)前設(shè)備的“額定采樣率”44.1Khz過(guò)多后，就導(dǎo)致了當(dāng)前采樣率“卡”在了某一固定值，不知道這算不算一個(gè)BUG。

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

4. 最后再提一個(gè)linux下調(diào)試USB十分方便的工具:usbmon

? ? ?這個(gè)USB的抓包工具linux自帶，已經(jīng)編譯進(jìn)內(nèi)核。

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

? ? ?不過(guò)抓到的數(shù)據(jù)看起來(lái)很不直觀， 例如下面我是一小段用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里面的說(shuō)明信息，每一項(xiàng)都有它的含義，需要對(duì)照來(lái)看。

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).

? ? 現(xiàn)在就只看下面這一小段

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” 就是上面說(shuō)明里提到的URB Tag; "3346920735" 是時(shí)間戳，以微秒為單位，這個(gè)可以從連續(xù)的兩個(gè)feedback驗(yàn)證，

...... 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
......

? ? 兩個(gè)包的時(shí)間戳之差約為16000,而我的feedback端點(diǎn)的refresh間隔的確是16ms為周期。

? ? 時(shí)間戳之后的 C 代表[feedback]事件類型；在這之后是 address項(xiàng)，它由4個(gè)部分組成，以符號(hào):隔開(kāi)，Zi表示同步In端點(diǎn)，1:003代表bus1下的003號(hào)設(shè)備，2表示該端點(diǎn)號(hào)。

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

? ? 之后是“Number of isochronous frame descriptors and descriptors themselves“，這部分首先是一個(gè)數(shù)代表frame descriptor的個(gè)數(shù), 接下來(lái)以空格為間隔，列出每個(gè)frame descriptor的信息，此信息有3個(gè)部分“status, offset, and length”，以 : 符號(hào)隔開(kāi)。可以看到，第一行只有一個(gè)frame descriptor，數(shù)據(jù)長(zhǎng)度為3。

? ? 最后是數(shù)據(jù)長(zhǎng)度， 緊跟著是 > < 或 =， 然后就是部分的傳輸數(shù)據(jù)了。

? ? ?

? ? ?

??

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/Ilmen/p/3451628.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。