18i8 Scarlett - This card can't output sound. But, the proprietary options apears and works for Alsamixer
mikefaille opened this issue · 33 comments
I'm able to install the driver without issue.
I use the branch v5.11-scarlett-gen3 and I configure the module with those options :
options snd_usb_audio device_setup=1,1,1,1
options snd_usb_audio vid=0x1235 pid=0x8210 device_setup=1
options snd_usb_audio vid=0x1235 pid=0x8211 device_setup=1
options snd_usb_audio vid=0x1235 pid=0x8212 device_setup=1
options snd_usb_audio vid=0x1235 pid=0x8213 device_setup=1
options snd_usb_audio vid=0x1235 pid=0x8214 device_setup=1
options snd_usb_audio vid=0x1235 pid=0x8215 device_setup=1
Without this driver, it works perfectly after configuring the sound card using Windows 10 + VMWARE then after using the device under Linux.
With the patched module, I also tried to configure the sound card under windows with a basic configuration under Linux using Jack and it doesn't work.
My kernel version :
Linux pop-os 5.11.0-7614-generic #15~1618626693~21.04~ecb25cd-Ubuntu SMP Thu Apr 22 15:59:53 UTC x86_64 x86_64 x86_64 GNU/Linux
The git hash used for this module : b802378
Branch : v5.11-scarlett-gen3
Here is my alsa config if it could be usefull :
Here is my Jack configuration :
@HinTak Please, ask me the information you may need to debug it. I would be glad if it's work. I'm already happy to get all the proprietary options working without Windows !
Fine, I just deleted my /var/lib/alsa/asound.state and it works after reboot !
Everything is fine, the driver seems flawless !
Was there any messages in dmesg or /var/log/kern.log or /var/log/* ? (Don't know what pop-os distro is). On hindsight it is probably obvious that alsa got confused by left over states from the non-patched driver. Would be nice to get the new driver code to drop / auto-correct any wrong and left over settings though; if it is possible.
@mikefaille if you have the patience, or the next time you upgrade, etc, dump the listing of amixer settings with "amixer contents -c N" and "amuser scontents -c N" where N is your scarlett device number.
Before and after breakage...
@HinTak I would help as much you need me ! I will do that tomorrow. You just need to ask and I cooperate. I want this driver on the mainline kernel.
I got the same problem again !
I backuped my asound state before Deleting it but it doesn't repair the sound stack with alsa. I did tried to route the sound directly from an Analogue in to an Analogue out and it doesn't work more. I prepare some detail to prove i'm fine with my configuration.
Also, I just realize the issue occur when I use the option speaker switching and I turn it from off to main after I switch the option to off.
Here, there is a video proving everything is fine on my side. Because you may not understand my english, I would describe how I make sure everything is ok on my side. First, I realize the sound wasn't working as usual using alsa + jack + my external synth. (after I turn on and off the configuration speaker switching).
Then, what I show on my video is the following configuration to simplify the test : I route directly Analogue 3 in to Analogue 1 out. During my test, I give the proof my synthesizer is suppose to the sounds to the Scarlett in Analogue 3 in. Also, trust me, I never touch to my speaker cable of volume. There is also a light on them to show they are on. Here is the video :
https://www.youtube.com/watch?v=x1qBuWkFJtI
During this video demonstration, here is my alsa config :
Finally, I think it's important to mention that I did use the option speaker switching on my initial issue I got here the first time. I didn't reported I did use the speaker switching parameter because I didn't know it could be linked to my issue.
To fix it, it may not be erasing the /var/lib/alsa/asound.state that changed something but doing a factory reset from the official software from my Windows VM. It should not be related to alsa because the actual issue is during direct routing from an Analogue in interface to an Analogue out interface. I believe then the driver may have corrupt the firmware or changed an option not well understood.
As last note, when I use the switch speaker switching it reset all my hardware configurations from what I see from Alsa configs. I believe the driver may not cover well some parameter on the Scarlett firmware.
Now, I would try to fix the card reseting it and use the option speaker switching again to reproduce the issue.
Now, I would try to
fixthe card reseting it and use the optionspeaker switchingagain to reproduce the issue.
I did it, and the Microphone works under Windows if I use the direct connection betweenAnalogue 1 intoAnalogue 1 out.
But, it still doesn't work under Linux. Actually, I found no way to recover the output. Strangely, since it's a direct connection, it should work under Linux. Also, when I configure Analogue 1 in to Analogue 1 out my speaker clicks buy from the microphone no sound.
To permit the upload, I added the .log to my asound.state. The one I backup-ed initially. Even it doesn't work with an hardware direct routing between 2 interfaces, I upload the alsa state since the same direct routing configuration works under windows but not under linux.
asound.state.log
Oh ! if I factory reset the sound card from Windows, when I connect the card to linux, it reload my configuration as my Air parameter to Analogue in 1 become amber.
Ok, I found how to fix this issue. The minimal sequence :
- Associating the Scarlett to a Windows VM
- Sending factory reset on Windows using the official software.
- Reinitialize the Alsa state on Linux (during the time the card is dedicated to the Windows VM or Alsa may corrupt the card if the alsa state is bad !). a) removing the alsa state
/var/lib/alsa/asound.state. b) Applyalsactl init. - Disconnect the card from Windows. (To get the card detected, sometime I need to turn the power switch of the Scarlett
offthenon) - Test the card on Linux and everything work as expected!
Here is the alsa state when I can get my direct connection of my microphone Analogue in 1 to my speaker Analogue out 1
asound.state.working.log
I also reproduce the bug for the 3rd time.
Here is the minimal sequence :
speaker switchingfromofftomaster. It reset all configuration of my card at this point.- When
speaker switchingis configured atmastereverything seems working. - When I turn
offspeaker switching, I plugAnalogue 1 intoAnalogue 1 outbut when I speak on my microphone it doesn't work !
Here is my alsa state right after this sequence (after configuring my microphone Analogue in 1 to my speaker Analogue out 1) :
asound.state.bad.log
Paradoxically.... the mute setting is inverted...
Ok, now, the switch mute/unmute does not work anymore. It means are it's always unmute.
Here, it's the last version of my working setup.
asound.state.good.2.log
@mikefaille does dmesg show anything interesting? Some of this behavior looks rather random/indeterministic.
Cc @sadko4u you probably have a better idea of what to do?
The Speaker switching works in interesting way for Scarlett devices.
As far as I remember, it automatically mutes non-used pair of ouputs.
I mean, If you use 'Main' speaker switching option, then outputs 1 and 2 should be working but outputs 3 and 4 should be muted. For the 'Alt' speaker switching the situation is opposite: 1 and 2 become muted but 3 and 4 work well.
For the 'Off' speaker switching you may use outputs 1-4 as you wish.
The mixer implementation from my version of driver automatically restores the state of device from so-called 'Software configuration area' stored inside of the Scarlett device. So actually you are not required to store the ALSA configuration for your device at all since the device stores it inside. And I think sometimes it may yield to unexpected behaviour due to the conflict of 'internal' state of the device and saved ALSA configuration of the mixer.
The main problem is that configuration for 18i20 device and 18i8 device is a bit different respective to internal mixer/router and input/output port mapping. That's why I'm currently crowdfunding money for purchasing the 18i8 device. In some cases the mixer/router seems to be working improperly.
😱 I just discovered that my sound outputs (1 & 2) work because : my sound is on mute according alsamixer!!!
Paradoxically.... the mute setting is inverted...
Ok, now, the switch mute/unmute does not work anymore. It means are it's always unmute.Here, it's the last version of my working setup.
asound.state.good.2.log
As a note, the parameter speaker switching was off for this test.
If you need pcap, please poke me.
There's nothing to look in the dmesg. For the detailed information there's a debug version of the driver with debug output inserted into code:
https://github.com/sadko4u/focusrite-scarlett-backports/blob/master/debug-drv/mixer_scarlett_gen2.c
@sadko4u I will install this one for tomorrow.
There's nothing to look in the dmesg. For the detailed information there's a debug version of the driver with debug output inserted into code:
https://github.com/sadko4u/focusrite-scarlett-backports/blob/master/debug-drv/mixer_scarlett_gen2.c
I haven't looked yet, but it is customary to do just include debug statements either at compile time (with preprocessor macro #if DEBUG) or dynamic with pr_debug(). The latter are skipped in normal kernels, but can be selectively enabled with dynamic debugging at runtime. (most desktop distro kernels are - the only exceptions I notice lately arw those shipped by Raspbian)
@mikefaille @sadko4u I have managed to move this issue to the split out scarlett sound-usb kernel-module repo (you should get notification of this message from the new location); and I have merged all the debug code into here too - found one bug with the debug version of the driver ( sadko4u/focusrite-scarlett-backports#8 )
and one bug with the production version of the driver while merging ( sadko4u/focusrite-scarlett-backports#2 is in the debug version but sadko4u/focusrite-scarlett-backports#3 is not yet in the production version) . I don't know if either are important, since I don't have the hardware, but the current state of this repo should be better than either now.
To enable debugging, insert a single line "#define DEBUG 1" at the top of sound/usb/mixer_scarlett_gen2.c before compiling.
@sadko4u having looked at the debug code, yes, I think they should be removed completely before submitting upstream. Also, many of the statements are simply about reaching specific routines or specific points in the code, and can be replace by the generic usb_audio_info(mixer->chip, __FUNCTION__); or usb_audio_info(mixer->chip, "%s line %d", __FUNCTION__, __LINE__); etc - I think writing them in these ways would make it more obvious they are debug only, as well as easier to ignore for being generic too. Changing them to usb_audio_dbg() would automatically enable dynamic debugging on systems where dynamic debugging is available; but anyway, I think most of them should be removed completely in the long term rather than converted from usb_audio_info to usb_audio_dbg.
I have updated the 'v5.12-sound-master' branch as the default, which also contains two post-submission fixes (one for 18i8 gen 3). People should use that branch now.
It sounds like the code submitted upstream + the recent fixes should address this? Anyway, the sound master branch is tracking what is in the sound maintainer's tree, and probably should be used until / unless there is any substantial further work to be included.
"It sounds like the code submitted upstream + the recent fixes should address this?"
I'm not sure if there is anything to fix. When you turn Speaker Switching Off, the global mute is activated (this is normal behaviour as per the Focusrite manual) and you need to deactivate the mute using alsamixer/qasmixer or using the mute button on the interface (18i20 only). It is very confusing for the 18i8 because there is no physical mute button/indicator.
@mikefaille The screenshot from your video shows the global mute on (4th column, 5th item). If you switch the mute off then sound should work again. Can you confirm that this works with the latest driver?
The ".pad_input_count = 4" (from 2) post-submission change is specifically said to affect 18i8 - what is the effect of not having it?
I see Takashi had commented on the index.id issue, and upstream had a little correction on it. Anyway, unless we have big upcoming changes we should try to use backported upstream and hopefully see / fix any further issues.
The ".pad_input_count = 4" (from 2) post-submission change is specifically said to affect 18i8 - what is the effect of not having it?
Not having it means that the third and fourth pad controls are missing.
I see Takashi had commented on the index.id issue, and upstream had a little correction on it.
I don't know what the "index.id issue" is, and I can't find a message from Takashi about it. Can you clarify?
Sorry I meant https://mailman.alsa-project.org/pipermail/alsa-devel/2021-June/186606.html , which was partly added afterwards in 8120b7e
Please feel free to continue the exchange, but I am closing this issue now, as the original problem seems to have gone.
Sorry I meant https://mailman.alsa-project.org/pipermail/alsa-devel/2021-June/186606.html , which was partly added afterwards in 8120b7e
Oh, right. Yes, that was in the set of patches I already submitted upstream:
geoffreybennett/scarlett-gen2@9ba38e3
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=785b6f29a795f109685f286b91e0250c206fbffb