Bug 207023
| Summary: | MOTU M2 regression on duplex audio | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Erwin Burema (e.burema) |
| Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | alexander, e.burema, fanantoxa, greg.allam, hi, Isaak.Aleksandrov, iserg9, jelmer, lukeisgreat, raemanjonsun, salemixu, tiwai |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 5.6rc7 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
.config file and output of lspci
patch to enable duplex usb audio whith implicit feedback fix-pulseaudio-for-motu-m2.patch |
||
|
Description
Erwin Burema
2020-03-30 10:19:29 UTC
Hm, that's unfortunate. Alexander, any chance to diffenctiate M2 from other models you fixed? (In reply to Takashi Iwai from comment #1) I'm pretty sure M2 also doesn't provide explicit feedback endpoint. (In reply to Erwin Burema from comment #0) Could you attach lsusb -v -d 07fd:0008 output? Output of lsusb -v -d 0fd:0008 as requested
Bus 001 Device 003: ID 07fd:0008 Mark of the Unicorn M2
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x07fd Mark of the Unicorn
idProduct 0x0008
bcdDevice 1.01
iManufacturer 1 MOTU
iProduct 3 M2
iSerial 2 M20000007839
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0147
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 3
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 3 M2
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 8
wTotalLength 0x0053
bmControls 0x00
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 1
bmAttributes 3 Internal programmable clock
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 9 MOTU Internal Clock
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 11 (CLOCK_SELECTOR)
bClockID 4
bNrInPins 1
baCSourceID(0) 1
bmControls 0x03
Clock Selector Control (read/write)
iClockSelector 8 MOTU Clock Selector
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 42
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 4
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 12 Out 1
bmControls 0x0000
iTerminal 6 M2
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 20
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 42
bCSourceID 4
bmControls 0x0000
iTerminal 0
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 41
wTerminalType 0x0201 Microphone
bAssocTerminal 0
bCSourceID 4
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 14 In 1
bmControls 0x0000
iTerminal 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 22
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 41
bCSourceID 4
bmControls 0x0000
iTerminal 7 M2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0006 1x 6 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 M2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 M2
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 42
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 12 Out 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 24
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x00c8 1x 200 bytes
bInterval 1
AudioStreaming Endpoint Descriptor:
bLength 8
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bmControls 0x00
bLockDelayUnits 2 Decoded PCM samples
wLockDelay 0x0008
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 5 M2
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 5 M2
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 22
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 14 In 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 24
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 37
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Implicit feedback Data
wMaxPacketSize 0x00c8 1x 200 bytes
bInterval 1
AudioStreaming Endpoint Descriptor:
bLength 8
bDescriptorType 37
bDescriptorSubtype 1 (EP_GENERAL)
bmAttributes 0x00
bmControls 0x00
bLockDelayUnits 2 Decoded PCM samples
wLockDelay 0x0008
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 0
iInterface 0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0009
bInCollection 1
baInterfaceNr(0) 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 3 MIDI Streaming
bInterfaceProtocol 0
iInterface 0
MIDIStreaming Interface Descriptor:
bLength 7
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 1.00
wTotalLength 0x0041
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 1 Embedded
bJackID 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (MIDI_IN_JACK)
bJackType 2 External
bJackID 2
iJack 11 MOTU MIDI In
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 1 Embedded
bJackID 3
bNrInputPins 1
baSourceID( 0) 2
BaSourcePin( 0) 1
iJack 0
MIDIStreaming Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (MIDI_OUT_JACK)
bJackType 2 External
bJackID 4
bNrInputPins 1
baSourceID( 0) 1
BaSourcePin( 0) 1
iJack 10 MOTU MIDI Out
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 1
Endpoint Descriptor:
bLength 9
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
bRefresh 0
bSynchAddress 0
MIDIStreaming Endpoint Descriptor:
bLength 5
bDescriptorType 37
bDescriptorSubtype 1 (GENERAL)
bNumEmbMIDIJack 1
baAssocJackID( 0) 3
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 4
bInterfaceProtocol 1
iInterface 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
So, M2 also needs implicit feedback quirk and implicit feedback support needs to be fixed in the driver. Or we are going to choose what is more important: glitch-free playback or a working duplex in pulseaudio. And this is basically the same bug as bug #103751 (In reply to Alexander Tsoy from comment #4) > So, M2 also needs implicit feedback quirk and implicit feedback support > needs to be fixed in the driver. Or we are going to choose what is more > important: glitch-free playback or a working duplex in pulseaudio. Currently running with the workaround and have heard no glitches yet, is there any particular situation those should be prevalent? Also as far as I have been able to test Jack is still able to do full duplex audio even with the implicit feedback quirk enabled, as I understand this is because Jack opens the device differently. So if pulse can figure out if this quirk is enabled for the device it should be able to work around it (by opening the device the same way Jack does instead of doing whatever is does now) Am I wrong here? (In reply to Erwin Burema from comment #6) > (In reply to Alexander Tsoy from comment #4) > > So, M2 also needs implicit feedback quirk and implicit feedback support > > needs to be fixed in the driver. Or we are going to choose what is more > > important: glitch-free playback or a working duplex in pulseaudio. > > Currently running with the workaround and have heard no glitches yet, is > there any particular situation those should be prevalent? This probably depends on how system clock diverges from the devices' internal clock. If you record a sine wave from M2, you will see periodic artifacts. > Also as far as I have been able to test Jack is still able to do full duplex > audio even with the implicit feedback quirk enabled, as I understand this is > because Jack opens the device differently. So if pulse can figure out if > this quirk is enabled for the device it should be able to work around it (by > opening the device the same way Jack does instead of doing whatever is does > now) Yes, this depends on the order in which an application configures and starts pcm streams. But it would be better if it gets fixed on the kernel side. (In reply to Alexander Tsoy from comment #7) > (In reply to Erwin Burema from comment #6) > > (In reply to Alexander Tsoy from comment #4) > > > So, M2 also needs implicit feedback quirk and implicit feedback support > > > needs to be fixed in the driver. Or we are going to choose what is more > > > important: glitch-free playback or a working duplex in pulseaudio. > > > > Currently running with the workaround and have heard no glitches yet, is > > there any particular situation those should be prevalent? > > This probably depends on how system clock diverges from the devices' > internal clock. If you record a sine wave from M2, you will see periodic > artifacts. > Just checked with a 1Khz sine and every few seconds there is a slight plop, it is noticeable with a pure tone but not very noticeable in day to day use. > > Also as far as I have been able to test Jack is still able to do full > duplex > > audio even with the implicit feedback quirk enabled, as I understand this > is > > because Jack opens the device differently. So if pulse can figure out if > > this quirk is enabled for the device it should be able to work around it > (by > > opening the device the same way Jack does instead of doing whatever is does > > now) > > Yes, this depends on the order in which an application configures and starts > pcm streams. But it would be better if it gets fixed on the kernel side. That would be preferable and will be able to test patches Created attachment 288179 [details]
patch to enable duplex usb audio whith implicit feedback
This patch enables duplex audio for me with implicit feedback and should still fail when:
1) Endpoint already in use but not used for implicit feedback
2) Endpoint used as implicit feedback but configured with different parameters
This is based on my understanding that when implicit feedback is used the output stream uses the input stream to check sync (so for 1 output packet 1 input packet), but those packets can still also be used for an actual input audio stream. Of course this only works when settings don't change (settings for both input and output endpoint need to be the same)
The current check is I think overly complicated and duplicates quite a bit of code but not sure what checks should be performed to make sure input and output stay the same.
The patch looks good and feasible, could you submit it alsa-devel ML? Maybe better to brush up the coding style issues via checkpatch.pl before submitting, though. FWIW I've been running with the patch for the last week or so with a M2 and various other audio devices, with no issues encountered. Will clean up the patch and send it to alsa-devel coming weekend Thanks all, especially Erwin for the work on this. I am also running a patched 5.6.12 and my MOTU M2 is functional. Well, AFAIS, it actually doesn't fully fix the issue. If you, for example, start/stop capture stream while playback stream is active, then playback will be interrupted. We really need to always start and stop both endpoints at the same time with some refcounting of substreams. (In reply to Alexander Tsoy from comment #14) > Well, AFAIS, it actually doesn't fully fix the issue. If you, for example, > start/stop capture stream while playback stream is active, then playback > will be interrupted. Does it even after applying the recent full-duplex support on 5.8? The endpoint is managed with refcount, so the sync EP should be still running after the capture stream gets closed before the playback, I thought. Hmm.. I need to retest with the more recent kernel. There might be something overlooked, of course :) e.g. I didn't track fully how the sync ep handling in snd_usb_handle_sync_urb() can be influenced. And there is one potential use-after-free, which I already showed a fix patch in the past. I'll submit the oneliner soon later. (In reply to Alexander Tsoy from comment #16) > Hmm.. I need to retest with the more recent kernel. If you can find something I'll see if I can get some kind of fix for it during the weekend. Hi everyone. I just got my Motu M2 recently and trying to use it under Ubuntu. Still have some issues Full-duplex doesn't work with pulseaudio Kernel 5.7.8 Kernelt 5.8-rc5 If I switch to use M2 input it just stop output In addition anything that were using it start to hand For example if I had chrome playing video on youtube: - First sound disappear but video still going - After player showed me all that was cached it hangs Like should that loading circle but it doesn't load anything - If I open new video same issue it show circle and can't kinda start it at all If I swatch PulseAudio to user other input and after disconnect/connect Motu and restart chrome everything works again as usual. Also I've tried JACK config from this guide: https://panther.kapsi.fi/posts/2020-02-02_motu_m4 It did worked out but I had only JACK in my sound setting (witch is not what I'm up too since I also use other sound deviced) But it did worked out. Problem happen when you disconnect/connect Motu. (I have USB hub that I switch from PC <-> Laptop, This is crucial for me since I do it few time a day) The same can be emulated by just turning Motu off/on (likely it have switch on the back) So with JACK it was working but If I connect/disconnect it stop working. And I experience same issue that I described above (with chrome) In this case only restart helps to get control back. If that will be somehow helpful for investigation. Also I'm can provide other information like logs or smth (but please help me with that, I don't know where to look) If anyone needs someone to test a patch, I can. Let me know if there are any types of tests I could run. (In reply to Luke Tidd from comment #20) > If anyone needs someone to test a patch, I can. Let me know if there are any > types of tests I could run. It a patch in comment #9 > attachment 288179 [details] I wasn't able to build a kernel with it yet. But we can try to test it probably. Oh that patch, yes I tested it and things seemed fine for me. I can test again if people want, I thought it wasn't going in because it needed more work. Created attachment 290697 [details]
fix-pulseaudio-for-motu-m2.patch
I've tried to build a Ubuntu Kernel to apply this patch. But I've found that changes already there. https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.7.11/ It still doesn't work with pulseaudio. I was looking to comment here: > The issue seems to be introduced with commit: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/usb/pcm.c?h=v5.4.28&id=da2d50868e59257410fe75315dc99984c3b9fad6 > which is a fix for the MOTU M4 which sadly has the same USB device numbers, > removing this fix restores duplex mode with the MOTU M2 in pulseaudio MOTU M2 and M$ have different `iProduct` value MOTU M4 lsusb -v https://gist.github.com/puleglot/ec75ff504b8727096c2de7c1a630864a MOTU M2 lsusb Higer above here in comment #3 I ended up with a patch: https://bugzilla.kernel.org/attachment.cgi?id=290697 I didn't try it yet. But will do this weekend. I have hard time to build Ubuntu Kernel, but will try my best. If you'd be able to test it before it'd be nice. (In reply to fanantoxa from comment #24) > I've tried to build a Ubuntu Kernel to apply this patch. > > But I've found that changes already there. > > https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.7.11/ > > > It still doesn't work with pulseaudio. > That is really weird since it works for me under pulse audio (and many other people using implicit feedback devices) maybe related to the power issue I described bellow? > > > I was looking to comment here: > > > The issue seems to be introduced with commit: > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/sound/usb/pcm.c?h=v5.4.28&id=da2d50868e59257410fe75315dc99984c3b9fad6 > > which is a fix for the MOTU M4 which sadly has the same USB device numbers, > > removing this fix restores duplex mode with the MOTU M2 in pulseaudio > > MOTU M2 and M$ have different `iProduct` value > > MOTU M4 lsusb -v > https://gist.github.com/puleglot/ec75ff504b8727096c2de7c1a630864a > > MOTU M2 lsusb Higer above here in comment #3 > > I ended up with a patch: > https://bugzilla.kernel.org/attachment.cgi?id=290697 > > > > I didn't try it yet. But will do this weekend. > I have hard time to build Ubuntu Kernel, but will try my best. > > If you'd be able to test it before it'd be nice. That will disable implicit feedback making duplex audio work but making sync fail (eventually) you will be experiencing small pops every few seconds when recording. That said the following rings a bell (forgot about it since I "solved" it well before the initial implicit feedback patch in 5.5 or 5.6) > If I switch to use M2 input it just stop output > In addition anything that were using it start to hand > For example if I had chrome playing video on youtube: > - First sound disappear but video still going > - After player showed me all that was cached it hangs > Like should that loading circle but it doesn't load anything > - If I open new video same issue it show circle and can't kinda start it at > > > all It is an USB powermanagement issue which can be worked around with the following udev rule: ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", ATTR{power/control}="on", ATTR{power/persist}="0" and also poweroff the M2 (with the switch on the back) when suspending the computer and power on when resuming. Extremely rarely it still fails but it seems to be firmware related. (In reply to Erwin Burema from comment #25) I'll try to get some help. I've tried this rule. And looks like I have some other problems. When I switch input to MOTU, output stuck. But actually I don't even get input. Nothing incoming. Maybe I messed up some configs (it was many config changes to try make it work.) Probably I've broke something. (And I still on Ubuntu 18.04 but with 5.7 kernel which also might make a difference). I probably start with making bootable flash with 20.04 to make a fast test So I partly made I work. I won't able to test properly on 20.04 yet. ( I need to find a way how to make bootable flash drive with custom kernel version) But when I boot on 20.04 (with 5.4.0.40 kernel) and I choose M2 as an Input it automatically switches output to other device (laptop speackers in my case). So Input worked but no duplex. On Ubuntu 18.04 it don't do that switch for me just stuck. Also I kinda managed it to work on my current Ubuntu 18.04 I've update pulseaudio manually from 11.0 to 13.0 (Ubuntu don't have it yet in repo's) Now when I chose `Analog Output - M2` and after `Analog Input - M2` both works!!!! I was able to make some recording while playing music. But once I've finished recording I switched `Analog Input` to another device (Logitech webcam in my case) Both output stuck and applications that where using it. So audacity not able to perform recording (it just doesn't do anything when I click on play) Firefox hangs like chrome did. If I go to sound settings (in gnome) and click on other output device and back to M2 it starts to work again. So some things are works some bugs are still there. I'll try more to check what happening. Next step will be: - check some logs in Ubuntu 18.04 - make bootable Ubuntu 20.04 with 5.7.11 kernel So I've tried more. I manage to use JACK + PulseAudio. And it works good. (I didn't get yep how to make JACK ocupate only MOTU and not other devices, but it's minor and should be doable) But if I disconnect and connect back (or on/off) device. If hang browser as usual. In addition to that it brakes JACK too. So I'm getting no devices to output audio and can't input. But WebCam mic still seen in pulseaudio and works properly. ``` 03:05:08.786 D-BUS: JACK server could not be started. Sorry Fri Aug 28 03:05:08 2020: Starting jack server... Fri Aug 28 03:05:08 2020: ERROR: `default' server already active Fri Aug 28 03:05:08 2020: ERROR: Failed to open server Fri Aug 28 03:05:10 2020: Saving settings to "~/.config/jack/conf.xml" ... 03:05:18.361 Could not connect to JACK server as client. - Overall operation failed. - Server communication error. Please check the messages window for more info. ``` I used 5.9 rc1 or rc2 over the weekend and simultaneous playback and recording was possible without starting JACK. The details are over my head as I can't find out what implicit feedback means, but I am curious what the current state of the code in the kernel is? Are there outstanding issues I might expect? It seems to be working pretty nicely. (In reply to Luke Tidd from comment #29) > I used 5.9 rc1 or rc2 over the weekend and simultaneous playback and > recording was possible without starting JACK. The details are over my head > as I can't find out what implicit feedback means, but I am curious what the > current state of the code in the kernel is? Are there outstanding issues I > might expect? It seems to be working pretty nicely. I can't use 5.9 rc1|2 because it unstable yet and breaks other stuff I use in linux. Maybe will try when it will be 5.9.0 I manage to work it few time with pulseaudio and JACK. But main problem that no metter what you use if I turn Off/On device while Laptop os running it hang everythinig. Could you try off and on device while OS is running and you have both input/output as motu? Ok. I've reset all the configs to default, reinstalled pulseaudio and removed JACK. Now I got both input and output working. But still when I turn off and on device it hangs. I managed to get off this hang state without restarting chrome: - changed input to another device (WebCam in my case) - turn off and on motu again - got to output setting and click to internal speakers and back for a few times. Also if there were no sound for some long time and I start to some video, there is no sound for ~5 second and after it starts. I addition to Steps to make it work: After those steps I'm able Only working output. If I try to use input at the same time it hangs as usual. Repeating those step make output work again. First things first if you have duplex audio on pulseaudio than the patch discussed here (and this bug) is solved. For some background implicit feedback in USB means that it uses the input channel(s) for timing feedback on the output channels it does so by looking at packet size (next packet size to send out is the packet size of the last incoming packet), without the patch in this bug report(which should now be mainlined) the Linux USB audio driver didn't want to extract the audio from the input line due to it already being started for use as implicit feedback, with this patch it checks if a) it is used as implicit feedback and b) if it would be set up the same as the output channel, if both are the case it just skips setup and starts using the endpoint. This is the only thing the patch does and shouldn't cause any hangs
I also used to have a lot more audio hangs before applying the following udev rule:
ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", ATTR{power/control}="on", ATTR{power/persist}="0"
Combining what I know about implicit feedback and the above USB rule I don't think the hang us caused by the USB audio stack but a bug in the power management code most likely in the firmware of the M2 (and probably M4 as well)
Ergo you probably should open a new bug report since I am pretty sure it is not related to this one.
(In reply to fanantoxa from comment #31) > Also if there were no sound for some long time and I start to some video, > there is no sound for ~5 second and after it starts. This is probably caused by a sample rate change. And this is a limitation of the device, not a linux bug. I don't know what I was thinking; unfortunately I can only access my machine with the updated kernel on the weekend and perhaps I had been drinking. I definitely still need to start JACK to have simultaneous i/o working. 5.9.0-rc2 Unfortunately I don't see this patch in 5.9-rc4. Do you think the MOTU M4 would need a different approach? If the strcmp is removed, would this patch support both cards? I haven't tested recording a sine wave, if it produces artifacts during recording is there any bug about the underlying issue causing that? (In reply to Luke Tidd from comment #36) > Unfortunately I don't see this patch in 5.9-rc4. > > Do you think the MOTU M4 would need a different approach? If the strcmp is > removed, would this patch support both cards? > > I haven't tested recording a sine wave, if it produces artifacts during > recording is there any bug about the underlying issue causing that? Which patch are you using? The implicit feedback patch is included I can clearly see the code that I wrote that was accepted so duplex audio on implicit feedback devices should be working. The strcmp was only to distinguish M2 from M4 which isn't needed since both use implicit feedback. The artifacts you get are because the timers on the computer and inside the USB audio device are not synced, implicit feedback fixes this by telling the host how much behind or ahead it is by decreasing or increasing the buffers it sends (and the host receives), the host should then use those buffer sizes for the next block it sends back.(this differs from explicit feedback which uses an extra USB endpoint for its feedback, according to apples documentation implicit is more accurate and thus recommended that is probably why so many devices uses it) This has most impact on the playback (made a mistake in an earlier comment when saying recording) which depending on how much out of sync the timers are can be more or less audible (it will always be audible on a pure sine). (besides implicit and explicit there is also a total async mode that is mostly used in cheaper/older devices since that is the only mode supported by UAC1, UAC2 introduced the feedback modes which allowed USB audio devices to be used in sync modes important for audio production, instead of just as a consumer device) I'm sorry I was referring to "fix-pulseaudio-for-motu-m2.patch". We shouldn't expect this to work out of the box until pcm.c get's this diff, correct? (In reply to Luke Tidd from comment #38) > I'm sorry I was referring to "fix-pulseaudio-for-motu-m2.patch". We > shouldn't expect this to work out of the box until pcm.c get's this diff, > correct? No that is not correct, that patch disable implicit feedback on the M2 which it definitely needs. Currently running 5.8.2 with only the patches provided by Arch applied (currently 1 unrelated to USB audio) and have my M2 working in full duplex (under both pulseaudio and jack, probably raw ALSA as well but haven't tried that). I see where my confusion has come from. I was running a different kernel than you and I was expecting the same behavior. kernel 5.8.10-arch1-1: Everything appears to work all of the time. I have full duplex audio that functions at when the desktop starts, and I have not experienced any issues yet. I did not use the power related udev rule. kernel 5.9.0-rc5-1-mainline: Often, audio can play for about 20 seconds when the desktop starts, then hangs. Any other application that tries to in or out audio will also hang. If all of these applications are closed, then restarted, full duplex audio can sometimes work. Sometimes it does not start working again and it takes restarting the card to get it to function. I have tried this with and without the udev rule, I do not see a difference. I have tested the same kernel with a Focusrite Scarlett 4i4 and have not reproduced this hang. I'm not sure if we should expect a release candidate kernel to function correctly, but I wanted to include this here in case it's relevant. (In reply to Luke Tidd from comment #40) > I see where my confusion has come from. I was running a different kernel > than you and I was expecting the same behavior. > > kernel 5.8.10-arch1-1: > Everything appears to work all of the time. I have full duplex audio that > functions at when the desktop starts, and I have not experienced any issues > yet. I did not use the power related udev rule. > > kernel 5.9.0-rc5-1-mainline: > Often, audio can play for about 20 seconds when the desktop starts, then > hangs. Any other application that tries to in or out audio will also hang. > If all of these applications are closed, then restarted, full duplex audio > can sometimes work. Sometimes it does not start working again and it takes > restarting the card to get it to function. I have tried this with and > without the udev rule, I do not see a difference. I have tested the same > kernel with a Focusrite Scarlett 4i4 and have not reproduced this hang. > > I'm not sure if we should expect a release candidate kernel to function > correctly, but I wanted to include this here in case it's relevant. If this is indeed the case you want to git bisect the kernel between 5.8.10 and 5.9.0-rc5 so you can pinpoint a patch that introduces your issues. Am going to see if I have time for this myself, but no guarantees on that front (I am just a hobyist with way to much knowledge, but not a lot of time) PS. You also might want to try a different USB port, sometimes multiple devices on the same hub don´t get along. Small update, I've removed any other USB devices besides keyboard and mouse and tried different ports, but since this problem is only occurring with the release candidate kernels I am going to assume it's software. Unfortunately I haven't had time to figure out a workflow to run `git bisect` on this. I did however try the newly released arch linux-mainline kernel package and the issue is still present in "5.9.0-rc8-1-mainline". I realized a simple work around for the issue I am experiencing. Currently testing with Arch's 5.9.0-1-mainline AUR kernel, but I am seeing a similar problem when I look closely with older kernels. Problem Details: On boot: No sound output No VU activity on the sound card display for output (the input still responds) pavucontrol: "Playback" tab -> no VU activity on the playing application "Output Devices" -> no VU activity which displays only "M Series Analog Stereo" -> "Analog Output" which is selected and not muted "Configuration" tab shows "M Series" -> "Analog Stereo Duplex" Mitigation: Either power cycle the sound card or less invasively select the "Configuration" tab of pavucontrol, set "M Series" Profile to "Off", then back to "Analog Stereo Duplex" After rebooting about 20 times, infrequently the sound card will work and not need the mitigation. If I boot three times in a row and test sound output, the need to do the mitigation is very likely. Can anyone else see this behavior? I could write a systemd service that tries to restart pulseaudio after the desktop or disable then re-enable the sound card but it seems like a bug somewhere. Should this be filed as a separate bug? Hey people! I've got a MOTU M4, using latest Arch Linux using kernel 5.9.1-arch1-1. I connect the interface directly to the motherboard on a USB 3.0 port. Full duplex issue is fixed in this latest kernel, but if you force PulseAudio to 192khz it won't show the Full Duplex mode. Apart from that, I also experience this audio output freeze. Sometimes whenever I start the computer, or when there's a long time of not playing anything, I can't get any output although audio streams are playing. Or sometimes, they freeze completely (youtube or audacious for example). If I restart the interface some times, while restarting the audio daemon (I've tried PulseAudio, Jack, PipeWire, and also plain ALSA) I can get it to work again as normal. Is there any way I can debug the module, or test anything to know why is this happening? I'd gladly help you with this, feel free to suggest or guide me through it. (In reply to Angel from comment #44) > Hey people! I've got a MOTU M4, using latest Arch Linux using kernel > 5.9.1-arch1-1. > > I connect the interface directly to the motherboard on a USB 3.0 port. > Full duplex issue is fixed in this latest kernel, but if you force > PulseAudio to 192khz it won't show the Full Duplex mode. > Sadly no idea why that would be the case, you might want to check if you get the following message in kernel log (dmesg) "Unable to change format on ep #%x: already in use" (replace %x with a number) That means it can't configure both input and output for 192khz at the same time, if this does work with e.g. jack might need to look into making the checks a bit more robust > Apart from that, I also experience this audio output freeze. Sometimes > whenever I start the computer, or when there's a long time of not playing > anything, I can't get any output although audio streams are playing. Or > sometimes, they freeze completely (youtube or audacious for example). > Personally I suspect I it has something to do with how the MOTU devices (m2 and m4) handle USB autosuspend if I disable that with an udev rule it seems to be a lot more stable and only shows issues with when suspending the whole computer (the workaround for that is to turn it off (with the handy provided switch on the back of the MOTU) before suspending and turn it on when back on) The uev rule would be (normally power/control would be in 'auto' meaning it will automatically suspend when not in use) ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", ATTR{power/control}="on" > If I restart the interface some times, while restarting the audio daemon > (I've tried PulseAudio, Jack, PipeWire, and also plain ALSA) I can get it to > work again as normal. > > Is there any way I can debug the module, or test anything to know why is > this happening? > > I'd gladly help you with this, feel free to suggest or guide me through it. Hope the above info is helpful, if turning off autosuspend works for you as well I might see if I can get some kind of quirk in the kernel (or a default udev rule) so that it works for more people (In reply to Erwin Burema from comment #45) > (In reply to Angel from comment #44) > > Hey people! I've got a MOTU M4, using latest Arch Linux using kernel > > 5.9.1-arch1-1. > > > > I connect the interface directly to the motherboard on a USB 3.0 port. > > Full duplex issue is fixed in this latest kernel, but if you force > > PulseAudio to 192khz it won't show the Full Duplex mode. > > > > Sadly no idea why that would be the case, you might want to check if you get > the following message in kernel log (dmesg) > > "Unable to change format on ep #%x: already in use" (replace %x with a > number) > > That means it can't configure both input and output for 192khz at the same > time, if this does work with e.g. jack might need to look into making the > checks a bit more robust > Yes, in dmesg I can see the following line repeated 20 times when I start pulseaudio at 192Khz: [ 176.345760] usb 2-9.2: Unable to change format on ep #81: already in use In jack I have noticed that it can't start on full duplex some times: 21:46:11.531 JACK was started with PID=3506. JACK compiled with System V SHM support. loading driver .. apparent rate = 192000 creating alsa driver ... hw:M4|hw:C920|256|3|192000|0|0|nomon|swmeter|-|32bit ALSA lib pcm_hw.c:1829:(_snd_pcm_hw_open) Invalid value for card ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to playback-only mode configuring for 192000Hz, period = 256 frames (1.3 ms), buffer = 3 periods ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 3 periods for playback On other times this is the log: creating alsa driver ... hw:M4|hw:C920|256|3|192000|0|0|nomon|swmeter|-|32bit configuring for 192000Hz, period = 256 frames (1.3 ms), buffer = 3 periods ALSA: final selected sample format for capture: 16bit little-endian ALSA: use 3 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 3 periods for playback playback and capture sample rates do not match (44100 vs. 32000) Usually, if I don't use my webcam as capture device (this is the C920), and use de M4 or the default device, there's no issues apart from a list of xrun's: **** alsa_pcm: xrun of at least 0.032 msecs > > Apart from that, I also experience this audio output freeze. Sometimes > > whenever I start the computer, or when there's a long time of not playing > > anything, I can't get any output although audio streams are playing. Or > > sometimes, they freeze completely (youtube or audacious for example). > > > > Personally I suspect I it has something to do with how the MOTU devices (m2 > and m4) handle USB autosuspend if I disable that with an udev rule it seems > to be a lot more stable and only shows issues with when suspending the whole > computer (the workaround for that is to turn it off (with the handy provided > switch on the back of the MOTU) before suspending and turn it on when back > on) > > The uev rule would be (normally power/control would be in 'auto' meaning it > will automatically suspend when not in use) > ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", ATTR{power/control}="on" > I added this rule in UDEV and the same behavior happened. After I removed and took a look at the corresponding file, I could see that power control is always turned on: grep 0008 /sys/bus/usb/devices/*/idProduct /sys/bus/usb/devices/2-9.2/idProduct:0008 cat /sys/bus/usb/devices/2-9.2/power/control on > > If I restart the interface some times, while restarting the audio daemon > > (I've tried PulseAudio, Jack, PipeWire, and also plain ALSA) I can get it > to > > work again as normal. > > > > Is there any way I can debug the module, or test anything to know why is > > this happening? > > > > I'd gladly help you with this, feel free to suggest or guide me through it. > > Hope the above info is helpful, if turning off autosuspend works for you as > well I might see if I can get some kind of quirk in the kernel (or a default > udev rule) so that it works for more people I don't know if it is related to autosuspend, but after the tests I made, looks like it's not related to it. I could be wrong, though. I can do further tests if you like. I was thinking that maybe I could debug in some way the kernel module and see any event rised, or breakpoint on some value, or similar. I'm quite out of ideas. Thanks for your help :) (In reply to Angel from comment #46) > (In reply to Erwin Burema from comment #45) I just experienced an strange behavior. I just used the interface with my bass monitoring it. And when I wanted to play audio there wasn't any output (the usual bug we're discussing). Restarted, and later I used my webcam with Skype for an hour or so, and left listening to music and some youtube videos on Firefox and Chromium, when suddenly I can see a notification from PulseAudio saying that there's a new source from my webcam. And just a second later I can't hear anything from the interface and the youtube video is hanged. I could see how the UV levels were going down. When I took a look at dmesg, it showed me this (the first line is quite some time ago, the second line on 13839.something is when it started): [ 7909.611739] usb 2-10.3.1: reset high-speed USB device number 11 using xhci_hcd [13839.596068] usb 2-10.3.1: USB disconnect, device number 11 [13839.735558] usb 2-10.3.1: new high-speed USB device number 13 using xhci_hcd [13840.405445] usb 2-10.3.1: New USB device found, idVendor=046d, idProduct=0892, bcdDevice= 0.19 [13840.405447] usb 2-10.3.1: New USB device strings: Mfr=0, Product=2, SerialNumber=1 [13840.405448] usb 2-10.3.1: Product: HD Pro Webcam C920 [13840.405448] usb 2-10.3.1: SerialNumber: 5A4B9D2F [13840.406556] gspca_main: vc032x-2.14.0 probing 046d:0892 [13840.406799] gspca_vc032x: reg_r err -32 [13840.406804] vc032x: probe of 2-10.3.1:1.0 failed with error -32 [13840.406823] uvcvideo: Found UVC 1.00 device HD Pro Webcam C920 (046d:0892) [13840.408474] input: HD Pro Webcam C920 as /devices/pci0000:00/0000:00:14.0/usb2/2-10/2-10.3/2-10.3.1/2-10.3.1:1.0/input/input28 Later, I powered down and up again the MOTU M4, and audio just worked again. Could it be that the USB hub power goes into sleep, or restarts itself or anything alike? I am using your udev rule, and while it seems to attempt to write these values in many places, it does seem to write them at least once successfully.
ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", ATTR{power/control}="on", ATTR{power/persist}="0"
https://paste.ee/p/Wf0lE
I have been running with this udev rule for a while, but my sound cards still needs to be manually reset after boot to function. kernel 5.9.9-arch1-1
(In reply to Luke Tidd from comment #48) > I am using your udev rule, and while it seems to attempt to write these > values in many places, it does seem to write them at least once successfully. > > > ATTRS{idVendor}=="07fd", ATTRS{idProduct}=="0008", > ATTR{power/control}="on", ATTR{power/persist}="0" > > https://paste.ee/p/Wf0lE > > I have been running with this udev rule for a while, but my sound cards > still needs to be manually reset after boot to function. kernel 5.9.9-arch1-1 I've no problems after a fresh boot so no clue (I am on 5.9.8-arch1-1), also I think this is drifting away from the original issue (duplex) audio, so might need a new bug report? I've opened https://bugzilla.kernel.org/show_bug.cgi?id=210339 about the sound card halting and requiring a reset after boot. I finally had some time to hunt the implicit feedback issue and a few other UAC bugs. The patch set was submitted to upstream and merged now. https://lore.kernel.org/r/20201123085347.19667-1-tiwai@suse.de The merged branch is topic/usb-audio-refactoring in sound.git tree git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git and it'll be included in linux-next from tomorrow, destined to 5.11 kernel. Wit this patch set, the full duplex will work better as the hw constraints are applied properly when one stream is opened. Also, it received the generic UAC2 implicit fb support, as well as MOTU quirk fixes. Now the patches are included in linux-next for 5.11. I can confirm the full duplex audio issue with a MOTU M4 running Ubuntu 20.10 and Kernel 5.8-low-latency. Selecting the M4 for both the output device and input device in the sound settings panel prevented any audio playback. Rhythmbox playback froze along with web browser audio. I thought the hardware was defective but thanks to this thread confirmed it as a software issue. I updated to Kernel 5.11 based Takashi's feedback above and the full duplex issue is gone. I haven't tried recording yet but I can at least choose my M4 for both input and output from system settings without any playback freezes/crashes. I used mainline (https://github.com/bkw777/mainline) to change out the kernel. Unfortunately the mainline gui tool doesn't support low latency kernel versions but I'm happy to have a working audio interface for day to day tasks using pulseaudio/alsa and use Jack only when low latency recording is needed. I tried 5.11 and beyond on Manjaro and 5.11 on Xubuntu LiveDVD and the output always stops after a while. After this happens pavucontrol still shows audio being outputted but the output meters on the front of the device stop moving and no audio is heard. Motu M2. I've now commented on https://bugzilla.kernel.org/show_bug.cgi?id=210339, I think that issue is more relevant to my case. |