Focusrite Scarlett 18i20 2nd Gen mixer driver

[Michael Willis]

Hi all, I'm so sorry for the delay! I thought no-one was interested because I logged in LinuxMusicians occasionally and there was never a notification that someone had posted to the thread. Is there a better platform that we can do this on?

I'm somewhat interested, as somebody who might decide to purchase a 2nd-gen focusrite interface some day. Right now I'm using a first-gen 2i4, so I don't really have much to say on the topic, other than I agree that putting it on github (or maybe gitlab for idealogical purposes).

[Philotomy]

Yeah, I think a git repository on github (or gitlab or whatever) would be a good choice.

[geoffrey]

Thank you all for the advice. My code is now available at https://github.com/geoffreybennett/scar ... rlett-gen2 (applied onto Linus's v5.0 tag). You can see a diff at https://github.com/torvalds/linux/compa ... rlett-gen2

Answering some questions I missed before:

Looks like this is a fork of the Gen 1 code too.

Two questions:
1) Are you trying to keep backwards compatibility?
2) Can you give me a feeling for the major changes between v1 and v2?

I did start with the Gen 1 code and especially the diagram helped me figure out what was happening, but there's little in common now except that they're both ALSA mixer quirks. The USB mixer protocol is completely different between Gen 1 and 2.

I wasn't trying to keep backwards compatibility. I don't have a Gen 1 device to test with so I couldn't see what mixer controls were available to even try and keep compatibility.

[daeavelwyn]

@geoffrey : Does your code have some chances to be merged into the official ALSA repos ? I'm not good enough in compiling / tweaking linux stuff to find an easy way to make your code works with my system, but still wait for a convenient way to use scarlett 18i20 2ng gen internal mixer on linux, so, thanks for your work and sorry if I can't help more, not a lack of interest, more a lack of skills ... :-/

[geoffrey]

@geoffrey : Does your code have some chances to be merged into the official ALSA repos ? I'm not good enough in compiling / tweaking linux stuff to find an easy way to make your code works with my system, but still wait for a convenient way to use scarlett 18i20 2ng gen internal mixer on linux, so, thanks for your work and sorry if I can't help more, not a lack of interest, more a lack of skills ... :-/

Hi daeavelwyn,

I would hope there is a good chance that it would be merged, but I am guessing that the ALSA devs would probably like to hear from a few people reporting that it works first (I don't know; I haven't ever done this before).

To make it easier for you and others to test, I have built kernels for Fedora and Ubuntu. Please see: https://github.com/geoffreybennett/scar ... ag/v5.0.s1

The Fedora kernel works for me. The Ubuntu kernel at least boots but I don't have a Ubuntu desktop to see if the driver works. I used the instructions at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild to build it.

Here are the notes I wrote in the github release:

Test 1 of Focusrite Scarlett 18i20 Gen 2 ALSA mixer driver. To install (if you don't want to build from source):

- Fedora:

Code: Select all

sudo rpm -ivh kernel-5.0.0s1+-4.x86_64.rpm

- Ubuntu:

Code: Select all

sudo dpkg -i linux-image-5.0.0s1_5.0.0s1-1_amd64.deb linux-headers-5.0.0s1_5.0.0s1-1_amd64.deb

Then reboot and make sure to select the new kernel: "sudo reboot"

"alsamixer -cUSB" should show a whole lot more controls:

• Master volume knob indicator
• Volume controls for the 10 analogue HW outputs
• HW/SW volume switches for the 10 analogue HW outputs
• Output mux (where the sound for the HW outputs comes from; defaults to PCM outputs 1-20)
• Capture mux (where the sound for PCM recording comes from; defaults to HW inputs 1-18)
• Matrix mux (where the sound going into the mixer comes from; 18 inputs default off)
• Mixer matrix (18 inputs * 10 outputs = 180 controls)
• Mute and dim indicators

Also of note:

• The output, capture, and matrix muxes each have all inputs available to them (HW inputs, PCM outputs, and matrix outputs)
• The driver cannot load the configuration from the hardware so best to use "alsactl store" and "alsactl restore" to keep a copy of your configuration if you want to change the configuration later
• The driver will not reset the hardware configuration when it loads (only once you change something e.g. in alsamixer, and then only that bank of controls)

[pasik]

I would hope there is a good chance that it would be merged, but I am guessing that the ALSA devs would probably like to hear from a few people reporting that it works first (I don't know; I haven't ever done this before).

Good work, thanks a lot!

I'm not an expert on linux kernel development, but I think in general it goes like this, for audio/sound drivers:

- subscribe to alsa-devel mailinglist (if you haven't subscribed already).
- post your patch(es) to alsa-devel mailinglist for review, remember to add your Signed-off-by line. You can use for example "git-send-email" tool to post the patches to the ml.
- wait for other developers to review your patch(es).
- work with the other developers, and address all the requests for changes/improvements, and provide comments if there are any questions.
- re-send new versions of the patch(es) with the fixes/improvements included.
- wait for the patches to get ACK'ed by other developers/maintainers.
- repeat the previous steps as needed
- Once the patches are fully ACKed/reviewed, the alsa/sound maintainer (Takashi Iwai, iirc) will then apply the patch(es) to the patch queue / git tree which will be sent to Linus for inclusion in upstream Linux kernel during the next merge window.

Good luck

[moarg]

geoffrey, thank you so much for this effort.

TL;DR : works for me

Setup:

- 18i20 2nd gen brand new (received 2 days ago)
- Lenovo X230 laptop
- Debian 10 (Buster, current testing)

So, I built the whole kernel with make deb-pkg from your branch on GiHub, following the Ubuntu instructions you already linked earlier in this thread, and installed that deb...
For now, I have video driver problems with this kernel (should be unrelated), but testing with alsamixer (curses text mode) over SSH, I could give the internal mixer some testing: routing input1 (playing instrument) to the headphones.

Just took me a while to understand the settings, should have read your subsequent post.

So thanks again, and I hope you'll be able to upstream it to the mainline kernel.

[daeavelwyn]

And the result is : Geoffrey wins !!!! Your driver perfectly works for me on ubuntu mate 18.04 with your built kernel.

I only get this error while installing your driver :

Code: Select all

 update-initramfs: Generating /boot/initrd.img-5.0.0s1
W: Possible missing firmware /lib/firmware/i915/icl_dmc_ver1_07.bin for module i915

Not sure this is really significant...

So I can use it with alsamixer and qasmixer, but routing is stil a pita :-/ . I've tried to make this mixer works for me : https://github.com/x42/scarlett-mixer , compilation succeed, but can't get the soundcard recognize. Here is the output :

Code: Select all

./scarlett-mixer hw:2
scarlett-mixer: ./src/scarlett_mixer.c:603: get_enum: Assertion `snd_mixer_selem_is_enumerated (c->elem)' failed.
Abandon (core dumped)

So, thks for your work, if you could find the time to have a look at the x42 mixer it will really help to make the internal routing more friendly !

[geoffrey]

Thanks pasik for writing that info up. I'll send my patch through to alsa-devel soon.

Thanks moarg and daeavelwyn for testing. I definitely can't help with video driver issues though; my patch only touches USB audio.

"routing is stil a pita :-/" ooh yes. My patch only makes it *possible* to do the routing/mixing/metering in Linux; it's the basic building block on which a mixer interface like scarlett-mixer or AlsaJsonMixer can be built.

There is no chance of me getting scarlett-mixer working (I did have a look at it and couldn't figure it out). It uses hard-coded offsets, and the ALSA mixer controls I expose are arranged differently to the v1 controls.

[pasik]

Thanks pasik for writing that info up. I'll send my patch through to alsa-devel soon.

Np. If you want to have some references, see here (random month of the mailinglist archives):
https://mailman.alsa-project.org/piperm ... hread.html

Example patch series from that Sep/2018 mailinglist threads page :
"[alsa-devel] [PATCH 00/15] Add support for Sound BlasterX AE-5":
https://mailman.alsa-project.org/piperm ... 40379.html

That patch series seems to have been prepared well, and got applied pretty much immediately:
https://mailman.alsa-project.org/piperm ... 40425.html

Looking forward to seeing your patch(es) on alsa-devel

[geoffrey]

Thanks pasik for writing that info up. I'll send my patch through to alsa-devel soon.

Np. If you want to have some references, see here (random month of the mailinglist archives):
https://mailman.alsa-project.org/piperm ... hread.html

Example patch series from that Sep/2018 mailinglist threads page :
"[alsa-devel] [PATCH 00/15] Add support for Sound BlasterX AE-5":
https://mailman.alsa-project.org/piperm ... 40379.html

That patch series seems to have been prepared well, and got applied pretty much immediately:
https://mailman.alsa-project.org/piperm ... 40425.html

Looking forward to seeing your patch(es) on alsa-devel

Thanks again! I have now reformatted my patch and written the email (then noticed again a couple more whitespace fixes ).

Do you have an 18i20 2nd Gen? Are you able to confirm if it works for you? Would you mind reading through the patch? My remaining concerns that will go into the email (unless you have suggestions) are:

• I added a private field to struct snd_usb_audio for storing the private mixer data. This seems wrong, but I didn't know where I should put it.
• I've #define'd the vendor-specific interface, endpoint, max_data, and interval values. Is it okay to leave these hard-coded (they match the values provided by lsusb -v; I presume they never change?), or should they be looked up at runtime instead?
• I'm not sure if those snd_printk()s for unexpected responses from the hardware should be left in there.

Has anyone else out there listening had success with the driver? I have uploaded a second release to github: https://github.com/geoffreybennett/scar ... g/v5.0.5s2
This makes the meters work better by sending the mux data in the same order as the Windows driver (I'm using "watch -n0 'amixer -cUSB cget numid=265'" for testing). I also decided to not implement the "todo" that I had for sending the meter data in dB instead of the raw (linear) numbers returned by the hardware. Probably better to do that conversion in user-space.

[geoffrey]

Looking forward to seeing your patch(es) on alsa-devel

After a few more minor fixups... Done!

[Jorin]

Hello! I compiled your kernel from the GitHub branch on Manjaro (Arch Linux based). Unfortunately I'm having no luck.

Code: Select all

alsamixer -cUSB

just says

Code: Select all

cannot load mixer controls: Protocol error

. Dumped some basic info here: https://gist.github.com/jorins/12779bcb ... f7b0e6a6d1

Let me know what more you need to know, or what I'm doing wrong :3

[geoffrey]

Hello! I compiled your kernel from the GitHub branch on Manjaro (Arch Linux based). Unfortunately I'm having no luck.

Code: Select all

alsamixer -cUSB

just says

Code: Select all

cannot load mixer controls: Protocol error

. Dumped some basic info here: https://gist.github.com/jorins/12779bcb ... f7b0e6a6d1

Let me know what more you need to know, or what I'm doing wrong :3

Hi Jorin,

I don't think you're doing anything wrong. It appears that your interface isn't responding to my driver's attempt to say "hi!" to it . In the log you provided, it says "result command 0" (that's the initialisation request) "was -110" (that's a timeout).

A couple of things that could help me debug this:

1) Please send me the output of "lsusb -v 1235:8201".

2) You can capture USB bus traffic by running "usbmon -fu -s 10000 | grep -v 'Z[io]:'". If you could capture the first second of data when you plug in your interface then I can compare that against what I see. It will look something like this:

Code: Select all

ffff967ac994e900 1413982320 S Ci:2:081:0 s 80 06 0100 0000 0012 18 <
ffff967ac994e900 1413982401 C Ci:2:081:0 0 18 = 12010002 ef020140 35120182 3b040103 0202
ffff967ac994e900 1413982431 S Ci:2:081:0 s 80 06 0200 0000 0009 9 <
ffff967ac994e900 1413982487 C Ci:2:081:0 0 9 = 09029002 060103c0 00

In the above example, the "2:081" is the bus and device number (as reported by "lsusb"). You can use the "-i" argument to lsusb to filter for only messages on a specific USB bus to reduce the amount of output.

Somewhere in your output there's going to be a line like this:

Code: Select all

ffff967cd03f93c0 1414026647 S Co:2:081:0 s 21 02 0000 0005 0010 16 = 00000000 00000000 00000000 00000000

Ignore the random numbers at the beginning of the line. The "21 02 0000 0005 0010 16 = 00000000 00000000 00000000 00000000" part is the initialisation request. If you see that in your capture then you know you've captured the right thing. I'm interested in everything up to that point, and whatever follows it up until you get the "result command 0 was -110" error (I'd expect it to be about 150 lines worth of stuff).

Thanks,
Geoffrey.

[Jorin]

[...]

Outputs here: https://gist.github.com/jorins/46bce342 ... 2feacd7243

I don't have any usbmon executable, but I was able to find /sys/kernel/debug/usb/usbmon and it appears to be the output you were looking for.