On Sat, Mar 09, 2013 at 09:01:48AM -0800, chris hermansen wrote: > I plugged in the Schiit, then with 'sudo aplay -vD > plughw:CARD=Interface,DEV=0' I played: > > 1. a 44.1/16 for ~ 10 seconds - it sounded fine - so I interrupted it > 2. a 96/24 - it was staticky / noisy, even though the plughw slave > reported it at 96000 - I interrupted it > 3. the same 96/24 again - it was fine > > Here is the stream from /var/log/kern.log, as it all occurred > > clh@temuko:~/kernel$ tail -f /var/log/kern.log > Mar 9 08:33:05 temuko kernel: [ 250.380056] usb 1-3: new high-speed > USB device number 2 using ehci-pci > Mar 9 08:33:05 temuko kernel: [ 250.537896] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 > Mar 9 08:33:05 temuko kernel: [ 250.537909] usb 1-3: config 1 interface 8 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64 > Mar 9 08:33:05 temuko kernel: [ 250.540454] usb 1-3: New USB device found, idVendor=0d8c, idProduct=0304 > Mar 9 08:33:05 temuko kernel: [ 250.540480] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 > Mar 9 08:33:05 temuko kernel: [ 250.540490] usb 1-3: Product: Schiit USB Interface > Mar 9 08:33:05 temuko kernel: [ 250.540499] usb 1-3: Manufacturer: CMEDIA > Mar 9 08:33:05 temuko kernel: [ 250.910794] 2:1: resetting device after change 48000 -> 192000 > Mar 9 08:33:05 temuko kernel: [ 250.926921] 2:2: resetting device after change 48000 -> 192000 > Mar 9 08:33:05 temuko kernel: [ 250.954813] 2:3: resetting device after change 48000 -> 192000 > Mar 9 08:33:05 temuko kernel: [ 250.966681] 2:4: resetting device after change 48000 -> 192000 > Mar 9 08:33:05 temuko kernel: [ 250.979809] current rate 48000 is different from the runtime rate 192000 > Mar 9 08:33:05 temuko kernel: [ 250.979822] 2:5: resetting device after change -595519488 -> 48000 > Mar 9 08:33:05 temuko kernel: [ 250.984816] 2:5:2: clock source 19 is not valid, cannot use > Mar 9 08:33:05 temuko kernel: [ 250.985339] cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 According to lsusb -v from https://gist.github.com/storrgie/2897496 the initialization goes through iface 1-5 which are 2: SPDIF Output 3: Microphone In 4: Line In 5: SPDIF Input and when it gets to SPDIF Input altsetting 2, uac_clock_source_is_valid() fails. Other CM6631-devices doesn't expose iface 2-5. These extra exposed interfaces only observable difference between the Schiit and other devices. > Mar 9 08:33:05 temuko kernel: [ 250.995007] usbcore: registered new interface driver usbhid > Mar 9 08:33:05 temuko kernel: [ 250.995022] usbhid: USB HID core driver > Mar 9 08:33:05 temuko kernel: [ 251.012102] usbcore: registered new interface driver snd-usb-audio > Mar 9 08:33:05 temuko kernel: [ 251.139444] input: CMEDIA Schiit USB Interface as /devices/pci0000:00/0000:00:13.2/usb1/1-3/1-3:1.6/input/input7 > Mar 9 08:33:05 temuko kernel: [ 251.140092] hid-generic 0003:0D8C:0304.0001: input,hidraw0: USB HID v1.00 Device [CMEDIA Schiit USB Interface] on usb-0000:00:13.2-3/input6 > Mar 9 08:33:05 temuko kernel: [ 251.252844] 2:4: resetting device after change 192000 -> 44100 > Mar 9 08:33:05 temuko kernel: [ 251.276084] 2:1: resetting device after change 192000 -> 44100 Here the rate is set for 4 (Line In), as well as the expected 1. > Mar 9 08:34:55 temuko kernel: [ 361.220050] current rate 44100 is different from the runtime rate 96000 > Mar 9 08:34:55 temuko kernel: [ 361.220066] 2:1: resetting device after change -467349503 -> 44100 > Mar 9 08:35:18 temuko kernel: [ 384.140889] 2:1: resetting device after change 44100 -> 96000 The first read of rate is garbled. After setting the rate to 44.1k, the rate is read back as 96k. > (playing 96/24) > > (sounds fine - interrupting 96/24) > > (playing 44.1/16) > > Mar 9 08:49:35 temuko kernel: [ 1241.305358] 2:1: resetting device after change 96000 -> 44100 > > (sounds fine - interrupting 44.1/16) > > (playing 96/24) > > Mar 9 08:50:32 temuko kernel: [ 1297.804486] 2:1:2: cannot get freq (v2) > > (ok that is weird, it did not play, and the following came out of the aplay:) The read with snd_usb_ctl_msg() fails, and aborts the rate setting. > Playing WAVE '2L50SACD_tr1_96k_stereo.wav' : Signed 24 bit Little > Endian in 3bytes, Rate 96000 Hz, Stereo > aplay: set_params:1145: Unable to install hw params: > [...] > > (trying the 96/24 again) > > Mar 9 08:52:13 temuko kernel: [ 1399.137610] 2:1: resetting device after change 44100 -> 96000 If the attempts at modifying the rate of the SPDIF output from the CM6631 interferes with the intended operation, that might explain why the Schiit Bifrost still has issues with the workaround applied, while the Corda Daccord and Asus Xonar Essence One works fine. The theory doesn't fit that well with your previous experience where the problem first occurred long after plugging in the device, but it should be easy to test by ignoring the extra interfaces exposed by the Schiit: diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 64d25a7..f2fcc78 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3238,4 +3238,42 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, +/* Schiit USB Interface */ +{ + USB_DEVICE(0x0d8c, 0x0304), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = & (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = 3, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = 4, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = 5, + .type = QUIRK_IGNORE_INTERFACE + }, + { + .ifnum = -1 + } + } + } +}, + #undef USB_DEVICE_VENDOR_SPEC Torstein ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
