Hi folks.
I'm wondering if anybody runs a similar, to my current ""RPi4 - Khadas Toneboard USB-DAC"" config.
So far pretty much everything is working fine.
I really like the DAC. I currently prefer it over all the HATs (Audiophonics/Allo/IanCanda Fifo/Hifiberry/Mambo...) I have/had around here.
However. There's one odd thing. It might be a potential issue.
I'm currently running latest Raspbian and squeezelite. 32 or 64 bit kernel.
What I found is that the RPi4 shows more then 2000 IRQs/second
on the USB interface as soon as squeezelite locks the interface.
I havn't been running USB DACs for a long time. I'm not sure if this is normal
behavior in isynchronous USB-DAC operation mode!?!?
I'd appreciate if somebody could try below measurement (just copy/paste into a terminal).
The snippet just counts the IRQs per second.
squeezelite or mpd should be up'n running to have the IF locked.
Thx.
I'm wondering if anybody runs a similar, to my current ""RPi4 - Khadas Toneboard USB-DAC"" config.
So far pretty much everything is working fine.
I really like the DAC. I currently prefer it over all the HATs (Audiophonics/Allo/IanCanda Fifo/Hifiberry/Mambo...) I have/had around here.
However. There's one odd thing. It might be a potential issue.
I'm currently running latest Raspbian and squeezelite. 32 or 64 bit kernel.
What I found is that the RPi4 shows more then 2000 IRQs/second
on the USB interface as soon as squeezelite locks the interface.
I havn't been running USB DACs for a long time. I'm not sure if this is normal
behavior in isynchronous USB-DAC operation mode!?!?
I'd appreciate if somebody could try below measurement (just copy/paste into a terminal).
The snippet just counts the IRQs per second.
squeezelite or mpd should be up'n running to have the IF locked.
Code:
count=$(cat /proc/interrupts | grep xhci_hcd | awk ‘{print $2}’)
for i in {1…9}
do
sleep 1
countnew=$(cat /proc/interrupts | grep xhci_hcd | awk ‘{print $2}’)
echo “sec $i: $(($countnew - $count))”
count=$countnew
done
Thx.
Last edited:
Post lsusb -v dump for the DAC to see the config. Since that DAC supports up to 384kHz/2ch/32b, I would not be surprised if they used bInterval=1 which means packet every highspeed frame (125us). Also the question is how often async feedbacks are sent, they must be handled right away -> IRQ.
USB capture in wireshark will show you how packets are distributed to URBs. Every urb will generate an interrupt. There will be other interrupts during the communication.
Try to raise alsa period size, it may (or not) increase URB size.
There is not much else you can do with async isochronous, the feedback must react fast for 384kHz/2ch/32b to avoid large buffers in the DAC (i.e. keeping latency low).
USB capture in wireshark will show you how packets are distributed to URBs. Every urb will generate an interrupt. There will be other interrupts during the communication.
Try to raise alsa period size, it may (or not) increase URB size.
There is not much else you can do with async isochronous, the feedback must react fast for 384kHz/2ch/32b to avoid large buffers in the DAC (i.e. keeping latency low).
THX for the feedback.
You're right: btinterval=1
You're right: btinterval=1
Code:
Bus 001 Device 003: ID 20b1:000a XMOS Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x20b1 XMOS Ltd
idProduct 0x000a
bcdDevice 1.04
iManufacturer 1 XMOS
iProduct 3 Khadas Tone Control
iSerial 0
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x011c
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 0mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 3 Khadas Tone Control
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 8
wTotalLength 0x0048
bmControls 0x00
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 41
bmAttributes 3 Internal programmable clock
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 9 XMOS Internal Clock
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 11 (CLOCK_SELECTOR)
bClockID 40
bNrInPins 1
baCSourceID(0) 41
bmControls 0x03
Clock Selector Control (read/write)
iClockSelector 8 XMOS Clock Selector
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 40
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
bmControls 0x0000
iTerminal 6 Khadas Tone Control
AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 10
bSourceID 2
bmaControls(0) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(1) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(2) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
iFeature 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 20
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 10
bCSourceID 40
bmControls 0x0000
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0308 1x 776 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 2
bBitResolution 16
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0184 1x 388 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x80000000
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0308 1x 776 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 10 XMOS DFU
Device Firmware Upgrade Interface Descriptor:
bLength 9
bDescriptorType 33
bmAttributes 7
Will Not Detach
Manifestation Tolerant
Upload Supported
Download Supported
wDetachTimeout 250 milliseconds
wTransferSize 64 bytes
bcdDFUVersion 1.10
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x011c
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 0mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 3 Khadas Tone Control
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 8
wTotalLength 0x0048
bmControls 0x00
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 41
bmAttributes 3 Internal programmable clock
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 9 XMOS Internal Clock
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 11 (CLOCK_SELECTOR)
bClockID 40
bNrInPins 1
baCSourceID(0) 41
bmControls 0x03
Clock Selector Control (read/write)
iClockSelector 8 XMOS Clock Selector
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 40
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
bmControls 0x0000
iTerminal 6 Khadas Tone Control
AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 10
bSourceID 2
bmaControls(0) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(1) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(2) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
iFeature 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 20
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 10
bCSourceID 40
bmControls 0x0000
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0308 1x 776 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 2
bBitResolution 16
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0184 1x 388 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 Khadas Tone Control
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x80000000
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 11 Analogue 1/SPDIF 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0308 1x 776 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 1
iInterface 10 XMOS DFU
Device Firmware Upgrade Interface Descriptor:
bLength 9
bDescriptorType 33
bmAttributes 7
Will Not Detach
Manifestation Tolerant
Upload Supported
Download Supported
wDetachTimeout 250 milliseconds
wTransferSize 64 bytes
bcdDFUVersion 1.10
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 2
Device Status: 0x0000
(Bus Powered)
The interesting thing.
Just with squeezelite locking the interface and no audio streamed
the - idle operation - IRQs are skyrocketing.
Just with squeezelite locking the interface and no audio streamed
the - idle operation - IRQs are skyrocketing.
"Idle" may not mean "no communication".
Check the wireshark USB capture, very useful for learning USB details.
EP OUT (data) bInterval = 1 -> every 125us
EP IN (async feedback) bInterval = 4 -> every 1ms
2000 IRQ/s is not surprising, just handling the async feedback takes 1000 IRQ/s
Check the wireshark USB capture, very useful for learning USB details.
EP OUT (data) bInterval = 1 -> every 125us
EP IN (async feedback) bInterval = 4 -> every 1ms
2000 IRQ/s is not surprising, just handling the async feedback takes 1000 IRQ/s
Thx, for confirming that the IRQ count ballpark is about right (or perhaps better: to be expected 😉 ).
I'll check out wireshark anyway.
I actually first realized the behavior while running my rt-kernel and the xhci_hcd
causing 17% CPU load. 😱 (and 24/96 wouldn't even be possible)
With the standard Raspbian kernels (32/64) all looks OK though.
That high CPU load made me also wonder about the performance or relevance of the new supposedly powerful GIC-400 interrupt controller on the Pi4,
that'd, as I assumed, offload the CPUs from IRQ stress. I guess I do lack quite some background knowledge here. 😉
Still a lot of question marks and a lot to learn. 😉
I'll check out wireshark anyway.
I actually first realized the behavior while running my rt-kernel and the xhci_hcd
causing 17% CPU load. 😱 (and 24/96 wouldn't even be possible)
With the standard Raspbian kernels (32/64) all looks OK though.
That high CPU load made me also wonder about the performance or relevance of the new supposedly powerful GIC-400 interrupt controller on the Pi4,
that'd, as I assumed, offload the CPUs from IRQ stress. I guess I do lack quite some background knowledge here. 😉
Still a lot of question marks and a lot to learn. 😉
The "advanced" IRQ controller offers useful options (prioritizing, virtual interrupts, etc - page 11 of http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf ), but the actual reaction to the IRQ must be done by the CPU.
RT kernel = more parallelization, smaller latencies, more shorter queues - all that requires more synchronization mechanisms + shorter sleeps => inevitably more CPU load. I keep saying all the time that RT kernel just offers lower latencies in exchange for higher CPU load. If the standard kernel handles the required timing OK, no reason to use the less-tested more-complicated more-difficult-to-troubleshoot RT kernel.
RT kernel = more parallelization, smaller latencies, more shorter queues - all that requires more synchronization mechanisms + shorter sleeps => inevitably more CPU load. I keep saying all the time that RT kernel just offers lower latencies in exchange for higher CPU load. If the standard kernel handles the required timing OK, no reason to use the less-tested more-complicated more-difficult-to-troubleshoot RT kernel.
I did some more tests.
I ran these tests several times.
1. Idle rates equal streaming rates.
2. 24/96 requires about 100 interrupts less then 44.1/16.
3. The idle interrupts seen after startup seem to default to 44.1/16.
Because if I stop 24/96 the IRQ number stays at the lower-100 rate in idle.
4. I didn't see any changes when changing periods from 4 to 8 and running the buffer at 140ms.
Code:
24/96
################
sc ~ # irq-count.sh
*** count: IRQs per second
*** IRQ: xhci_hcd
*** sec 0: 66655
*** sec +1: 2076
*** sec +2: 2024
*** sec +3: 2057
*** sec +4: 2072
*** sec +5: 2044
*** sec +6: 2041
*** sec +7: 2039
*** sec +8: 2040
*** sec +9: 2039
*** sec +10: 2023
*** avg/s: 2045
*** done
16/44.1
############
sc ~ # irq-count.sh
*** count: IRQs per second
*** IRQ: xhci_hcd
*** sec 0: 116361
*** sec +1: 2129
*** sec +2: 2125
*** sec +3: 2144
*** sec +4: 2118
*** sec +5: 2139
*** sec +6: 2143
*** sec +7: 2152
*** sec +8: 2130
*** sec +9: 2144
*** sec +10: 2122
*** avg/s: 2134
*** done
I ran these tests several times.
1. Idle rates equal streaming rates.
2. 24/96 requires about 100 interrupts less then 44.1/16.
3. The idle interrupts seen after startup seem to default to 44.1/16.
Because if I stop 24/96 the IRQ number stays at the lower-100 rate in idle.
4. I didn't see any changes when changing periods from 4 to 8 and running the buffer at 140ms.
Last edited:
The "advanced" IRQ controller offers useful options (prioritizing, virtual interrupts, etc - page 11 of http://infocenter.arm.com/help/topic/com.arm.doc.ddi0471a/DDI0471A_gic400_r0p0_trm.pdf ), but the actual reaction to the IRQ must be done by the CPU.
Yep. But before everything had to be done by the CPU. There got to be some offload.
And I simply do not understand why I still see all IRQs hooked to CPU0:
Code:
sc ~ # cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
3: 4185 8951 189118 35523 GICv2 30 Level arch_timer
6: 0 0 0 0 GICv2 112 Level bcm2708_fb DMA
8: 20385 0 0 0 GICv2 114 Level DMA IRQ
16: 565 0 0 0 GICv2 65 Level fe00b880.mailbox
20: 0 0 0 0 GICv2 169 Level brcmstb_thermal
21: 171044 0 0 0 GICv2 158 Level mmc1, mmc0
22: 0 0 0 0 GICv2 48 Level arm-pmu
23: 0 0 0 0 GICv2 49 Level arm-pmu
24: 0 0 0 0 GICv2 50 Level arm-pmu
25: 0 0 0 0 GICv2 51 Level arm-pmu
34: 24 0 0 0 GICv2 66 Level VCHIQ doorbell
36: 2164362 0 0 0 Brcm_MSI 524288 Edge xhci_hcd
IPI0: 15632 244023 13027 34663 Rescheduling interrupts
IPI1: 77 555 732 63 Function call interrupts
Yep. But before everything had to be done by the CPU. There got to be some offload.
And I simply do not understand why I still see all IRQs hooked to CPU0:
Before that all IRQs were routed to CPU0 rpi 2: Unable to change irq affinity - Raspberry Pi Forums
The GIC could handle that, but IIUC it is not implemented yet Raspberry Pi 4 Benchmarks & Mini Review
Even if the routing is implemented, the load will not drop noticeably. The GIC does not run any handling code, it is CPUs job.
2. 24/96 requires about 100 interrupts less then 44.1/16.
44.100 stream is distributed to uneven number of audio frames per usb frame/packet (9/10). Also, typically 44100-based streams have a varying number of frames per URB. 100/1000 is just that 10%. Again, wireshark will show you the details.
3. The idle interrupts seen after startup seem to default to 44.1/16.
Because if I stop 24/96 the IRQ number stays at the lower-100 rate in idle.
Again, look at wireshark for 44.1/16. You may see zeros being sent by the player, e.g.
4. I didn't see any changes when changing periods from 4 to 8 and running the buffer at 140ms.
OK, good to know.
Although I don't have a RPI4 I did some tests on another board (Odroid C2) which suffers from a pretty crappy USB implmentation that is causing thousands of interrupts per second.
Hardware
- Odroid C2
- DIY 9018K2M with DIYINHK XMOS (I tested with other DACs too - the situation is the same)
The OS:
- A crappy old ArchlinuxARM installation for tests
- kernel 5.4.2 without even PREEMPT (voluntary preemption enabled)
- MPD 0.21.16
Ethernet interrupts are sent to the 3rd core, while USB interrupts are sent to the 4th. MPD uses the 2nd core.
I usually use CPU isolation, but I did the tests while I was building a kernel, so isolation was disabled.
The governor used was Performance.
CPU use while performing the tests:
idle:
16/44.1:
24/96
24/192
DSD 128 (native)
DXD 352
As I mentioned earlier, all these tests were performed while my new kernel was being built so CPU.
The kernel used in this test is the worst choice if one really cares about OS latency.
As you can see, this crappy board produces A HELL of interrupts, but there are ZERO issues with music reproduction even with DXD 352.
When CPU is not under stress and ex. the DXD file is being reproduced, the 4th core which handles the USB interrupts gets a CPU load of 6-8%.
I know that everything I posted are for a different board, but I find it really strange that with 2000 interrupts/sec you could not listen to even 24/96.
Have you tried with a non RT kernel, in case it's a bug caused by the RT patch?
Greetings,
Mike
Hardware
- Odroid C2
- DIY 9018K2M with DIYINHK XMOS (I tested with other DACs too - the situation is the same)
The OS:
- A crappy old ArchlinuxARM installation for tests
- kernel 5.4.2 without even PREEMPT (voluntary preemption enabled)
- MPD 0.21.16
Ethernet interrupts are sent to the 3rd core, while USB interrupts are sent to the 4th. MPD uses the 2nd core.
I usually use CPU isolation, but I did the tests while I was building a kernel, so isolation was disabled.
The governor used was Performance.
CPU use while performing the tests:
idle:
Code:
“sec 1: 8156”
“sec 2: 8292”
“sec 3: 8172”
“sec 4: 8180”
“sec 5: 8222”
“sec 6: 8179”
“sec 7: 8162”
“sec 8: 8170”
“sec 9: 8198”
Code:
“sec 1: 8704”
“sec 2: 8680”
“sec 3: 8834”
“sec 4: 8625”
“sec 5: 8800”
“sec 6: 8722”
“sec 7: 8597”
“sec 8: 8763”
“sec 9: 8762”
Code:
“sec 1: 14020”
“sec 2: 14626”
“sec 3: 14436”
“sec 4: 14365”
“sec 5: 14442”
“sec 6: 15211”
“sec 7: 14005”
“sec 8: 14431”
“sec 9: 14279”
Code:
“sec 1: 16470”
“sec 2: 16513”
“sec 3: 16557”
“sec 4: 16561”
“sec 5: 16159”
“sec 6: 16456”
“sec 7: 16795”
“sec 8: 16541”
“sec 9: 16573”
Code:
“sec 1: 16262”
“sec 2: 16157”
“sec 3: 16124”
“sec 4: 16384”
“sec 5: 16266”
“sec 6: 16053”
“sec 7: 16243”
“sec 8: 16136”
“sec 9: 15985”
Code:
“sec 1: 16741”
“sec 2: 16616”
“sec 3: 16550”
“sec 4: 16891”
“sec 5: 16433”
“sec 6: 16570”
“sec 7: 16519”
“sec 8: 16584”
“sec 9: 16726”
The kernel used in this test is the worst choice if one really cares about OS latency.
As you can see, this crappy board produces A HELL of interrupts, but there are ZERO issues with music reproduction even with DXD 352.
When CPU is not under stress and ex. the DXD file is being reproduced, the 4th core which handles the USB interrupts gets a CPU load of 6-8%.
I know that everything I posted are for a different board, but I find it really strange that with 2000 interrupts/sec you could not listen to even 24/96.
Have you tried with a non RT kernel, in case it's a bug caused by the RT patch?
Greetings,
Mike
Last edited:
tuxx: Please can you post lsusb -v dump for your DIYINHK XMOS? Thanks.
Code:
Bus 001 Device 004: ID 20b1:2009 XMOS Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x20b1 XMOS Ltd
idProduct 0x2009
bcdDevice 15.21
iManufacturer 1 DIYINHK
iProduct 3 DIYINHK USB Audio 2.0
iSerial 0
bNumConfigurations 2
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x010a
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 3 DIYINHK USB Audio 2.0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 8
wTotalLength 0x0048
bmControls 0x00
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 41
bmAttributes 3 Internal programmable clock
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 9 DIYINHK Internal Clock
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 11 (CLOCK_SELECTOR)
bClockID 40
bNrInPins 1
baCSourceID(0) 41
bmControls 0x03
Clock Selector Control (read/write)
iClockSelector 13 (error)
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 40
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 1
bmControls 0x0000
iTerminal 6 DIYINHK USB Audio 2.0 Output
AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 10
bSourceID 2
bmaControls(0) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(1) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(2) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
iFeature 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 20
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 10
bCSourceID 40
bmControls 0x0000
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 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 0x0188 1x 392 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 2
bBitResolution 16
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x00c4 1x 196 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x80000000
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0188 1x 392 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x010a
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 1 Audio
bFunctionSubClass 0
bFunctionProtocol 32
iFunction 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 1 Control Device
bInterfaceProtocol 32
iInterface 3 DIYINHK USB Audio 2.0
AudioControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdADC 2.00
bCategory 8
wTotalLength 0x0048
bmControls 0x00
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 41
bmAttributes 3 Internal programmable clock
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 9 DIYINHK Internal Clock
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 11 (CLOCK_SELECTOR)
bClockID 40
bNrInPins 1
baCSourceID(0) 41
bmControls 0x03
Clock Selector Control (read/write)
iClockSelector 13 (error)
AudioControl Interface Descriptor:
bLength 17
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bCSourceID 40
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 1
bmControls 0x0000
iTerminal 6 DIYINHK USB Audio 2.0 Output
AudioControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 6 (FEATURE_UNIT)
bUnitID 10
bSourceID 2
bmaControls(0) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(1) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
bmaControls(2) 0x0000000f
Mute Control (read/write)
Volume Control (read/write)
iFeature 0
AudioControl Interface Descriptor:
bLength 12
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 20
wTerminalType 0x0301 Speaker
bAssocTerminal 0
bSourceID 10
bCSourceID 40
bmControls 0x0000
iTerminal 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 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 0x0188 1x 392 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x00000001
PCM
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 2
bBitResolution 16
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x00c4 1x 196 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 1 Audio
bInterfaceSubClass 2 Streaming
bInterfaceProtocol 32
iInterface 4 DIYINHK USB Audio 2.0 Output
AudioStreaming Interface Descriptor:
bLength 16
bDescriptorType 36
bDescriptorSubtype 1 (AS_GENERAL)
bTerminalLink 2
bmControls 0x00
bFormatType 1
bmFormats 0x80000000
bNrChannels 2
bmChannelConfig 0x00000000
iChannelNames 10 Analogue 1
AudioStreaming Interface Descriptor:
bLength 6
bDescriptorType 36
bDescriptorSubtype 2 (FORMAT_TYPE)
bFormatType 1 (FORMAT_TYPE_I)
bSubslotSize 4
bBitResolution 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0188 1x 392 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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 17
Transfer Type Isochronous
Synch Type None
Usage Type Feedback
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 4
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 2
Device Status: 0x0001
Self Powered
BTW below you may find the interrupts without any USB device attached:
Code:
“sec 1: 8344”
“sec 2: 8216”
“sec 3: 8256”
“sec 4: 8241”
“sec 5: 8238”
“sec 6: 8270”
“sec 7: 8210”
“sec 8: 8182”
“sec 9: 8229”
This is a well-known issue of the Odroid C2.
Thanks. bInterval=1 EP OUT and 4 EP IN feedback for all samplerates/bitwidths (16, 24, 32). I am working on Linux USB-Audio Gadget (RPi4 OTG) and every async lsusb dump is handy.
* I'm currently running the default Raspbian kernel (low latency desktop).
* 24/96 does work if I transcode on the server btw.
* I do have the alsa output thread assigned to a separate and isolated processor
(perhaps I should rewind to 0 and start form the most basic setup)
* I do run onboard-wifi. But that shouldn't interfere with USB.
* The RPI folks are still tinkering in the GIC area for the PI4. The PI4 IMO still is work-in- progress.
I gonna have a closer look at all this if I find time.
Anyhow. It seems with 2000k interrupts/second I'm doing quite well. 😉
* 24/96 does work if I transcode on the server btw.
* I do have the alsa output thread assigned to a separate and isolated processor
(perhaps I should rewind to 0 and start form the most basic setup)
* I do run onboard-wifi. But that shouldn't interfere with USB.
* The RPI folks are still tinkering in the GIC area for the PI4. The PI4 IMO still is work-in- progress.
I gonna have a closer look at all this if I find time.
Anyhow. It seems with 2000k interrupts/second I'm doing quite well. 😉
@tuxx
Slighty off topic:
Just saw that your XMOS reports being selfpowered.
One thing is nagging me about the Khadas. You can backpower it through GPIO
and it still reports "buspowered". I guess that's why Khadas still requires VBUS
to be present. If I cut VBUS the TB simply won't work. Not sure if this is a simple
FW issue.
Slighty off topic:
Just saw that your XMOS reports being selfpowered.
One thing is nagging me about the Khadas. You can backpower it through GPIO
and it still reports "buspowered". I guess that's why Khadas still requires VBUS
to be present. If I cut VBUS the TB simply won't work. Not sure if this is a simple
FW issue.
My XMOS is indeed self-powered. However I really don't know if the lsusb report should give a real-time information on the method of powering the XMOS board or not.
Regarding the interrupts I did some further tests.
I did a fresh ArchlinuxARM installaiton on my C2 and compiled and installed:
- linux-aarch64 5.4.3 with CONFIG_PREEMPT
- squeezelite 1.9.2.1165
Squeezelite runs on the 2nd core, while ethernet/usb interrupts run on 3rd/4th.
The first thing I noticed is an increase in interrupts:
idle
16/44.1
24/96
24/192
DXD 352
Squeezelite was able to perform fine in all the situations above.
The increase in interrupts has nothing to do with squeezelite. The reason for this change is the CONFIG_PREEMPT.
Again, it's obvious that this is a different board, but our difference in interrupts is huge and I am 100% sure that the RPI4 should be able to handle much more than 2k/sec without any issue.
I am really curious to read your feedback on this issue, as I have decided to buy the RPI4 and make it my default board. I am too tired with hardkernel/odroid and their inability to offer a recent and reliable kernel for C2 (linux-aarch64 which I run is a generic aarch64 kernel and not a C2 specific).
Regarding the interrupts I did some further tests.
I did a fresh ArchlinuxARM installaiton on my C2 and compiled and installed:
- linux-aarch64 5.4.3 with CONFIG_PREEMPT
- squeezelite 1.9.2.1165
Squeezelite runs on the 2nd core, while ethernet/usb interrupts run on 3rd/4th.
The first thing I noticed is an increase in interrupts:
idle
Code:
“sec 1: 9281”
“sec 2: 9281”
“sec 3: 9279”
“sec 4: 9218”
“sec 5: 9279”
“sec 6: 9280”
“sec 7: 9281”
“sec 8: 9215”
“sec 9: 9282”
16/44.1
Code:
“sec 1: 9321”
“sec 2: 9288”
“sec 3: 9260”
“sec 4: 9229”
“sec 5: 9216”
“sec 6: 9331”
“sec 7: 9294”
“sec 8: 9215”
“sec 9: 9311”
24/96
Code:
“sec 1: 16386”
“sec 2: 16321”
“sec 3: 16319”
“sec 4: 16316”
“sec 5: 16320”
“sec 6: 16325”
“sec 7: 16320”
“sec 8: 16321”
“sec 9: 16321”
24/192
Code:
“sec 1: 16439”
“sec 2: 16522”
“sec 3: 16442”
“sec 4: 16453”
“sec 5: 16531”
“sec 6: 16362”
“sec 7: 16448”
“sec 8: 16517”
“sec 9: 16444”
DXD 352
Code:
“sec 1: 16401”
“sec 2: 16549”
“sec 3: 16461”
“sec 4: 16403”
“sec 5: 16498”
“sec 6: 16511”
“sec 7: 16400”
“sec 8: 16448”
“sec 9: 16548”
Squeezelite was able to perform fine in all the situations above.
The increase in interrupts has nothing to do with squeezelite. The reason for this change is the CONFIG_PREEMPT.
Again, it's obvious that this is a different board, but our difference in interrupts is huge and I am 100% sure that the RPI4 should be able to handle much more than 2k/sec without any issue.
I am really curious to read your feedback on this issue, as I have decided to buy the RPI4 and make it my default board. I am too tired with hardkernel/odroid and their inability to offer a recent and reliable kernel for C2 (linux-aarch64 which I run is a generic aarch64 kernel and not a C2 specific).
Last edited:
With rt-patch and full preempt, xhci was causing 14% load. Not good.
That went away immediately when going back to the standard kernel (configured as low latency desktop)
.
There's been a new rt-patch released just recently. I have to see what that one does.
BTW.
I have turned off HID in the kernel. No need to have it on a headless client. HID is pretty
intrusive.
***
Good decision to go for PI4. The PI4 project (firmware/drivers) is still not as mature as its siblings though. However. It's IMO good enough for using it now.
A pity that there's still no 64bit Raspbian. I had my own 64bit ALARM running.
However. I did switch from ALARM to Raspbian, simply because the PI4, with its work-in-progress environment, is currently much better supported under Raspbian.
That went away immediately when going back to the standard kernel (configured as low latency desktop)
.
There's been a new rt-patch released just recently. I have to see what that one does.
BTW.
I have turned off HID in the kernel. No need to have it on a headless client. HID is pretty
intrusive.
***
Good decision to go for PI4. The PI4 project (firmware/drivers) is still not as mature as its siblings though. However. It's IMO good enough for using it now.
A pity that there's still no 64bit Raspbian. I had my own 64bit ALARM running.
However. I did switch from ALARM to Raspbian, simply because the PI4, with its work-in-progress environment, is currently much better supported under Raspbian.
With regards to HID, I usually put a command like the following on a startup script:
but yes, why not disable it at all on a custom kernel.
As far as the ArchlinuxARM aarch64 for the RPI4 is concerned, as we speak I believe that there's a solution to a fully updated aarch64 OS:
rootfs
index - powered by h5ai v0.29.2
kernel
index - powered by h5ai v0.29.2
firmware
index - powered by h5ai v0.29.2
eeprom-update
GitHub - RoEdAl/al-rpi-eeprom: Raspberry Pi4 boot EEPROM updater [Arch Linux package]
or
AUR (en) - rpi-eeprom
However I haven't tested yet but I plan to do so very soon.
Code:
echo -n "x-x.x:x.x" > /sys/bus/usb/drivers/usbhid/unbind
As far as the ArchlinuxARM aarch64 for the RPI4 is concerned, as we speak I believe that there's a solution to a fully updated aarch64 OS:
rootfs
index - powered by h5ai v0.29.2
kernel
index - powered by h5ai v0.29.2
firmware
index - powered by h5ai v0.29.2
eeprom-update
GitHub - RoEdAl/al-rpi-eeprom: Raspberry Pi4 boot EEPROM updater [Arch Linux package]
or
AUR (en) - rpi-eeprom
However I haven't tested yet but I plan to do so very soon.
Last edited:
- Home
- Source & Line
- PC Based
- RPi4 and Khadas Toneboard - interrupt flooding !?!?