Open geoffreybennett opened 2 years ago
I can't entirely figure out what "Extension Unit Switch" and "Keep Interface" are about, but I don't think they're relevant to this application. I'm still after answers to the other questions though.
'Sample Clock Source' seems to change 'Scarlett 18i20 USB-Sync Clock Source' as well but 'Scarlett 18i20 USB-Sync Clock Source' can be changed independently of 'Sample Clock Source.' The 'Scarlett 18i20 USB-Sync Clock Source' seems to be able to set the 'Sample Clock Sync Status' to locked. 'Sample Clock Source' does not impact the lock status at all.
Please, this would be immensely useful. I have an 18i8 Gen1 that simply doesn't play ball with Linux, and I thought this was the solution.
I have a 18i20 1st gen. Maybe the Master Playback sections are related to the Monitor Sections in the MixControl app for Windows.
In such section of MixControl there's a big volume control, which can be set to influence the volume of any combination of the 10 outputs (for each output, one can set whether it's either infuenced by the control, muted or independent from such control). Since there's a physical knob on the interface, one can chose whether the monitoring volume is controlled by that physical knob or the software one.
In the same section there are DIM, MUTE, LMUTE, RMUTE, MONO buttons. All affecting the monitor level.
Hope this helps, I'll continue to poke the interface to understand better, let me know if you need anything. Also, if you come up with a tentative change for supporting the interface in some separate branch, I can try and test it.
Hey, I have a first-gen 18i6. Here's a gist with my asound.state file contents: https://gist.github.com/jaredhirsch/818bba0fc2973514a1e95992205540a7
Also, now that I think about it, there's a 2012 focusrite linux support blog post that goes over some details of the VIDs and PIDs, and was written by @dvhdr who seems to still work at Focusrite. I wonder if he might be able to answer some of your questions in the bug description?
Hi there, just curious if support for gen1 is still in the pipeline or has it been abandoned?
It's on the backburner right now, but someone has said they are sending me one, so if that arrives then it will make it a lot easier to do.
Great! thanks for the response and looking forward.
I have a gen1 scarlett 2i2. Let me know if you need any data from it!
@eb0687 I've got a Gen 1 18i6 now. I've had a bit of a play with it, with some success. I'm also working on Gen 4, Vocaster, and firmware update support so it might take some time, but I'll get there! :)
@pinpox The 1st and 2nd Gen Scarlett Solo, 2i2, and 2i4 have all their controls accessible from the front panel of the device, and there are no proprietary software controls, so no need for any kernel support or control software. Ref: https://support.focusrite.com/hc/en-gb/articles/207547145-Does-my-bus-powered-Scarlett-Solo-2i2-2i4-4i4-require-Scarlett-MixControl-or-Focusrite-Control-
@geoffreybennett Quoting from the link:
To change buffer size and sample rate go to the audio preferences in your DAW (Mac) or open the ASIO Control Panel application on your Windows PC.
I have not been able to do that on linux, maybe I'm looking at the wrong place. My interface had very crackling/distorting microphone sound and I was only able to fix it by booting windows and setting the buffersize to a higher value in the focusrite software. Being able to set this, was what I was hoping I could do with this GUI. Not sure if I'm missing something or looking in the wrong place, if there already is a possibility to set buffersize and sample rate from linux please let me know.
Hi @pinpox,
No this GUI won't help with that. This GUI is only for the Focusrite-specific controls, which are independent of the audio I/O.
Buffer size and sample rate can be controlled by whatever application is talking to ALSA, which is going to be one of these sound servers:
I'd suggest asking at the LinuxMusicians forum for advice on this.
Regards, Geoffrey.
Extension unit is driving me nuts. It seems like activating "extension unit 1" disables my DAW recording input. I am trying to disable the direct monitoring but am having no luck. "Extension unit" doesn't do anything from what I can tell.
Thanks for looking into gen 1 support - Here's a state file from a 1st gen 8i6 - I don't have any particular issues with this under linux in my (fairly basic) usage patterns 8i6_asound.state.tar.gz
Also waiting for this to be implemented, the device is recognized but won't let me have control over the output for spdif. So far I've tried alsamixer and qasmixer without luck. Thanks for the hard work, let me know if I can help somehow.
Hi @ALi3naTEd0, if alsamixer is unable to control the spdif output, then that's a kernel driver problem, not something that can be fixed by this GUI, which is only a pretty front-end to the same controls that alsamixer has access to. The 1st Gen 18i6 has spdif output, so I'll be able to check if it works or not.
I wish I understand more since I switched to Linux 2 months ago, but back on Windows, I used to have to manually select "SPDIF" somewhere in the MixControl, so I'm guessing I need to do something similar here, just not sure what exactly since SPDIF is kinda tricky. Thank you very much @geoffreybennett
Hi @geoffreybennett, I have a 1st gen Scarlett 18i8 laying around which I've been playing with a bit recently. I'm able to do everything (that I tried so far) via alsamixer, so I suspect adding support for this interface would be relatively easy. Is there anything I can do to help with this FR? (alsactl state files or similar?)
Thanks for your great work!
Hi @nexus-os, correct, adding support "shouldn't" be too hard. Since I've got an 18i6 now I don't need anything but time. My free time at the moment is going towards Gen 4 GUI support and Vocaster support as promised to the people who donated for that. Once I've finished those then I can work on the Gen 1 support.
Hi @nexus-os, correct, adding support "shouldn't" be too hard. Since I've got an 18i6 now I don't need anything but time. My free time at the moment is going towards Gen 4 GUI support and Vocaster support as promised to the people who donated for that. Once I've finished those then I can work on the Gen 1 support.
Hello Geofrrey, I am new here but my problem is old as all others here! I have a Gen 1 18i20 and would love to get my ADAT configured as it is possible now (thanks to your hard work) in latest Gen's. I would appreciate a lot to see my scarlett working on Linux as in MacOS. Thank you so much once more. Cheers Kata
Hi all, a little update... I just released 0.4.0 which completes the 4th Gen support and adds initial Vocaster support, so I will start working on the 1st Gen devices more now. A generous donor sent me a 1st Gen 6i6 so I now have two 1st Gen devices to test with.
@AquaMorph @sonicdebris @kataventos can one of you please attach here the file generated by alsactl -f scarlett-gen1-18i20.state store
? The 1st Gen 18i20 file that someone sent me was actually a 1st Gen 18i8.
Here is mine: scarlett-gen1-18i20.state.zip
Thanks @burt777! Stay tuned!
Okay, first rough draft of Gen 1 support is pushed on the dev branch for the adventurous people.
Big note:
sudo alsactl store
will save the settings, to be automatically loaded whenever you plug in your interface. So, be aware you'll want to either twiddle every knob & press every button so that what you see matches the interface, or do File→Load Configuration or run alsactl restore
from a saved configuration if alsactl
isn't automatically doing a restore when you plug your interface in.Small note:
I tested with Gen1 18i8 on a Opensuse TumbleWeed (kernel 6.8.1) on a x86_64 and on a raspi5 with raspi-os (kernel 6.6.20).
18i8 directly recognized on both systems, could switch Inst/Pad, I tried to set before Inst/Pad on #1 with the scarlett-mixer from Robin Gareus. On the first start of alsa-scarlett-gui it recognized the enabled Inst/Pad on #1. Could select the Clock source, but N/A on the Sample rate on both systems.
Routing and Mixer seem to work ok, Levels are greyed out on both, startup shows this:
Sample rate came up when i fired up jack... ;-)
Just tried the dev branch with the 18i20 gen1 on OpenSuse Tumbleweed (kernel 6.8.1), but I don't get the "Analogue inputs section"
* Limitation of the kernel driver (maybe of the hardware, I don't know): **The driver cannot read the configuration from the interface**, so until the ALSA controls are written to (either automatically or manually), the state shown in the interface is unlikely to reflect the actual interface state. Maybe `sudo alsactl store` will save the settings, to be automatically loaded whenever you plug in your interface. So, be aware you'll want to either twiddle every knob & press every button so that what you see matches the interface, or do File→Load Configuration or run `alsactl restore` from a saved configuration if `alsactl` isn't automatically doing a restore when you plug your interface in.
I always thought that was a kernel driver limitation. All my scripts first do an alsactl restore Scarlett18i8 -f allmuted.conf
which is a config with everything muted, all sliders at the bottom, and all other controls set to Off. That was the only way I could guarantee that all controls would actually be set. It seems the driver didn't know what the state of the hardware is until it sets it itself and if it doesn't think a control needs to be changed, it doesn't set it and the hardware remains at whatever setting it was before.
It probably need kernel changes. I did a bit of poking around with wireshark (https://wiki.wireshark.org/CaptureSetup/USB and sudo tcpdump -i usbmon3 -w /tmp/usb-focusrite.mastervol.pcap
and then analyzing the traces with wireshark. There is definitely traffic when e.g. turning the master-volume knob (Class-specific Audio Control Interface Descriptor: Extension unit descriptor
) and it seems to be proprietary extensions.
@tithrion
Sample rate came up when i fired up jack... ;-)
Hover your mouse over the sample rate display & check the tooltip. I wrote that for you ;)
Also, those mute buttons look rather awful. Could you pull the dev branch & see if I managed to fix it?
@ensonic
Just tried the dev branch with the 18i20 gen1 on OpenSuse Tumbleweed (kernel 6.8.1), but I don't get the "Analogue inputs section"
There are no such controls that I could find in the kernel driver, and I think that's correct — I don't believe that there are any such controls in the interface. What are you expecting to see there?
@ThubLives
I always thought that was a kernel driver limitation. All my scripts first do an
alsactl restore Scarlett18i8 -f allmuted.conf
which is a config with everything muted, all sliders at the bottom, and all other controls set to Off. That was the only way I could guarantee that all controls would actually be set. It seems the driver didn't know what the state of the hardware is until it sets it itself and if it doesn't think a control needs to be changed, it doesn't set it and the hardware remains at whatever setting it was before.
Oh, that's really terrible behaviour on the part of the kernel driver. If the driver thinks that a control is "Off" but it's actually "On", you can't set it "Off" without first setting it "On"!
The interface firmware might not have implemented any way that the driver could read its state. Unless it does support this and we discover how to do it, I can't yet think of a good way to solve this problem.
@geoffreybennett
Also, those mute buttons look rather awful. Could you pull the dev branch & see if I managed to fix it?
Yes:
@ensonic
Just tried the dev branch with the 18i20 gen1 on OpenSuse Tumbleweed (kernel 6.8.1), but I don't get the "Analogue inputs section"
There are no such controls that I could find in the kernel driver, and I think that's correct — I don't believe that there are any such controls in the interface. What are you expecting to see there?
If the 18i8 has it (https://github.com/geoffreybennett/alsa-scarlett-gui/issues/33#issuecomment-2027603652), I was hoping that the 18i20 would have it too, since the hardware buttons exist. But you are right amixer -D hw:4 controls
does not show them, I'll take another look at the driver.
@ensonic Latching buttons (which I think the 1st Gen 18i20 Inst and Pad buttons are) control hardware directly — once toggled, they change and maintain the hardware's state independently of software. Try this experiment to check for sure: 1) Choose one of the Inst/Pad buttons and note the state of the corresponding LED 2) Power off your interface 3) Press your chosen button while the device is off 4) Power on your interface 5) If the LED's state has changed, it confirms the button is a latching type.
The 2nd Gen 18i20 similarly has latching buttons and no software control. On the other hand, the 1st Gen 18i8 has software controls because it doesn't have any hardware controls.
On the third hand, momentary switches like the 3rd Gen 18i20 Inst/Pad buttons don't maintain their state. They signal the interface's microcontroller to change the state when you push them, and that is what allows for control from both the front panel and over USB.
@geoffreybennett
It seems the driver didn't know what the state of the hardware is until it sets it itself and if it doesn't think a control needs to be changed, it doesn't set it and the hardware remains at whatever setting it was before.
Oh, that's really terrible behaviour on the part of the kernel driver. If the driver thinks that a control is "Off" but it's actually "On", you can't set it "Off" without first setting it "On"!
To be clear, I only really noticed this behaviour with the volume levels, but as I was making an "all sliders to -Inf" config anyway, I went ahead and set all the switches and selectors to "Off" or something else that was different than the hardware defaults.
@geoffreybennett
What do these controls do:
- 'Extension Unit Switch' (and why are there two?)
This is for additional channels through ADAT. The Optical In on the back (one on the 18i8 and two on 18i20, which I bought and returned years ago when I realised I only needed the 18i8) are used for 4 additional channels at 44.1/48 KHz or 2 additional channels at 96 KHz for each port.
EDIT: I'm pretty sure that should be 8 channels at 44.1/48 KHz or 4 channels at 96 KHz on each ADAT input.
From what I could tell, both units have the same core mixing processor but different firmware and so actually has more mixing capability than is available out-of-the-box. As for what the 'Extension Unit Switch' actually does in the driver, I can only guess because I've never used ADAT with either 18i8 or 18i20, but my guess is that it has something to do with reconfiguring the mixer matrix to accommodate more channels.
- 'Keep Interface'
This was added to the kernel driver sometime in 2019 which forced me to recreate all my config files because suddenly the controls didn't line up anymore. Again I am only speculating here, but my guess is that it has something to do with the internally stored configuration.
The last time I had a serious play with the Windows software was years ago, but I noticed that at power on the device loads settings from an internal storage of some kind, which is a pretty powerful feature for a power-on and forget setup. Once USB is connected however, it would reset to some other internal default set (either coming from firmware or from the Windows drivers) and relied on the proprietary mixer software to manage it thereafter.
That software also had "Save to hardware" and "Load from hardware" menu options which would write the current mixer settings to that internal storage or read those settings from internal storage and apply it to the active device configuration. So the power-on settings were different than the software mixer settings because USB activation would change the setup and the settings saved to the hardware were only effective before USB was plugged in for the first time.
Again, what this control actually does is a mystery, but if I had a Windows machine around, that's what I would look into.
@geoffreybennett
And regarding the "Master Playback Switch" controls...
- 'Master Playback Switch' - is this master-mute? in addition to the individual stereo output mutes?
Yes.
- 'Master Playback Volume' - master volume? does this control and the individual stereo output controls get multiplied together, as if they are in series? so e.g. you need Master Playback Volume AND Master 1 Playback Volume to be turned up in order to hear anything out of Line 1/2 outputs?
Correct. At least for the 18i8 Gen1.
@ensonic Latching buttons (which I think the 1st Gen 18i20 Inst and Pad buttons are) control hardware directly — once toggled, they change and maintain the hardware's state independently of software. Try this experiment to check for sure:
- Choose one of the Inst/Pad buttons and note the state of the corresponding LED
- Power off your interface
- Press your chosen button while the device is off
- Power on your interface
- If the LED's state has changed, it confirms the button is a latching type.
The 2nd Gen 18i20 similarly has latching buttons and no software control. On the other hand, the 1st Gen 18i8 has software controls because it doesn't have any hardware controls.
Thanks for suggesting the test. The "pad/inst" buttons are indeed latching type buttons. And they are also represent their state not only through the led, but also in the pressed state, the button is lowered.
On the third hand, momentary switches like the 3rd Gen 18i20 Inst/Pad buttons don't maintain their state. They signal the interface's microcontroller to change the state when you push them, and that is what allows for control from both the front panel and over USB.
The master dim/mute are just push buttons and according to the screenshots of the windows software they should be usb-controlable: https://fael-downloads-prod.focusrite.com/customer/prod/downloads/Scarlett%2018i20%20Bedienungsanleitung%20Deutsche%20-%20DE.pdf#page=20
But since there are no controls for them this part is probably missing in the driver (same as the whole monitoring section aa per pdf starting from page 28).
Sorry for the noise.
That software also had "Save to hardware" and "Load from hardware" menu options
How sure about that "Load from hardware" option are you? I'm not seeing such a thing (if it existed previously, maybe they removed it? maybe it's only on some models?):
Can anyone else find this option? If it exists, that would be fantastic.
suddenly the controls didn't line up anymore
How does that work? Are you using the numid values shown by amixer controls
? They can change between kernel versions and should not be relied on between reboots. Better to use the control name which is going to be more constant.
Once USB is connected however, it would reset to some other internal default set (either coming from firmware or from the Windows drivers) and relied on the proprietary mixer software to manage it thereafter.
I tried this. It keeps its previously-saved values until you start MixControl. I think since it can't read from the hardware it loads up the previous config that it had.
How sure about that "Load from hardware" option are you?
Certainly less sure than I was when I posted about it. Most of my knowledge about how this worked on Windows was from years ago when I bought this thing. I don't have a Windows system now to test any of this.
suddenly the controls didn't line up anymore
How does that work? Are you using the numid values shown by
amixer controls
? They can change between kernel versions and should not be relied on between reboots. Better to use the control name which is going to be more constant.
My workflow here was pretty crude. I would use QasMixer to set everything up how I liked it, then I'd do an alsactl store
to dump the config as a preset. Then I would use a simple script to alsactl restore
to the "All Muted" config that I mentioned, followed by another alsactl restore
for the actual preset I wanted with a pause in between to allow things to settle.
Simply using alsactl restore
meant that any significant change to the kernel driver would result in an error and I would have to recreate all my presets. I had to do this at least three times, but only once because the controls changed.
Once USB is connected however, it would reset to some other internal default set (either coming from firmware or from the Windows drivers) and relied on the proprietary mixer software to manage it thereafter.
I should have mentioned that I am working from memories from around 2015. As rigorously as I felt my testing was and as vivid as those memories are, I would concede to what you're seeing there.
By now I am convinced 18i20 Gen1 is a hopeless case wrt the extra functions (output section, pad & inst, dim & mute):
lsusb | grep Foc
Bus 003 Device 002: ID 1235:800c Focusrite-Novation Scarlett 18i20
# Bus3 --> usbmod 3
sudo modprobe usbmon
sudo tcpdump -i usbmon3 -w - -U | hexdump -C
Note, need to run something, e.g. ./src/alsa-scarlett-gui to see traffic, most devices otherwise might not proactively send data.
In any case whatever I do on the hardware controls shows no usb traffic, only the periodic reads from alsa-scarlett-gui.
Thanks for making my 1. Gen 6i6 great again! Working fine with Ubuntu Studio 23.10 and PipeWire 1.0.3
Tip: do a 'make depclean' if compiled for master first and make on dev fails.
I just build from source on dev
and it works like a charm!
Tip: do a 'make depclean' if compiled for master first and make on dev fails.
Thanks, that was a good tip!
It seems the driver didn't know what the state of the hardware is until it sets it itself and if it doesn't think a control needs to be changed, it doesn't set it and the hardware remains at whatever setting it was before.
I just ran an experiment where I briefly connected my 1st Gen 18i8 to a Mac and opened the official Scarlett GUI. Just opened it, I didn't touch any button or slider or anything. Then went back to my Debian machine and the settings indeed had changed (and alsa-scarlett-gui couldn't tell).
I suspect that Focusrite's own software works around the issue by blindly applying the last known configuration on startup. Perhaps it would be fair game for alsa-scarlett-gui to do the same?
@ThubLives's tip to first apply "zero" state and then the desired one works well :+1:
(Thank you so much for your work!).
Hi @pablobm,
I believe that you're correct about how the official Scarlett software works. I also think it would be fair game for alsa-scarlett-gui to blindly apply a default configuration on startup, but I don't think there's any way to tell if the controls have already been initialised. It wouldn't be good to do it every time you load alsa-scarlett-gui because the interface might have already been configured. Perhaps this sort of thing can be done with the alsactl service or with a UCM profile?? See https://www.alsa-project.org/alsa-doc/alsa-lib/group__ucm__conf.html under "Boot (alsactl)".
I also fear that there is not a single "zero" state that will work in every circumstance. Imagine this scenario:
Ugh. The best solutions I can think of are:
(I don't think they're very good solutions, but they're the best I've got so far)
Regards, Geoffrey.
I also fear that there is not a single "zero" state that will work in every circumstance. Imagine this scenario:
If we're going to apply some kind of (useful) default set of values, then we should know what "zero" values we can apply for each control. It would stand to reason that any togglable/binary control should first be set to the opposite state to what our default state indicates. Then we can be sure that the default state is applied. Likewise, if any volume fader should be set to 0 (-Inf) when applying the default values, then we should set it to the nearest value (i.e. 1) before setting it to the final value of 0.
For other controls with multiple possible states I'm not sure what the implications are of switching to random values before setting it to a final value. The sync settings on my 18i8 Gen1 comes to mind, but I suspect the impact would be negligible.
The issue of how to reliably apply this default state as a one-time operation remains, but I played with running a script with a udev rule to do just this, but udev rules make my head hurt and I gave up. Still, if we can make this happen when the device is first attached to the system, that would be ideal.
Support for Gen 1 devices can be added. I have alsactl state files from 18i8 and 18i20 but need state files from the other interfaces, and I have some questions:
What do these controls do:
And regarding the "Master Playback Switch" controls...