Frequent USB and video interruptions w/ Ryzen

stratacast1

stratacast1

Okay, this is a topic I brought up a while back, but with it relating to an older release of FreeBSD that isn't supported and some new info, I thought I'd open a new topic. Here is the old thread for reference.

forums.freebsd.org

Frequent interruptions of IO in FreeBSD 11.2?

I just did a fresh install of FreeBSD 11.2 on my prior 11.1 box, and I'm finding now after doing so, I will frequently have my audio cut out for just a moment. My audio plays out of USB to a FiiO E10K external DAC. I don't know sound, and I don't know where to begin on this one. I'm also on KDE5...
forums.freebsd.org forums.freebsd.org

So here is my issue. From FreeBSD 11.2 to 12.1 I have had an issue with only FreeBSD and only Ryzen hardware. I have a FiiO E10K USB DAC for listening and whenever I use it, I'll have frequent pauses or sporadic stutters of both audio and video (apparent when watching a video) and mouse input that lasts maximum a couple seconds. This might happen once or twice a minute, it may go a few minutes without happening. This issue has not happened on any of the Intel boxes I have tried.

I don't see anything in terms of CPU or disk I/O that is causing this, my memory is tested, new, and good. In addition, I moved my headset to my rear audio out port and while playing audio through that devices I did Not have the interruption issues. These issues do not happen on Windows or Linux either on the exact same machine. Is there may some combo of sysctl flags that might solve this? I've been stumped a while now. Kinda just let it slide, but I've been using FreeBSD on my Ryzen desktop lately and I'm itching for a fix.
 
I preface with: I know nothing about audio on FreeBSD.

I read your last post of 18 months ago and wonder did you follow up and post a bug report? If so, what is its status?

Is the DAC connected (physically) to the USB port, not via an extension cable?

It sounds (ahem!) like a timing issue if it's constant. What's the driver that's controlling the USB audio?
 
Phishfry said:
I would check to make sure your interrupts are not going wacky.
vmstat -i
Look for xhci and/or ehci devices.
Click to expand...

Woah yes. Lots of interrupts. Which would be consistent with what I'm experiencing. Look at xhci2

Code: 
interrupt                          total       rate
cpu0:timer                       1071034         71
cpu1:timer                        690440         46
cpu2:timer                        703682         46
cpu3:timer                        731759         48
cpu4:timer                        750651         49
cpu5:timer                        655633         43
cpu6:timer                        738985         49
cpu7:timer                        616520         41
cpu8:timer                        640384         42
cpu9:timer                        659280         43
cpu10:timer                       683735         45
cpu11:timer                       659807         43
irq259: nvme0:admin                   30          0
irq260: nvme0:io0                  43660          3
irq261: nvme0:io1                  41621          3
irq262: nvme0:io2                  43453          3
irq263: nvme0:io3                  43500          3
irq264: nvme0:io4                  45048          3
irq265: nvme0:io5                  43423          3
irq266: nvme0:io6                  44422          3
irq267: nvme0:io7                  43132          3
irq268: nvme0:io8                  44457          3
irq269: nvme0:io9                  43530          3
irq270: nvme0:io10                 45806          3
irq271: nvme0:io11                 43346          3
irq272: xhci0                     472454         31
irq273: ahci0                       1948          0
irq274: igb0:rxq0                 349694         23
irq275: igb0:rxq1                 407089         27
irq276: igb0:aq                        5          0
irq278: hdac0                       4254          0
irq279: xhci2                   16218159       1069
irq280: hdac1                      10485          1
irq313: vgapci0                   136001          9
Total                           26727427       1762

This is where my knowledge is very limited. I don't know what exactly to do with handling interrupts with this stuff..


mark_j said:
I preface with: I know nothing about audio on FreeBSD.

I read your last post of 18 months ago and wonder did you follow up and post a bug report? If so, what is its status?

Is the DAC connected (physically) to the USB port, not via an extension cable?

It sounds (ahem!) like a timing issue if it's constant. What's the driver that's controlling the USB audio?
Click to expand...

I haven't done a report yet. I actually jumped off the FreeBSD desktop for that time in between and when I got back on it in October I ran it on an Intel box with none of these issues. I did use FreeBSD on my Ryzen desktop since December but I had been gone and really just ignored the issue because I had too much other stuff going on. I debated whether to do this or a bug report. If it can't be solved here, I will do a bug report next
 
stratacast1 said:
Woah yes. Lots of interrupts. Which would be consistent with what I'm experiencing. Look at xhci2
[...]
This is where my knowledge is very limited. I don't know what exactly to do with handling interrupts with this stuff..
Click to expand...

Interrupts are a natural part of a functioning operating system, so on that basis alone, these figures mean nothing. Perhaps watching the interrupts increase when you experience the lag is more relevant, but it still won't tell you what the problem is. I mean, I don't know whether that rate of interrupts is ok for such a bus. Are there other devices sharing it?

(I will counter that with the fact it might be experiencing an "interrupt storm" at the point of lag and that would be evident if watching vmstat when it happens).


stratacast1 said:
I haven't done a report yet. I actually jumped off the FreeBSD desktop for that time in between and when I got back on it in October I ran it on an Intel box with none of these issues. I did use FreeBSD on my Ryzen desktop since December but I had been gone and really just ignored the issue because I had too much other stuff going on. I debated whether to do this or a bug report. If it can't be solved here, I will do a bug report next
Click to expand...

Fair enough. You can raise a bug report now, continue with the consultation in the forums and if it gets solved, close the bug. What the bug report does do is make those responsible know of this issue (given it's gone on a long time).

When you plug this device in, what does usbconfig show? For example, if the device is ugen0.4 then what does usbconfig -d ugen0.4 dump_device_desc display?

Also, more information on the machine you're running would be informative, if you can.
 
Phishfry said:
Some different things to try.
usb_quirk (4)

For info: pciconf -lvbce xhci2 << Look for the MSI interrupts

Set this sysctl hw.usb.xhci.debug=32 then monitor with tail -f /var/log/messages

There are also some hw.usb settings you can twiddle. sysctl hw.usb.xhci

You could try and disable XHCI in the BIOS

213713 – xhci and ehci interrupt storms

bugs.freebsd.org bugs.freebsd.org
Click to expand...

I will investigate!

mark_j said:
Interrupts are a natural part of a functioning operating system, so on that basis alone, these figures mean nothing. Perhaps watching the interrupts increase when you experience the lag is more relevant, but it still won't tell you what the problem is. I mean, I don't know whether that rate of interrupts is ok for such a bus. Are there other devices sharing it?

(I will counter that with the fact it might be experiencing an "interrupt storm" at the point of lag and that would be evident if watching vmstat when it happens).




Fair enough. You can raise a bug report now, continue with the consultation in the forums and if it gets solved, close the bug. What the bug report does do is make those responsible know of this issue (given it's gone on a long time).

When you plug this device in, what does usbconfig show? For example, if the device is ugen0.4 then what does usbconfig -d ugen0.4 dump_device_desc display?

Also, more information on the machine you're running would be informative, if you can.
Click to expand...

Yes, I do know that interrupts are normal and serve their purpose (though I wouldn't know why one is necessarily fine to have a high count...stuff I have forgotten)...I've been trying to watch, but perhaps I have been watching the wrong way. My DAC is on its own hub (in my case, ugen2.1 is my XHCI root hub and ugen2.2 is my DAC)...here is the output for the command you said, including that of the hub it's connected to (I say hub because that's what the output says, this is direct to the motherboard):

Code: 
~ » usbconfig -d ugen2.1 dump_device_desc
ugen2.1: <0x1022 XHCI root HUB> at usbus2, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0300
  bDeviceClass = 0x0009  <HUB>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0003
  bMaxPacketSize0 = 0x0009
  idVendor = 0x0000
  idProduct = 0x0000
  bcdDevice = 0x0100
  iManufacturer = 0x0001  <0x1022>
  iProduct = 0x0002  <XHCI root HUB>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

~ » usbconfig -d ugen2.2 dump_device_desc
ugen2.2: <FiiO DigiHug USB Audio> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0110
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0008
  idVendor = 0x1852
  idProduct = 0x7022
  bcdDevice = 0x0001
  iManufacturer = 0x0001  <FiiO>
  iProduct = 0x0002  <DigiHug USB Audio>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001

What other info do you want about the machine? Hardware?
 
stratacast1 said:
What other info do you want about the machine? Hardware?
Click to expand...

Most particularly any other devices connected on that bus. You've stated that above.

To clarify, the DAC is self powered? It is connected by its own cable to a USB port on your machine, not an external hub?
What is the output of
sysctl dev.pcm
and
sysctl hw.usb

Also, perhaps the dmesg portion relevant to the device?
 
mark_j said:
To clarify, the DAC is self powered? It is connected by its own cable to a USB port on your machine, not an external hub?
Click to expand...

That is correct. It's plugged straight into my desktop's motherboard and both data and power are sent over that single USB

`sysctl dev.pcm`

Code: 
dev.pcm.7.feedback_rate: 0
dev.pcm.7.mixer.mute_1.desc: DigiHug USB Audio
dev.pcm.7.mixer.mute_1.max: 1
dev.pcm.7.mixer.mute_1.min: 0
dev.pcm.7.mixer.mute_1.val: 0
dev.pcm.7.mixer.vol_0_1.desc: DigiHug USB Audio
dev.pcm.7.mixer.vol_0_1.max: 0
dev.pcm.7.mixer.vol_0_1.min: -14080
dev.pcm.7.mixer.vol_0_1.val: 0
dev.pcm.7.mixer.vol_0_0.desc: DigiHug USB Audio
dev.pcm.7.mixer.vol_0_0.max: 0
dev.pcm.7.mixer.vol_0_0.min: -14080
dev.pcm.7.mixer.vol_0_0.val: 0
dev.pcm.7.bitperfect: 0
dev.pcm.7.buffersize: 0
dev.pcm.7.rec.vchanformat: s16le:2.0
dev.pcm.7.rec.vchanrate: 48000
dev.pcm.7.rec.vchanmode: fixed
dev.pcm.7.rec.vchans: 1
dev.pcm.7.play.vchanformat: s16le:2.0
dev.pcm.7.play.vchanrate: 48000
dev.pcm.7.play.vchanmode: fixed
dev.pcm.7.play.vchans: 3
dev.pcm.7.hwvol_mixer: vol
dev.pcm.7.hwvol_step: 5
dev.pcm.7.%parent: uaudio0
dev.pcm.7.%pnpinfo:
dev.pcm.7.%location:
dev.pcm.7.%driver: pcm
dev.pcm.7.%desc: USB audio
dev.pcm.6.bitperfect: 0
dev.pcm.6.buffersize: 65536
dev.pcm.6.play.vchanformat: s16le:2.0
dev.pcm.6.play.vchanrate: 48000
dev.pcm.6.play.vchanmode: passthrough
dev.pcm.6.play.vchans: 1
dev.pcm.6.play.32bit: 24
dev.pcm.6.%parent: hdaa1
dev.pcm.6.%pnpinfo:
dev.pcm.6.%location: nid=30
dev.pcm.6.%driver: pcm
dev.pcm.6.%desc: Realtek ALC1220 (Rear Digital)
dev.pcm.5.bitperfect: 0
dev.pcm.5.buffersize: 65536
dev.pcm.5.rec.vchanformat: s16le:2.0
dev.pcm.5.rec.vchanrate: 48000
dev.pcm.5.rec.vchanmode: fixed
dev.pcm.5.rec.vchans: 1
dev.pcm.5.rec.autosrc: 2
dev.pcm.5.rec.32bit: 24
dev.pcm.5.play.vchanformat: s16le:2.0
dev.pcm.5.play.vchanrate: 48000
dev.pcm.5.play.vchanmode: fixed
dev.pcm.5.play.vchans: 1
dev.pcm.5.play.32bit: 24
dev.pcm.5.%parent: hdaa1
dev.pcm.5.%pnpinfo:
dev.pcm.5.%location: nid=27,25
dev.pcm.5.%driver: pcm
dev.pcm.5.%desc: Realtek ALC1220 (Front Analog)
dev.pcm.4.bitperfect: 0
dev.pcm.4.buffersize: 65536
dev.pcm.4.rec.vchanformat: s16le:2.0
dev.pcm.4.rec.vchanrate: 48000
dev.pcm.4.rec.vchanmode: fixed
dev.pcm.4.rec.vchans: 1
dev.pcm.4.rec.autosrc: 2
dev.pcm.4.rec.32bit: 24
dev.pcm.4.play.vchanformat: s16le:2.0
dev.pcm.4.play.vchanrate: 48000
dev.pcm.4.play.vchanmode: fixed
dev.pcm.4.play.vchans: 1
dev.pcm.4.play.32bit: 24
dev.pcm.4.%parent: hdaa1
dev.pcm.4.%pnpinfo:
dev.pcm.4.%location: nid=20,22,21,24,26
dev.pcm.4.%driver: pcm
dev.pcm.4.%desc: Realtek ALC1220 (Rear Analog 5.1/2.0)
dev.pcm.3.bitperfect: 0
dev.pcm.3.buffersize: 65536
dev.pcm.3.play.vchanformat: s16le:2.0
dev.pcm.3.play.vchanrate: 48000
dev.pcm.3.play.vchanmode: passthrough
dev.pcm.3.play.vchans: 1
dev.pcm.3.play.32bit: 24
dev.pcm.3.%parent: hdaa0
dev.pcm.3.%pnpinfo:
dev.pcm.3.%location: nid=7
dev.pcm.3.%driver: pcm
dev.pcm.3.%desc: NVIDIA (0x0083) (HDMI/DP 8ch)
dev.pcm.2.bitperfect: 0
dev.pcm.2.buffersize: 65536
dev.pcm.2.play.vchanformat: s16le:2.0
dev.pcm.2.play.vchanrate: 48000
dev.pcm.2.play.vchanmode: passthrough
dev.pcm.2.play.vchans: 1
dev.pcm.2.play.32bit: 24
dev.pcm.2.%parent: hdaa0
dev.pcm.2.%pnpinfo:
dev.pcm.2.%location: nid=6
dev.pcm.2.%driver: pcm
dev.pcm.2.%desc: NVIDIA (0x0083) (HDMI/DP 8ch)
dev.pcm.1.bitperfect: 0
dev.pcm.1.buffersize: 65536
dev.pcm.1.play.vchanformat: s16le:2.0
dev.pcm.1.play.vchanrate: 48000
dev.pcm.1.play.vchanmode: passthrough
dev.pcm.1.play.vchans: 1
dev.pcm.1.play.32bit: 24
dev.pcm.1.%parent: hdaa0
dev.pcm.1.%pnpinfo:
dev.pcm.1.%location: nid=5
dev.pcm.1.%driver: pcm
dev.pcm.1.%desc: NVIDIA (0x0083) (HDMI/DP 8ch)
dev.pcm.0.bitperfect: 0
dev.pcm.0.buffersize: 65536
dev.pcm.0.play.vchanformat: s16le:2.0
dev.pcm.0.play.vchanrate: 48000
dev.pcm.0.play.vchanmode: passthrough
dev.pcm.0.play.vchans: 1
dev.pcm.0.play.32bit: 24
dev.pcm.0.%parent: hdaa0
dev.pcm.0.%pnpinfo:
dev.pcm.0.%location: nid=4
dev.pcm.0.%driver: pcm
dev.pcm.0.%desc: NVIDIA (0x0083) (HDMI/DP 8ch)
dev.pcm.%parent:

`sysctl hw.usb`

Code: 
hw.usb.ums.debug: 0
hw.usb.uaudio.buffer_ms: 8
hw.usb.uaudio.default_channels: 0
hw.usb.uaudio.default_bits: 24
hw.usb.uaudio.default_rate: 96000
hw.usb.uaudio.debug: 0
hw.usb.wmt.debug: 0
hw.usb.uhid.debug: 0
hw.usb.ukbd.pollrate: 0
hw.usb.ukbd.no_leds: 0
hw.usb.ukbd.debug: 0
hw.usb.full_ddesc: 0
hw.usb.no_cs_fail: 0
hw.usb.proc.debug: 0
hw.usb.disable_port_power: 0
hw.usb.disable_enumeration: 0
hw.usb.power_timeout: 30
hw.usb.uhub.debug: 0
hw.usb.ugen.debug: 0
hw.usb.usb_lang_mask: 255
hw.usb.usb_lang_id: 9
hw.usb.template: -1
hw.usb.dev.debug: 0
hw.usb.timings.extra_power_up_time: 20
hw.usb.timings.resume_recovery: 50
hw.usb.timings.resume_wait: 50
hw.usb.timings.resume_delay: 250
hw.usb.timings.set_address_settle: 10
hw.usb.timings.port_resume_delay: 40
hw.usb.timings.port_powerup_delay: 300
hw.usb.timings.port_reset_recovery: 250
hw.usb.timings.port_root_reset_delay: 200
hw.usb.timings.port_reset_delay: 50
hw.usb.debug: 0
hw.usb.umass.throttle: 0
hw.usb.umass.debug: 0
hw.usb.no_shutdown_wait: 0
hw.usb.no_suspend_wait: 0
hw.usb.no_boot_wait: 0
hw.usb.ctrl.debug: 0
hw.usb.xhci.ctlstep: 0
hw.usb.xhci.dma32: 0
hw.usb.xhci.use_polling: 0
hw.usb.xhci.xhci_port_route: 0
hw.usb.xhci.debug: 0
hw.usb.xhci.streams: 0
hw.usb.uhci.loop: 0
hw.usb.uhci.debug: 0
hw.usb.ohci.debug: 0
hw.usb.ehci.lostintrbug: 0
hw.usb.ehci.iaadbug: 0
hw.usb.ehci.no_hs: 0
hw.usb.ehci.debug: 0


And here is the info pertaining to my USB device

Code: 
uhid1 on uhub2
uhid1: <FiiO DigiHug USB Audio, class 0/0, rev 1.10/0.01, addr 1> on usbus2
uaudio0 on uhub2
uaudio0: <FiiO USB DAC-E10> on usbus2
uaudio0: Play: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Play: 32000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 96000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 44100 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 32000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 16000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 8000 Hz, 2 ch, 24-bit S-LE PCM format, 2x8ms buffer.
uaudio0: No MIDI sequencer.
pcm7: <USB audio> on uaudio0
uaudio0: HID volume keys found.
 
This is all going to be trial and error and guesswork, I think... :-/

I forgot to ask, is this a machine that sleeps? If so, does the problem manifest itself after waking from sleep?

It's interesting your device has this setting:
Code: 
dev.pcm.7.bitperfect: 0
dev.pcm.7.buffersize: 0

I wonder if a) it accepts a buffersize and b) if you can set it?
Perhaps try setting it to what the others are 65536.

Also, set
hw.usb.xhci.debug: 0
to a value > 10 and then test with video/audio playback.
sysctl hw.usb.xhci.debug=10

This will throw a lot of output into /var/log/messages so you might want to run a rotate of the log beforehand.
newsyslog -R "Log rotated" /var/log/messages

Note down the time when it pauses and for how long if possible as we need to match them up (as best we can do). You can run systat -v in a terminal to see if anything weird pops out.

Oh, to turn off logging after you're finished, just set it back to zero:
sysctl hw.usb.xhci.debug=0

I think the timing settings might need a tweak, but that's laborious because I think you have to reboot after each change. I will check.
 
Hey there! Been a little bit too busy to do the debug on my USB yet, but I found out that dev.pcm.7.buffersize is a read-only value
 
You must log in or register to reply here.
Back
Top