Date: Mon, 24 Dec 2018 11:26:21 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Florian Walpen <dev@submerge.ch>, freebsd-usb@freebsd.org Subject: Re: SPL Crimson (rev 1) and snd_uaudio Message-ID: <68abf39b-7c6f-d9a9-bb6c-3cfeb2b569ea@selasky.org> In-Reply-To: <5738623.nAnukg6brD@z800> References: <1898371.YXp4yczo3S@z800> <569736da-5b33-44cb-4ad8-2986b38c10d0@selasky.org> <5738623.nAnukg6brD@z800>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/24/18 1:43 AM, Florian Walpen wrote: > On Sunday, December 23, 2018 9:56:20 PM CET Hans Petter Selasky wrote: >> On 12/23/18 3:07 PM, Florian Walpen wrote: >>> Hello all, >>> >>> this is my first post here, so apologies if this isn't the most >>> appropriate >>> list - but i thought this topic is more related to USB than to multimedia. >>> >>> I treated myself to an SPL Crimson (rev 1), which is a well-built USB >>> audio >>> interface for musicians (4 in 4 out + SPDIF) that hits the second hand >>> market here now for around 200$. See >>> https://spl.audio/studio/crimson/?lang=en >>> >>> It is indeed USB 2.0 Audio Class compliant as advertised, but still made >>> me >>> jump quite some hurdles before i got it to work with FreeBSD. >>> For the records: >>> >>> 1. This device is a shape-shifter and will present different USB >>> descriptors to Windows and macOS. A USB 1.0 Audio Class compliant header >>> is always there and works (2 in 2 out at 48000), but the USB 2.0 >>> configuration is hidden in Windows and only appears in macOS. Moreover, >>> the Crimson keeps that state between power cycles, so my solution was to >>> plug it into macOS once and never into Windows again. >>> >>> 2. The USB 2.0 header is in the second USB configuration, which is easy >>> enough to fix with a quirk added to /boot/loader.conf: >>> >>> hw.usb.quirk.0="0x0a4a 0xc150 0x0000 0xffff UQ_CFG_INDEX_1" >>> >>> 3. Still, there are no play and record channels detected and uaudio takes >>> minutes to attach to the device. As it turns out, the Crimson chokes on >>> the >>> sample rate request messages, resulting in USB timeouts. The >>> implementation in FreeBSD is somewhat simplistic in this regard, and i >>> have a patch now for 12.0-RELEASE which mimics the more subtle behaviour >>> of macOS. >>> >>> This gave me a working audio device with 6 in 6 out channels and sample >>> rates up to 96000. Output seems to work fine, i didn't test recording yet >>> since i don't have my gear here at home. >>> >>> >>> Now my questions would be: >>> a) What about adding the quirk permanently to FreeBSD? >>> I'm unsure because it could make a Crimson in crippled Windows mode >>> unusable, even though the device is not too useful in that state anyway. >>> Maybe i should investigate what triggers the shape-shifting first, i do >>> have USB dumps from macOS. >> >> Hi, >> >> If you want to add the patch permanently, add it to >> sys/dev/usb/quirk/usb_quirk.c . There should already be quirks for Fast >> Track Ultra R8 from M-audio, which are halfway class compliant. Did you >> look at Linux for any quirks for your device? > > Hi, > > thanks for the hints, I suppose the vendor and product id have to be added to > sys/dev/usb/usbdevs first? Also I just searched the linux sources for quirks > and neither found vendor and product id nor anything related to the > manufacturers (Ploytec GmbH and SPL). > Hi, Adding the vendor and product ID to usbdevs is correct. >> >>> b) Regarding the patch for issue 3., how would i post it for discussion >>> and >>> inclusion into FreeBSD? >>> Should i file a PR or just post it here on the list, inline (~30 lines) or >>> in an attachment? I couldn't find any policy on that for the mailing >>> lists. >> Filing a PR and referring it here is fine. If the patch is big, you >> might want to post it at differential revision at FreeBSD.org. > > I will file a PR then tomorrow, the patch is small (~30 lines). > >> >>> Mimicking the behaviour of macOS could be beneficial in general, i see a >>> lot of new class compliant audio interfaces coming out that are >>> explicitly tested with apple software (iPad compatible). >> >> It is not so good that the device dies on basic USB audio commands. It >> might indicate that the software has not undergone proper negative >> testing and that it might be possible to hack the firmware using the >> commands that timeout :-( Anyway I'm glad you got your device working >> improving the state of USB audio in FreeBSD and looking forward to a patch. >> >> --HPS > > I don't know how severe an issue like this is, but it is certainly not a sign > of thorough testing and robust implementation. Being realistic though, there > will always be devices tested and tailored to one of the popular OSes, not > according to standards. > All I want to say is that this situation is an opportunity to support more > devices out of the box, under the condition that the mimicked behaviour also > adheres to the standard. > You will probably see what I mean when reading the details of the patch. Looking forward to seeing your patch! --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68abf39b-7c6f-d9a9-bb6c-3cfeb2b569ea>