若正在播放
1
Altset =
1
Packet Size =
196
Momentary freq =
43640 Hz (
0x2b.a3c0)
Feedback Format =
10.14
Packet Size =
0
Momentary freq =
44100 Hz (
0x2c.199a)
Interface 上面的信息非常有用，可以看到，此音频设备是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://www.jb51.cc/article/p-owjrwpja-vw.html
不过抓到的数据看起来很不直观， 例如下面我是一小段用usbmon抓到信息:
@H_403_116@
ead46c00 3346920735 C Zi:1:003:2 0:16:954:0 1 3 4 = f0e80b00
ead46c00 3346920736 S Zi:2 -115:954 1 -18:4 <
eddf8600 3346928822 C Zo:955:8 188 188:192 380:568:760:1524 >
eddf8600 3346928836 S Zo:955 8 -188 -192 -572:1524 = a503c8fd 7703c6fd 3f03c3fd 0803c3fd d102c6fd 9102ccfd 5702d4fd 1602dafd
ea4cbc00 3346936710 C Zo:963:1524 >
ea4cbc00 3346936723 S Zo:963 1524 = 08fbf9fa 22fbe5fa 40fbd2fa 5efbc1fa 83fbb9fa abfbb5fa d4fbaffa 03fcb1fa
ead46e40 3346936729 C Zi:970:4 = f0e80b00
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,255)">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,and Endpoint are
decimal numbers,but they may
130 have leading zeros,255)">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
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,255)">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,255)">if present,consists of
5 words: one of each
for bmRequestType,152 bRequest,wValue,wIndex,wLength,255)">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
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,255)">this
is the requested length. For callbacks,128)">164 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,255)">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).
