hardware mixer doesn't work directly after boot (4i4, 3rd)

[fred41]

Hello Geoffrey,

first, thank you so much for your great work!

Maybe i found a minor bug related to module initialization (not really a problem, maybe even intentional behavior?):
The hardware mixer doesn't work directly after boot (standalone mode activated), until i start an application that opens the device.
After device opening via application the standalone mode (mixer included) works, until next module initialization (at boot).

Scarlett 4i4 3rd
[ 1.616264] usb 1-4: New USB device found, idVendor=1235, idProduct=8212, bcdDevice= 6.45
[ 1.616281] usb 1-4: New USB device strings: Mfr=1, Product=3, SerialNumber=2
[ 1.616283] usb 1-4: Product: Scarlett 4i4 USB
[ 1.616284] usb 1-4: Manufacturer: Focusrite
[ 1.616285] usb 1-4: SerialNumber: ....

[ 4.213484] usb 1-4: Focusrite Scarlett Gen 3 Mixer Driver 6.1-v1.3 enabled (pid=0x8212); report any issues to https://github.com/geoffreybennett/scarlett-gen2/issues
[ 4.240108] usb 1-4: Firmware version 1605
[ 4.244450] usbcore: registered new interface driver snd-usb-audio

Thank you,
fred41

[geoffreybennett]

Hi @fred41,

Thanks for your question! Most likely, I think what's happening is that the generic ALSA USB kernel driver (which is used by all class compliant drivers) selects every available sample rate and it gets left on 192kHz after it has finished initialising. The mixer in the Scarletts is not enabled at the higher sample rates, and so until you start an application that opens the device at a lower sample rate you'll get no audio passed through.

So, at least it's not a bug in the scarlett2 driver, as it doesn't have anything to do with sample rate selection or audio transfer. Just an unfortunate side-effect of the ALSA USB driver selecting the highest rate last, along with the hardware mixer not working at higher sample rates. This could probably be fixed with a change in ALSA initialisation. I had a quick look and maybe QUIRK_AUDIO_STANDARD_INTERFACE will do this. Otherwise the workaround is to set up something through udev to set the device to 48kHz when it connects.

Regards,
Geoffrey.

[fred41]

Hi Geoffrey,
thank you for your fast response, that makes sense in my opinion.
I will look into QUIRK_AUDIO_STANDARD_INTERFACE and udev as suggested by you.
I think i can close this issue already, because it is not a bug in your driver.

Thank you again,
fred41

[geoffreybennett]

I dug around in quirks.c, format.c, clock.c, endpoint.c, and stream.c and found that:

• my guess about QUIRK_AUDIO_STANDARD_INTERFACE wasn't useful
• because there is VENDOR_FLG(0x1235, QUIRK_FLAG_VALIDATE_RATES) in quirks.c, every sample rate for playback and recording is tested for validity when the driver starts
• after the sample rate validity check, stream.c explicitly sets the highest sample rate with: snd_usb_init_sample_rate(chip, fp, fp->rate_max);

So, please edit stream.c and change that use of fp->rate_max to 48000 and let me know if that fixes the problem.

If it does, then I'll ask upstream if they can help fix the issue in a general way. In the meantime, I'll reopen this issue.