Torstein and list;
On Tue, Mar 12, 2013 at 1:48 PM, Torstein Hegge <hegge@xxxxxxxxxxx> wrote:
> On Tue, Mar 12, 2013 at 07:59:52AM -0700, chris hermansen wrote:
>> Mar 12 07:13:34 temuko kernel: [ 1221.640038] usb 1-3: new high-speed
>> USB device number 2 using ehci-pci
>> Mar 12 07:13:34 temuko kernel: [ 1221.797930] usb 1-3: config 1
>> interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
>> Mar 12 07:13:34 temuko kernel: [ 1221.797943] usb 1-3: config 1
>> interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
>
> The device still thinks it should care about midi. I don't want to
> completely drop the theory about interaction with things not really
> supported. Here is another patch on top of the previous quirks-table.h
> entry, ignoring the midi interface as well.
>
> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
> index f2fcc78..66ade73 100644
> --- a/sound/usb/quirks-table.h
> +++ b/sound/usb/quirks-table.h
> @@ -3270,6 +3270,18 @@ YAMAHA_DEVICE(0x7010, "UB99"),
> .type = QUIRK_IGNORE_INTERFACE
> },
> {
> + .ifnum = 6,
> + .type = QUIRK_IGNORE_INTERFACE
> + },
> + {
> + .ifnum = 7,
> + .type = QUIRK_IGNORE_INTERFACE
> + },
> + {
> + .ifnum = 8,
> + .type = QUIRK_IGNORE_INTERFACE
> + },
> + {
> .ifnum = -1
> }
> }
>
> This has the side effect of ignoring the USB HID interface as well, but
> I don't think that does anything useful anyway.
I added that patch and rebuilt the kernel.
[ last experiment's evidence deleted ]
Here's the tail -f results this time. You can see I hit a similar
snag after switching back and forth a few times between 44.1/16 and
96/24.
clh@temuko:~$ tail -f /var/log/kern.log
Mar 13 20:27:58 temuko kernel: [ 19.781445] IPv6:
ADDRCONF(NETDEV_UP): wlan0: link is not ready
Mar 13 20:28:03 temuko kernel: [ 24.521089] wlan0: authenticate with
20:76:00:0d:dd:00
Mar 13 20:28:03 temuko kernel: [ 24.525107] wlan0:
capabilities/regulatory prevented using AP HT/VHT configuration,
downgraded
Mar 13 20:28:03 temuko kernel: [ 24.525317] wlan0: send auth to
20:76:00:0d:dd:00 (try 1/3)
Mar 13 20:28:03 temuko kernel: [ 24.526923] wlan0: authenticated
Mar 13 20:28:03 temuko kernel: [ 24.527235] ath5k 0000:02:02.0
wlan0: disabling HT/VHT due to WEP/TKIP use
Mar 13 20:28:03 temuko kernel: [ 24.528054] wlan0: associate with
20:76:00:0d:dd:00 (try 1/3)
Mar 13 20:28:03 temuko kernel: [ 24.530347] wlan0: RX AssocResp from
20:76:00:0d:dd:00 (capab=0x411 status=0 aid=1)
Mar 13 20:28:03 temuko kernel: [ 24.530674] wlan0: associated
Mar 13 20:28:03 temuko kernel: [ 24.530692] IPv6:
ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
(plugging in the Schiit now)
Mar 13 20:29:43 temuko kernel: [ 124.304074] usb 1-3: new high-speed
USB device number 2 using ehci-pci
Mar 13 20:29:44 temuko kernel: [ 124.461835] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
Mar 13 20:29:44 temuko kernel: [ 124.461848] usb 1-3: config 1
interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
Mar 13 20:29:44 temuko kernel: [ 124.464453] usb 1-3: New USB device
found, idVendor=0d8c, idProduct=0304
Mar 13 20:29:44 temuko kernel: [ 124.464466] usb 1-3: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Mar 13 20:29:44 temuko kernel: [ 124.464477] usb 1-3: Product: Schiit
USB Interface
Mar 13 20:29:44 temuko kernel: [ 124.464487] usb 1-3: Manufacturer: CMEDIA
Mar 13 20:29:44 temuko kernel: [ 124.960360] 2:1: resetting device
after change 48000 -> 192000
Mar 13 20:29:44 temuko kernel: [ 124.971954] usbcore: registered new
interface driver usbhid
Mar 13 20:29:44 temuko kernel: [ 124.971963] usbhid: USB HID core driver
Mar 13 20:29:44 temuko kernel: [ 124.977251] usbcore: registered new
interface driver snd-usb-audio
(starting testing on 44.1/16)
Mar 13 20:31:24 temuko kernel: [ 224.728339] 2:1: resetting device
after change 192000 -> 44100
(sounds great)
(ctrl-c and on to the 96/24)
Mar 13 20:32:12 temuko kernel: [ 272.768623] 2:1: resetting device
after change 44100 -> 96000
(working fine, ctrl-c and back to the 44.1/16)
Mar 13 20:32:45 temuko kernel: [ 305.741080] 2:1: resetting device
after change 96000 -> 44100
(working fine, ctrl-c and back to the 96/24)
Mar 13 20:33:06 temuko kernel: [ 326.579310] 2:1: resetting device
after change 44100 -> 96000
(working fine. ctrl-c and trying to play both on one aplay line)
Mar 13 20:33:51 temuko kernel: [ 372.014273] current rate 96000 is
different from the runtime rate 44100
(oops got alvin and the chipmunks here on the 44.1/16. here is the
output of the aplay -v)
clh@temuko:~/WavTest$ sudo aplay -vD plughw:CARD=Interface,DEV=0 06* 2L*
Home directory not accessible: Permission denied
Playing WAVE '06_-_Amadou & Mariam_-_Artistiya.wav' : Signed 16 bit
Little Endian, Rate 44100 Hz, Stereo
Plug PCM: Hardware PCM card 2 'Schiit USB Interface' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 22050
period_size : 5513
period_time : 125011
tstamp_mode : NONE
period_step : 1
avail_min : 5513
period_event : 0
start_threshold : 22050
stop_threshold : 22050
silence_threshold: 0
silence_size : 0
boundary : 1445068800
appl_ptr : 0
hw_ptr : 0
^CAborted by signal Interrupt...
clh@temuko:~/WavTest$
(trying again...)
Mar 13 20:35:25 temuko kernel: [ 465.674081] 2:1: resetting device
after change 96000 -> 44100
(yep that's fine)^C
clh@temuko:~$
Looking at the messages, I find it odd that the reset doesn't happen
cf. we just jump to the complaint about the rates not matching.
Mar 13 20:33:51 temuko kernel: [ 372.014273] current rate 96000 is
different from the runtime rate 44100
I thought maybe there might be something funny in the aplay command
arising from the pattern
aplay <a 96/24>
aplay <a 44.1/16> <a 96/24>
but I tried it again a few times and this time it all worked. So much
for that idea.
Looking at the code...
Torstein, I am not completely following all the details here but I see
in the patched clock.c
if (cur_rate != rate) {
snd_printk(KERN_WARNING
"current rate %d is different from the
runtime rate %d\n",
cur_rate, rate);
}
/* Some devices doesn't respond to sample rate changes while the
* interface is active. */
if (cur_rate != prev_rate) {
switch (chip->usb_id) {
/* C-Media CM6610/CM6620/CM6631 */
I am not following why you check for cur_rate and rate being unequal
in the first case and cur_rate and prev_rate being unequal in the
second.
Is this intentional, and I'm missing the wonderful subtlety of it all?
--
Chris Hermansen · clhermansen "at" gmail "dot" com
C'est ma façon de parler.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Alsa-user mailing list
Alsa-user@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/alsa-user
