Date: Mon, 24 Dec 2018 01:43:26 +0100 From: Florian Walpen <dev@submerge.ch> To: freebsd-usb@freebsd.org Subject: Re: SPL Crimson (rev 1) and snd_uaudio Message-ID: <5738623.nAnukg6brD@z800> In-Reply-To: <569736da-5b33-44cb-4ad8-2986b38c10d0@selasky.org> References: <1898371.YXp4yczo3S@z800> <569736da-5b33-44cb-4ad8-2986b38c10d0@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). > > > 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. Thanks again Florian Walpen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5738623.nAnukg6brD>