Date: Mon, 24 Dec 2018 23:16:18 +0000 From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 234380] [snd_uaudio] Sample rate detection fails for SPL Crimson Rev 1 Message-ID: <bug-234380-19105@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D234380 Bug ID: 234380 Summary: [snd_uaudio] Sample rate detection fails for SPL Crimson Rev 1 Product: Base System Version: 12.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: usb Assignee: usb@FreeBSD.org Reporter: dev@submerge.ch Created attachment 200478 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D200478&action= =3Dedit Implement sample rate table requests in two steps. The SPL Crimson Revision 1 is a (mostly) class compliant USB 2.0 audio interface for musicians. Due to a firmware bug the device will not return a sample rate table on request when using the current implementation in the snd_uaudio module. How to reproduce: 1. Set a quirk for the device to use the second USB configuration, which provides the full USB 2.0 audio interface: usbconfig add_dev_quirk_vplh 0x0a4a 0xc150 0x0000 0xffff UQ_CFG_INDEX_1 2. Plug the SPL Crimson into a USB 2.0 port. Results: The snd_uaudio module takes very long to attach to the device (some minutes= ). No playback or recording channels are found since the sample rates are miss= ing. Expected: Creation of a 6 in 6 out pcm device for up to 96kHz sample rate within seco= nds. Hard- and Software: SPL Crimson Revision 1 at firmware 1.0.9, the newest available on their website. FreeBSD 11.2-RELEASE and 12.0-RELEASE for amd64. Analysis: For USB 2.0 audio devices, snd_uaudio sends a request to get a table of the supported sample rates, possibly multiple times. Since the length of this table is not known, it requests 255 bytes of sample rate table regardless of its actual length. Due to the firmware bug the SPL Crimson only answers requests for up to about 100 bytes length. The unanswered requests for 255 bytes will result in USB timeouts and missing sample rates. When plugged into macOS (High Sierra), the device works as expected and the sample rates are detected correctly. This is because macOS requests only one row of sample rates at first. The table header indicates the actual length, which is then used for a second request. Both approaches should be valid according to the USB 2.0 audio specs. Proposed solution: The patch provided implements exactly the behavior of macOS. It sends one short request first for the header and one table row (2 + 1 * 12 bytes). If answered, a second request is sent using the actual length derived from the header (2 + n * 12 bytes). What is not implemented yet is a wrap-up into an optional USB quirk. But it may also prove beneficial to adopt the macOS behavior in general, many class compliant devices are explicitly tested against Apple software. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-234380-19105>