I found one regression in 4.17-rc1 that is not present in previous kernels (used 4.15- in Ubuntu for a long time, also tested vanilla 4.16.3 just now). USB sound card Creative SB Omni Surround 5.1 with 4.17-rc1 doesn't show PCM in alsamixer, also left channel is a bit quieter that the right channel, which wasn't present previously (both channels are configured to the same level and are working properly with the same exact settings on older kernels). nazar-pc@nazar-pc ~> env LANG=C aplay -l **** List of PLAYBACK Hardware Devices **** ... card 1: S51 [SB Omni Surround 5.1], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 card 1: S51 [SB Omni Surround 5.1], device 1: USB Audio [USB Audio #1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: S51 [SB Omni Surround 5.1], device 2: USB Audio [USB Audio #2] Subdevices: 1/1 Subdevice #0: subdevice #0
There are a few changes in USB-audio in 4.17, but I can't see any obvious ones that may bring such regression. Try to roll back sound/usb/* to the 4.16 state and see whether it works. e.g. copy the whole files of sound/usb/* from 4.16 tree, as well as include/linux/usb/audio*.h. Then build the modules and test whether the issue appears. If this works, it's a regression in USB-audio driver, so we can check go bisection concentrating only on sound/usb/* paths. If not, it means that the problem is in somewhere different, and you'd need a full bisection.
With suggested it works fine.
OK, then could you try git-bisect? It should be relatively short, only check sound/usb/* git bisect start -- sound/usb git bisect bad v4.17-rc1 git bisect good v4.16
Or, maybe a more straightforward way would be to simply revert one by one. % git log --no-merges --topo-order --pretty=oneline v4.16.. sound/usb/*.[ch] b580fbfff13b01fa79a0760cbb6386f33bc9e10b ALSA: usb-audio: Add sanity checks in UAC3 clock parsers f5d76e9c40fd8791202d31c66a63f6f7ebbb8dcb ALSA: usb-audio: More strict sanity checks for clock parsers f7645bd636d06f64f3eadb63cf1c8145219fdc58 ALSA: usb-audio: Refactor clock finder helpers ..... So, on top of Linus tree, revert starting from b580fbfff13b: % git revert b580fbfff13b And compile, install & test. % make -j8 % sudo make modules_install This should rebuild only sound/usb/*, so it must be fast. If the driver still works after the revert, go to the next one: % git revert f5d76e9c40fd and so on. It may need more tests than bisection, but this can be quicker as you don't need the build of full kernel from scatch.
I'd like to avoid doing anything like "sudo make *install" on primary system. Will try my best and get back when I find something more specific.
You can just copy sound/usb/*.ko into the corresponding /lib/modules/$VERSION/kernel/sound/usb/ directory instead of make modules_install, of course.
The first bad commit after bisect is 21e9b3e931f78497b19b1f8f3d59d19412c1a28f, in this commit regression happens immediately after boot. Now a little bit of background. I've reported another regression in https://bugzilla.kernel.org/show_bug.cgi?id=198757 (which I'll eventually try to bisect too, especially since no one responded to me on mailing list yet after several reminders), basically it requires me to unplug and plug back in mentioned USB sound card after each reboot to get 5.1 output mode available. So a bit later since first bad commit, as of 3446b1e962b387b8cec53e85fdd9392da25a2737, I only observe regression from this particular bug report after mentioned unplug/plug back procedure. I guess this all is somehow connected to each other.
Here is a PulseAudio config I've put together couple of years ago, might be useful for understanding how this sound card works: https://github.com/pulseaudio/pulseaudio/blob/master/src/modules/alsa/mixer/profile-sets/sb-omni-surround-5.1.conf
Thanks for performing bisection! I'll ping Andrew at first.
Could you attach the output of lsusb -v please? Thank you.
Sure, here: https://pastebin.com/d5rt47Fd
Now I took a closer look at the change, and found at least one place that seems forgotten to be converted. Nazar, could you try the patch below?
Created attachment 275483 [details] Test fix patch
Confirmed from the descriptors its a UAC2 device with master-channel only controls in the output path so it would definitely be affected by this mistake, sorry. I'm surprised this would affect left vs right channels though as the mistake appears to only affect master controls (volume affects mute by accident and mute does nothing). Maybe there's another issue.
Patch works for me, including left/right channels, thanks!