18 Jul
2018
18 Jul
'18
8:29 p.m.
Hi list,
I just re-installed my system partition with an kubuntu+kxstudio
repositories and I get some xruns in Jack2. I am trying to figure out
how to optimize my system configuration.
realtimeconfigquickscan gives me this:
== GUI-enabled checks ==
Checking if you are root... no - good
Checking filesystem 'noatime' parameter... 4.17.7 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors... CPU 0: 'performance' CPU 1: 'performance' CPU
2: 'performance' CPU 3: 'performance' CPU 4: 'performance' CPU 5:
'performance' CPU 6: 'performance' CPU 7: 'performance' - good
Checking swappiness... 10 - good
Checking for resource-intensive background processes... none found - good
Checking checking sysctl inotify max_user_watches... >= 524288 - good
Checking access to the high precision event timer... readable - good
Checking access to the real-time clock... readable - good
Checking whether you're in the 'audio' group... yes - good
Checking for multiple 'audio' groups... no - good
Checking the ability to prioritize processes with chrt... yes - good
Checking kernel support for high resolution timers... found - good
Kernel with Real-Time Preemption... not found - not good
Kernel without real-time capabilities found
For more information, see
http://wiki.linuxaudio.org/wiki/system_configuration#installing_a_real-time…
Checking if kernel system timer is high-resolution... found - good
Checking kernel support for tickless timer... found - good
== Other checks ==
Checking filesystem types... ok.
not found.
** Warning: no tmpfs partition mounted on /tmp
For more information, see:
- http://wiki.linuxaudio.org/wiki/system_configuration#tmpfs
- http://lowlatency.linuxaudio.org
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card's IRQ by looking at '/proc/interrupts' and lspci.
------------------
ok, so I'm looking at lspci:
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor DRAM Controller (rev 06)
Subsystem: Lenovo Xeon E3-1200 v3/4th Gen Core Processor DRAM
Controller
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel modules: ie31200_edac
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor PCI Express x16 Controller (rev 06) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00005000-00005fff
Memory behind bridge: f0000000-f0ffffff
Prefetchable memory behind bridge:
00000000c0000000-00000000d1ffffff
Capabilities: [88] Subsystem: Lenovo Xeon E3-1200 v3/4th Gen
Core Processor PCI Express x16 Controller
Capabilities: [80] Power Management version 3
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [a0] Express Root Port (Slot+), MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [140] Root Complex Link
Capabilities: [d94] #19
Kernel driver in use: pcieport
Kernel modules: shpchp
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core
Processor Integrated Graphics Controller (rev 06) (prog-if 00 [VGA
controller])
Subsystem: Lenovo 4th Gen Core Processor Integrated Graphics
Controller
Flags: bus master, fast devsel, latency 0, IRQ 28
Memory at f1000000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 6000 [size=64]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core
Processor HD Audio Controller (rev 06)
Subsystem: Lenovo Xeon E3-1200 v3/4th Gen Core Processor HD
Audio Controller
Flags: bus master, fast devsel, latency 0, IRQ 32
Memory at f2610000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo 8 Series/C220 Series Chipset Family USB xHCI
Flags: bus master, medium devsel, latency 0, IRQ 24
Memory at f2600000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Kernel driver in use: xhci_hcd
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series
Chipset Family MEI Controller #1 (rev 04)
Subsystem: Lenovo 8 Series/C220 Series Chipset Family MEI
Controller
Flags: bus master, fast devsel, latency 0, IRQ 29
Memory at f2619000 (64-bit, non-prefetchable) [size=16]
Capabilities: [50] Power Management version 3
Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
Kernel driver in use: mei_me
Kernel modules: mei_me
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2 (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo 8 Series/C220 Series Chipset Family USB EHCI
Flags: bus master, medium devsel, latency 0, IRQ 16
Memory at f261e000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci-pci
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset
High Definition Audio Controller (rev 04)
Subsystem: Lenovo 8 Series/C220 Series Chipset High Definition
Audio Controller
Flags: bus master, fast devsel, latency 0, IRQ 33
Memory at f2614000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #1 (rev d4) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: bfa00000-bfbfffff
Prefetchable memory behind bridge:
00000000bfc00000-00000000bfdfffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Lenovo 8 Series/C220 Series
Chipset Family PCI Express Root Port
Capabilities: [a0] Power Management version 3
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #3 (rev d4) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 18
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 00004000-00004fff
Memory behind bridge: f1e00000-f25fffff
Prefetchable memory behind bridge:
00000000f1400000-00000000f1bfffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Lenovo 8 Series/C220 Series
Chipset Family PCI Express Root Port
Capabilities: [a0] Power Management version 3
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #4 (rev d4) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 19
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 00003000-00003fff
Memory behind bridge: f1d00000-f1dfffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Lenovo 8 Series/C220 Series
Chipset Family PCI Express Root Port
Capabilities: [a0] Power Management version 3
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.4 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset
Family PCI Express Root Port #5 (rev d4) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0, IRQ 16
Bus: primary=00, secondary=05, subordinate=05, sec-latency=0
Memory behind bridge: f1c00000-f1cfffff
Capabilities: [40] Express Root Port (Slot+), MSI 00
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [90] Subsystem: Lenovo 8 Series/C220 Series
Chipset Family PCI Express Root Port
Capabilities: [a0] Power Management version 3
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1 (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo 8 Series/C220 Series Chipset Family USB EHCI
Flags: bus master, medium devsel, latency 0, IRQ 23
Memory at f261d000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port: BAR=1 offset=00a0
Capabilities: [98] PCI Advanced Features
Kernel driver in use: ehci-pci
00:1f.0 ISA bridge: Intel Corporation HM87 Express LPC Controller (rev 04)
Subsystem: Lenovo HM87 Express LPC Controller
Flags: bus master, medium devsel, latency 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset
Family 6-port SATA Controller 1 [AHCI mode] (rev 04) (prog-if 01 [AHCI 1.0])
Subsystem: Lenovo 8 Series/C220 Series Chipset Family 6-port
SATA Controller 1 [AHCI mode]
Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 26
I/O ports at 6088 [size=8]
I/O ports at 6094 [size=4]
I/O ports at 6080 [size=8]
I/O ports at 6090 [size=4]
I/O ports at 6060 [size=32]
Memory at f261c000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [70] Power Management version 3
Capabilities: [a8] SATA HBA v1.0
Kernel driver in use: ahci
Kernel modules: ahci
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family
SMBus Controller (rev 04)
Subsystem: Lenovo 8 Series/C220 Series Chipset Family SMBus
Controller
Flags: medium devsel, IRQ 255
Memory at f2618000 (64-bit, non-prefetchable) [size=256]
I/O ports at efa0 [size=32]
Kernel modules: i2c_i801
01:00.0 3D controller: NVIDIA Corporation GK208M [GeForce GT 740M] (rev a1)
Subsystem: Lenovo GK208M [GeForce GT 740M]
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at f0000000 (32-bit, non-prefetchable) [size=16M]
Memory at c0000000 (64-bit, prefetchable) [size=256M]
Memory at d0000000 (64-bit, prefetchable) [size=32M]
I/O ports at 5000 [size=128]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting <?>
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1
Len=024 <?>
Capabilities: [900] #19
Kernel driver in use: nvidia
Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5227
PCI Express Card Reader (rev 01)
Subsystem: Lenovo RTS5227 PCI Express Card Reader
Physical Slot: 1
Flags: bus master, fast devsel, latency 0, IRQ 25
Memory at f1e00000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-00-00-01-00-4c-e0-00
Capabilities: [150] Latency Tolerance Reporting
Capabilities: [158] L1 PM Substates
Kernel driver in use: rtsx_pci
Kernel modules: rtsx_pci
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
Subsystem: Lenovo RTL8111/8168/8411 PCI Express Gigabit
Ethernet Controller
Flags: bus master, fast devsel, latency 0, IRQ 19
I/O ports at 3000 [size=256]
Memory at f1d04000 (64-bit, non-prefetchable) [size=4K]
Memory at f1d00000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00
Capabilities: [170] Latency Tolerance Reporting
Capabilities: [178] L1 PM Substates
Kernel driver in use: r8169
Kernel modules: r8169
05:00.0 Network controller: Intel Corporation Wireless 7260 (rev 73)
Subsystem: Intel Corporation Wireless-N 7260
Flags: bus master, fast devsel, latency 0, IRQ 31
Memory at f1c00000 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 0c-8b-fd-ff-ff-66-0e-a9
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] Vendor Specific Information: ID=cafe Rev=1
Len=014 <?>
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi
--------------
My guess is that IRQ 32 and 33 are the internal sound card, maybe one of
them is the one that is serving the HDMI and the other one the headphone
jack.
Furthermore it looks like IRQ 16, 23 and 24 are USB controllers and on
one of them might be the external soundcard since it is connected via USB..
Which number do I need to assign to the SOUND_CARD_IRQ variable? I
assume it's an environment variable to be set like
"SOUND_CARD_IRQ=23"
in the terminal for realtimeconfigquickscan. However, even after setting
the variable realtimeconfigquickscan still gives me the info that I
should set the variable.
Is this IRQ business still something I need to worry about? (since most
info about it on the interwebs is from 2000 and prior).
Please advise
Thank you.
m.
18 Jul
18 Jul
8:49 p.m.
Hi Max,
for a start, do look at /proc/interrupts as suggestd by the script. Looking at
/proc/asound/cards will also give you a list of your currently recognised ALSA
soundcards.
Set the IRQ of the soundcard that you want to use for your realtime audio. And
probably do it with:
export VARIABLENAME=irq_number
(if you're in bash/sh).
Next, you might want to check your swap-space. I had problems with that. My
hard disk is a little slow and both swapping and recording/streaming from the
same disk might cause issues. If you're drive is new and fast enough: don't
worry.
If you're using JACK, check the periods and buffersize. Perhaps it's a little
low.
The quickscan script didn't find your filesystem types, it appears, unless
that was only the missing /tmp to which that "not found" referred. Check your
partition filesystems. You can look at /etc/fstab or /etc/mtab. The first
specifies how your partitions should be handled, but that might contain the
odd automatic discovery. mtab gives you the status quo of everything currently
mounted. Don't worry about all the /proc, /sys and /dev items.
In the end, you might want to install a kernel with realtime preemtion. Since
it's kubuntustudio, I exptect they have a preemt kernel in their package
repos.
HTH.
Best wishes,
Jeanette
--------
* Website: http://juliencoder.de - for summer is a state of sound
* SoundCloud: https://soundcloud.com/jeanette_c
* Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g
* GitHub: https://github.com/jeanette-c
* Twitter: https://twitter.com/jeanette_c_s
Ain't no way I'll be lonely <3
(Britney Spears)
9:27 p.m.
Hi Jeanette, thank you for your advice.
On 18.07.2018 18:49, Jeanette C. wrote:
for a start, do look at /proc/interrupts as suggestd
by the script.
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5
CPU6 CPU7
0: 22 0 0 0 0 0
0 0 IO-APIC 2-edge timer
1: 0 0 0 0 0 0
195 0 IO-APIC 1-edge i8042
8: 0 0 0 0 0 0
0 1 IO-APIC 8-edge rtc0
9: 0 6144 0 0 0 0
0 0 IO-APIC 9-fasteoi acpi
12: 0 0 0 0 0 499
0 0 IO-APIC 12-edge i8042
16: 0 0 31 0 0 0
0 0 IO-APIC 16-fasteoi ehci_hcd:usb1
23: 0 0 0 35 0 0
0 0 IO-APIC 23-fasteoi ehci_hcd:usb2
24: 0 55975374 0 0 753 0
0 0 PCI-MSI 327680-edge xhci_hcd
25: 22 0 0 0 0 0
0 0 PCI-MSI 1572864-edge rtsx_pci
26: 0 14018 0 0 0 0
350867 0 PCI-MSI 512000-edge ahci[0000:00:1f.2]
27: 0 0 0 0 122 0
0 581368 PCI-MSI 2097152-edge enp4s0
28: 0 0 748 1746778 0 0
0 0 PCI-MSI 32768-edge i915
29: 0 0 0 18 0 0
0 0 PCI-MSI 360448-edge mei_me
31: 0 0 0 0 0 12035
0 0 PCI-MSI 2621440-edge iwlwifi
32: 0 0 0 0 0 0
89 0 PCI-MSI 49152-edge snd_hda_intel:card0
33: 0 0 0 0 0 0
0 81843 PCI-MSI 442368-edge snd_hda_intel:card1
NMI: 229 233 244 137 188 99
147 107 Non-maskable interrupts
LOC: 8147412 11215181 8654677 7200413 6723892 2734777
4631806 2358955 Local timer interrupts
SPU: 0 0 0 0 0 0
0 0 Spurious interrupts
PMI: 229 233 244 137 188 99
147 107 Performance monitoring interrupts
IWI: 2900 885 1195 309101 1956 2702
5074 3143 IRQ work interrupts
RTR: 0 0 0 0 0 0
0 0 APIC ICR read retries
RES: 2223602 2119245 1217195 695903 667320 97291
114748 73705 Rescheduling interrupts
CAL: 895506 552115 863706 521526 842682 695239
1098867 768611 Function call interrupts
TLB: 842180 507316 819848 475430 799540 649222
1055178 722638 TLB shootdowns
TRM: 0 0 0 0 0 0
0 0 Thermal event interrupts
THR: 0 0 0 0 0 0
0 0 Threshold APIC interrupts
DFR: 0 0 0 0 0 0
0 0 Deferred Error APIC interrupts
MCE: 0 0 0 0 0 0
0 0 Machine check exceptions
MCP: 86 87 87 87 87 87
87 87 Machine check polls
HYP: 0 0 0 0 0 0
0 0 Hypervisor callback interrupts
HRE: 0 0 0 0 0 0
0 0 Hyper-V reenlightenment interrupts
HVS: 0 0 0 0 0 0
0 0 Hyper-V stimer0 interrupts
ERR: 0
MIS: 0
PIN: 0 0 0 0 0 0
0 0 Posted-interrupt notification event
NPI: 0 0 0 0 0 0
0 0 Nested posted-interrupt event
PIW: 0 0 0 0 0 0
0 0 Posted-interrupt wakeup event
I#m not sure how to read this table..
Looking at /proc/asound/cards will also give you a
list of your
currently recognised ALSA soundcards.
cat /proc/asound/cards
0 [HDMI ]: HDA-Intel - HDA Intel HDMI
HDA Intel HDMI at 0xf2610000 irq 32
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xf2614000 irq 33
2 [CODEC ]: USB-Audio - USB AUDIO CODEC
BurrBrown from Texas Instruments USB AUDIO CODEC
at usb-0000:00:14.0-1, full s
Set the IRQ of the soundcard that you want to use for
your realtime
audio. And probably do it with:
export VARIABLENAME=irq_number
(if you're in bash/sh).
For the card 2 this would be
"export SOUND_CARD_IRQ=usb-0000:00:14.0-1" ?
Next, you might want to check your swap-space. I had
problems with that.
My hard disk is a little slow and both swapping and recording/streaming
from the same disk might cause issues. If you're drive is new and fast
enough: don't worry.
It's a SSD. Not brand new, but reasonably fast I believe. I have a 2 GB
swap partition on the drive.
If you're using JACK, check the periods and
buffersize. Perhaps it's a
little low.
It is.. :)
The quickscan script didn't find your filesystem
types, it appears,
unless that was only the missing /tmp to which that "not found"
referred. Check your partition filesystems. You can look at /etc/fstab
or /etc/mtab. The first specifies how your partitions should be handled,
but that might contain the odd automatic discovery. mtab gives you the
status quo of everything currently mounted. Don't worry about all the
/proc, /sys and /dev items.
I think I am only missing /tmp, but does it matter? The rest of the file
system is ext4
In the end, you might want to install a kernel with
realtime preemtion.
Since it's kubuntustudio, I exptect they have a preemt kernel in their
package repos.
I am using a lowlatency kernel in a normal kubuntu with kxstudio repos,
not ubuntustudio. Is that a problem?
thanks
m.
9:52 p.m.
On Wed, 18 Jul 2018 19:27:26 +0200, Max wrote:
It depends. Most likely it isn't the culprit.
All that too long to read output doesn't really help. Yes, it's good
that there is the ability to use chrt to prioritize processes, but is
it done? Most of us are likely using Rui's rtirq script, which on
Ubuntu flavours not necessarily fits to the installed kernel.
What's the output of
/etc/rc.d/rtirq status
Consider to run jack and to post the output of jack.
If the output of
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
should be "powersave", then run
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
for testing purpose.
Don't troubleshoot by running too many command, start with simply
testing by using different USB ports.
BIOS settings might be important, too, but IMO you first should follow
my hints, before digging deeper.
I think I am only missing /tmp, but does it matter? The
rest of the
file system is ext4
You unlikely are missing a /tmp directory, it's most likely just not
set up for RAM disk usage and instead on the SSD, which is the default
for Ubuntu flavours.
Take a look at the output of
ls -d /tmp; df -h | grep tmp
Even if the SSD should be connected to a slow SATA port, it would be
fast enough for using /tmp without set up for RAM disk usage, so we
don't need to check this with smartctl.
In the end,
you might want to install a kernel with realtime
preemtion. Since it's kubuntustudio, I exptect they have a preemt
kernel in their package repos.
I am using a lowlatency kernel in a normal kubuntu with kxstudio
repos, not ubuntustudio. Is that a problem?
11:35 p.m.
On 18.07.2018 19:52, Ralf Mardorf wrote:
Consider to run jack and to post the output of jack.
I have a lot of those:
Wed Jul 18 21:31:05 2018: ERROR:
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Wed Jul 18 21:31:05 2018: Jack: Process: graph not finished!
Wed Jul 18 21:31:05 2018: Jack: Process: switch to next state delta = 4001
Wed Jul 18 21:31:05 2018: Jack: Process: graph not finished!
Wed Jul 18 21:31:05 2018: Jack: Process: waiting to switch delta = 1139
Wed Jul 18 21:31:05 2018: ERROR:
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Wed Jul 18 21:31:05 2018: Jack: Process: graph not finished!
Wed Jul 18 21:31:05 2018: Jack: Process: waiting to switch delta = 2140
Wed Jul 18 21:31:05 2018: ERROR:
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Wed Jul 18 21:31:05 2018: Jack: Process: graph not finished!
Wed Jul 18 21:31:05 2018: Jack: Process: switch to next state delta = 3972
If the output of
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
should be "powersave", then run
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
for testing purpose.
They are set to performance with the indicator-cpufreq
Don't troubleshoot by running too many command,
start with simply
testing by using different USB ports.
BIOS settings might be important, too, but IMO you first should follow
my hints, before digging deeper.
Thanks
10:01 p.m.
From: Ralf Mardorf <ralf.mardorf(a)rocketmail.com>
To: Max <abonnements(a)revolwear.com>om>, A list for linux audio users
<linux-audio-user(a)lists.linuxaudio.org> Subject: Re: [LAU] reducing
xruns (System configuration) Date: Wed, 18 Jul 2018 19:58:03 +0200
X-Mailer: Claws Mail 3.16.0git213 (GTK+ 2.24.32; x86_64-arch-linux-gnu)
On Wed, 18 Jul 2018 19:52:00 +0200, Ralf Mardorf wrote:
/etc/rc.d/rtirq status
Run
/etc/init.d/rtirq status
instead and also run
grep RTIRQ_NAME_LIST /etc/default/rtirq
10:14 p.m.
On Wed, July 18, 2018 12:27 pm, Max wrote:
On 18.07.2018 18:49, Jeanette C. wrote:
How low? There is quite a bit of variation in how low you can go with
USB devices, some run down to very low buffer sizes, some do not. Some
work fine with 2 buffers per period, some require 3 buffers per period to
run reliably.
Same with standard vs. low latency vs. RT kernels, with 1024 sample buffer
size you can run OK with a standard kernel. With 32 sample buffer size
(0.7ms) you will be unlikely (/understatement) to run reliably with a
standard kernel.
There have been multiple reports of WiFi drivers causing long delays in
scheduling, I noticed in your lspci output that there is a WiFi device in
your system. Try disabling that adapter (you will have to use google,
duck duck, etc. to find out how, I do not know how to make sure it is
completely turned off).
-- Chris Caudle
If you're using JACK, check the periods and
buffersize. Perhaps it's a
little low.
It is.. :)
10:44 p.m.
On Wed, 18 Jul 2018 13:14:29 -0500, Chris Caudle wrote:
On Wed, July 18, 2018 12:27 pm, Max wrote:
As already pointed out by a previous message, we don't know if the USB
audio interface has got rt priority. Or did I miss this information when
I skim through the long and mostly irrelevant output?
There are many pitfalls, but we should start with the most likely
pitfalls. To use jack with what ever low or not low settings, it's
first important to ensure, that the USB ports have got a reasonable
rt priority.
On 18.07.2018 18:49, Jeanette C. wrote:
How low? There is quite a bit of variation in how low you can go with
USB devices, some run down to very low buffer sizes, some do not. If you're using JACK, check the periods and
buffersize. Perhaps
it's a little low.
It is.. :)
11:28 p.m.
On 18.07.2018 20:14, Chris Caudle wrote:
On Wed, July 18, 2018 12:27 pm, Max wrote:
64 buffer size at 48kHz 2 Periods/Buffer
On 18.07.2018 18:49, Jeanette C. wrote:
How low? There is quite a bit of variation in how low you can go with
USB devices, some run down to very low buffer sizes, some do not. Some
work fine with 2 buffers per period, some require 3 buffers per period to
run reliably. If you're using JACK, check the periods and
buffersize. Perhaps it's a
little low.
It is.. :) Same with standard vs. low latency vs. RT kernels,
with 1024 sample buffer
size you can run OK with a standard kernel. With 32 sample buffer size
(0.7ms) you will be unlikely (/understatement) to run reliably with a
standard kernel.
There have been multiple reports of WiFi drivers causing long delays in
scheduling, I noticed in your lspci output that there is a WiFi device in
your system. Try disabling that adapter (you will have to use google,
duck duck, etc. to find out how, I do not know how to make sure it is
completely turned off).
I see, I will give this a try.
Thanks
11:57 p.m.
On Wed, July 18, 2018 2:28 pm, Max wrote:
64 buffer size at 48kHz 2 Periods/Buffer
That is low for USB devices. Not all USB devices can run reliably at that
low latency (around 1.3ms).
First try 3 periods/buffer, because of quirks regarding how buffers get
split into USB packets that can sometimes work more reliably.
Doubling the buffer size is still only around 2.7 ms, that is usually low
enough
Regarding the WiFi driver problem, I have never seen any documentation
that suggests someone has fully debugged the cause, but it seems to be
some drivers searching for wireless networks in interrupt context, or
something similar which disrupts the scheduler. I am not sure if that
still causes a problem with a fully RT patched kernel or not.
--
Chris Caudle
19 Jul
19 Jul
1:20 a.m.
On Wed, 18 Jul 2018 14:57:32 -0500
"Chris Caudle" <chris(a)chriscaudle.org> wrote:
On Wed, July 18, 2018 2:28 pm, Max wrote:
Something nobody seems to have mentioned is the command lsusb.
This will show you what is hanging on which bus. Ideally you want to try
different sockets until you find one that has nothing else on it.
Here is my 'office' one for example:
will@debian:~$ lsusb
Bus 005 Device 002: ID 8087:8000 Intel Corp.
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 003: ID 17cc:1001 Native Instruments
Bus 004 Device 002: ID 0227:0227
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 003: ID 04d9:1603 Holtek Semiconductor, Inc. Keyboard
Bus 002 Device 002: ID 046d:c018 Logitech, Inc. Optical Wheel Mouse
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
You'll see the NI KA6 is entirely on its own.
I don't know the sound card you are using, or how old it is, or even how well
it's firmware supports USB2, but USB2 speeds on modern cards can easily manage
64/2 at 48k. Indeed, mine can (just) manage 16/2 at 48k.
With a modern computer, supporting USB2 *high* speed you can get an effective
data rate very much faster than 1mS.
An except from:
https://www.edn.com/design/consumer/4376143/Fundamentals-of-USB-Audio
---------------------------------
A single isochronous transfer can carry 1024 bytes, and can carry at most 256
samples (at 24/32 bits). This means that a single isochronous endpoint can
transfer 42 channels at 48 kHz, or 10 channels at 192 kHz (assuming that High
Speed USB is used - Full Speed USB cannot carry more than a single stereo IN
and OUT pair at 48 kHz).
When transmitting digital audio, latency is introduced. In the case of High
Speed USB this latency is 250 us. A packet of data is transferred once in every
125 us window, but given that it may be sent anytime in this window a 250 us
buffer is required. On top of this 250 us delay, extra delay may be incurred in
the O/S driver, and in the CODEC. Note that Full Speed USB has a much higher
intrinsic latency of 2 ms, as data is only sent once in every 1 ms window.
---------------------------------
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
64 buffer size at 48kHz 2 Periods/Buffer
That is low for USB devices. Not all USB devices can run reliably at that
low latency (around 1.3ms).
First try 3 periods/buffer, because of quirks regarding how buffers get
split into USB packets that can sometimes work more reliably.
Doubling the buffer size is still only around 2.7 ms, that is usually low
enough
Regarding the WiFi driver problem, I have never seen any documentation
that suggests someone has fully debugged the cause, but it seems to be
some drivers searching for wireless networks in interrupt context, or
something similar which disrupts the scheduler. I am not sure if that
still causes a problem with a fully RT patched kernel or not.
4:32 p.m.
On 18.07.2018 23:20, Will Godfrey wrote:
Something nobody seems to have mentioned is the
command lsusb.
This will show you what is hanging on which bus. Ideally you want to try
different sockets until you find one that has nothing else on it.
[..]
I don't know the sound card you are using, or how
old it is, or even how well
it's firmware supports USB2, but USB2 speeds on modern cards can easily manage
64/2 at 48k. Indeed, mine can (just) manage 16/2 at 48k.
Thanks Will, that makes sense.
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 8087:07dc Intel Corp.
Bus 003 Device 021: ID 04b4:beef Cypress Semiconductor Corp.
Bus 003 Device 007: ID 046a:b090 Cherry GmbH
Bus 003 Device 008: ID 0424:4060 Standard Microsystems Corp. Ultra Fast
Media Reader
Bus 003 Device 005: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 006: ID 0bda:5719 Realtek Semiconductor Corp.
Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I assume that the bus can only be changed by physically attaching the
devices to different ports. Is that right? The audio interface (Texas
Instruments, A Behringer mixer) already is plugged in its own USB port,
I might see if a different port changes something.
4:49 p.m.
On Thu, 19 Jul 2018 14:32:49 +0200
Max <abonnements(a)revolwear.com> wrote:
On 18.07.2018 23:20, Will Godfrey wrote:
You want it on a different *bus*. It's on bus 003 and shared with quite a lot
of other stuff, including two additional hubs. The available bandwidth is shared
between all of these ports.
Try and get it on bus 004 if you can. That one is clean with just a linux root
hub.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
Something nobody seems to have mentioned is the
command lsusb.
This will show you what is hanging on which bus. Ideally you want to try
different sockets until you find one that has nothing else on it.
[..]
I don't know the sound card you are using, or
how old it is, or even how well
it's firmware supports USB2, but USB2 speeds on modern cards can easily manage
64/2 at 48k. Indeed, mine can (just) manage 16/2 at 48k.
Thanks Will, that makes sense.
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 8087:07dc Intel Corp.
Bus 003 Device 021: ID 04b4:beef Cypress Semiconductor Corp.
Bus 003 Device 007: ID 046a:b090 Cherry GmbH
Bus 003 Device 008: ID 0424:4060 Standard Microsystems Corp. Ultra Fast
Media Reader
Bus 003 Device 005: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 006: ID 0bda:5719 Realtek Semiconductor Corp.
Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I assume that the bus can only be changed by physically attaching the
devices to different ports. Is that right? The audio interface (Texas
Instruments, A Behringer mixer) already is plugged in its own USB port,
I might see if a different port changes something. 
5:10 p.m.
On 2018-07-19 14:49, Will Godfrey wrote:
On Thu, 19 Jul 2018 14:32:49 +0200
As this is 'Linux Foundation 3.0 root hub' then it will be a blue USB
3.0 socket or a USB-C socket. Even if the device is USB 2.0 or USB 1.1
it might work faster as the only device on the bus.
Jacek
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation
3.0 root hub
I assume that the bus can only be changed by physically attaching the
devices to different ports. Is that right? The audio interface (Texas
Instruments, A Behringer mixer) already is plugged in its own USB port,
I might see if a different port changes something.
You want it on a different *bus*. It's on bus 003 and shared with quite a lot
of other stuff, including two additional hubs. The available bandwidth is shared
between all of these ports.
Try and get it on bus 004 if you can. That one is clean with just a linux root
hub.
10:55 p.m.
On 19.07.2018 15:10, Jacek Konieczny wrote:
On 2018-07-19 14:49, Will Godfrey wrote:
Thanks Jacek, After looking into this I ordered the docking station for
mz laptop as this USB 3.0 Port is onlz available through the dock. Good
find!
m.
On Thu, 19 Jul 2018 14:32:49 +0200
As this is 'Linux Foundation 3.0 root hub' then it will be a blue USB
3.0 socket or a USB-C socket. Even if the device is USB 2.0 or USB 1.1
it might work faster as the only device on the bus. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation
3.0 root hub
I assume that the bus can only be changed by physically attaching the
devices to different ports. Is that right? The audio interface (Texas
Instruments, A Behringer mixer) already is plugged in its own USB port,
I might see if a different port changes something.
You want it on a different *bus*. It's on bus 003 and shared with quite a lot
of other stuff, including two additional hubs. The available bandwidth is shared
between all of these ports.
Try and get it on bus 004 if you can. That one is clean with just a linux root
hub.
20 Jul
20 Jul
12:16 a.m.
On Thu, 2018-07-19 at 20:55 +0200, Max wrote:
Thanks Jacek, After looking into this I ordered the
docking station for
mz laptop as this USB 3.0 Port is onlz available through the dock. Good
find!
To get a better house, somebody might need another load-bearing wall. To
get a better load-bearing wall, somebody might need a wallpaper.
Without doubts you need a load-bearing wall. You ordered a wallpaper,
the load-bearing wall does or doesn't need a wallpaper to fit your
taste, but you still didn't build the load-bearing wall, hence the
wallpaper isn't very useful, if useful at all.
As long as USB has got no rt priority, anything else unlikely will solve
the issue.
12:44 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Thu, 2018-07-19 at 20:55 +0200, Max wrote:
You are babbling. The goal was to find a USB hub not serving other
clients. And apparently the one best fitting the requirements was
routed to a docking station.
Another possibility would have been to use an Expresscard with USB 3
port(s). Obviously, an Expresscard using the PCIe lane, not the USB
connection of an Expresscard slot which would be useless unless it met
the requirement not to serve other clients. And the USB 3 ports would
be required not because of USB 3 speed but because an Expresscard with
USB 2 ports would be a whole lot more likely to use the USB connection
rather than the PCIe lane.
Thanks Jacek, After looking into this I ordered
the docking station for
mz laptop as this USB 3.0 Port is onlz available through the dock. Good
find!
To get a better house, somebody might need another load-bearing wall. To
get a better load-bearing wall, somebody might need a wallpaper.
Without doubts you need a load-bearing wall. You ordered a wallpaper,
the load-bearing wall does or doesn't need a wallpaper to fit your
taste, but you still didn't build the load-bearing wall, hence the
wallpaper isn't very useful, if useful at all. As long as USB has got no rt priority, anything else
unlikely will
solve the issue.
A lot of people get setups like that to work without rtirq .
--
David Kastrup
1:24 a.m.
On Thu, 2018-07-19 at 22:44 +0200, David Kastrup wrote:
You are babbling. [snip]
A lot of people get setups like that to work without rtirq .
Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC".
I'm not aware that a lot of people got this to work at all.
Is there any evidence for your claim? Perhaps a link to one of those lot
of people who get a setup like this right without rt priority for the
USB device? Such a link would be very helpful for the OP.
I try to help and as far as I know, there are not a lot of people who
get this to work at all.
Btw. if you reply to me, I don't receive a duplicated mail from the
mailing list, since I dislike receiving two times the same email. IOW
there will be no mailing list header in your replies to me. It's common
practise, part of netiquette, to reply to mailing lists only, as long as
it's not an open mailing list or as long as not a group of developers
should take attention to a mail, to a developers mailing list. While
this could happen by accident, you are doing it with intent again and
again. I don't care about your continuously derogatory tone of voice,
but its annoying when you continuously break mailing list headers. Plese
reply to the mailing list only.
Regards,
Ralf
2:25 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
Btw. if you reply to me, I don't receive a
duplicated mail from the
mailing list, since I dislike receiving two times the same email. IOW
there will be no mailing list header in your replies to me.
There will be no mailing list _footer_. The mailing list, of course, is
in the Cc field, and you have the option to "Reply to all" in order to
reply to both sender and mailing list, or just "Reply" in order to reply
only to the sender.
That is _exactly_ the same way you respond to mail sent via the list.
It's common practise, part of netiquette, to reply
to mailing lists
only, as long as it's not an open mailing list or as long as not a
group of developers should take attention to a mail, to a developers
mailing list.
Linux-audio-user is not a developer list, and it is an open list
according to its list page
https://lists.linuxaudio.org/listinfo/linux-audio-user which means that
posters to it are not necessarily subscribed.
While this could happen by accident, you are doing it
with intent
again and again. I don't care about your continuously derogatory tone
of voice, but its annoying when you continuously break mailing list
headers.
I don't "break mailing list headers". I use "Reply to All" in
order to
reply to all. The alternative would be "Reply", replying to just you.
Other options would be more esoteric.
The mail I replied to had the following headers regarding routing:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: linux-audio-user(a)lists.linuxaudio.org
That's it. No "Mail-Reply-To:", no "List-Reply-To:", no
"Reply-To:".
The mailing list itself was in the "Sender:" header, but it's not normal
to reply to that.
Plese reply to the mailing list only.
Look, you set your mailing list options _exactly_ to "avoid duplicates"
in order _not_ to receive duplicate mails. Now you complain that you
don't receive mails sent via the mailing list.
At some point of time, you need to decide yourself.
The way the mailing list is set up to operate, the options for replying
with standard mail clients are either _only_ to the author of a mail, or
to "all" which includes Cc: and To: fields.
If you want everybody answering you on the list to use his mail client
in non-standard manners specifically for replying to you, you have an
upstream battle before you. Alternatively, try convincing the list
owners to set up the mailing list headers differently in order to have
them match your idea of "netiquette". That would likely involve setting
at least a "List-Reply-To:" header (which is sort of the strongest
standard hint) or a "Reply-To:" header which usually is frowned upon.
Naturally, you can yourself set a "Reply-To:
linux-audio-user(a)linuxaudio.org" header when posting to the list in
order to express your desire _never_ to receive personal replies. Or a
"List-Reply-To:" header for expressing your desire to not receive copies
for replies to the list.
Since at the current point of time, the mailing list apparently is set
up _not_ to tamper with those headers, they are free for you to
customize in order to have the default behavior of replies to the list
match your preferences even without requiring every single one of your
correspondants to hand-edit headers just for placating you.
In general, it will be a lot easier to teach your preferences to your
mail client than every single person on the mailing list.
--
David Kastrup
2:38 a.m.
On Fri, 2018-07-20 at 00:25 +0200, David Kastrup wrote:
Correct!
No there is the option to reply to a mailing list only. If your MUA
doesn't support it, do it manually.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
That depends on the used MUA, it#s not when I reply using Claws mail and
apart from this, it makes filtering mails by mailing list impossible,
usage of mailing list features provided by the MUA, such as "show
archive" impossible.
Btw. if you reply to me, I don't receive a
duplicated mail from the
mailing list, since I dislike receiving two times the same email. IOW
there will be no mailing list header in your replies to me.
There will be no mailing list _footer_. The mailing list, of course, is
in the Cc field, and you have the option to "Reply to all" in order to
reply to both sender and mailing list, or just "Reply" in order to reply
only to the sender.
That is _exactly_ the same way you respond to mail sent via the list. It's
common practise, part of netiquette, to reply to mailing lists
only, as long as it's not an open mailing list or as long as not a
group of developers should take attention to a mail, to a developers
mailing list.
Linux-audio-user is not a developer list, and it is an open list
according to its list page https://lists.linuxaudio.org/listinfo/linux-audio-user
which means that
posters to it are not necessarily subscribed.
Incorrect! Since it's not an open mailing list, you need to be
subscribed.
While this
could happen by accident, you are doing it with intent
again and again. I don't care about your continuously derogatory tone
of voice, but its annoying when you continuously break mailing list
headers.
I don't "break mailing list headers". I use "Reply to All" in
order to
reply to all. The alternative would be "Reply", replying to just you.
Other options would be more esoteric.
The mail I replied to had the following headers regarding routing:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: linux-audio-user(a)lists.linuxaudio.org
That's it. No "Mail-Reply-To:", no "List-Reply-To:", no
"Reply-To:".
The mailing list itself was in the "Sender:" header, but it's not normal
to reply to that.
I receive emails from mailman mailing lists, if they are send to the
mailing list only!
Plese reply to the mailing list only.
Look, you set your mailing list options _exactly_ to "avoid duplicates"
in order _not_ to receive duplicate mails. Now you complain that you
don't receive mails sent via the mailing list. At some point of time, you need to decide yourself.
Yes, one mail only, from the mailing list only!
The way the mailing list is set up to operate, the options for replying
with standard mail clients are either _only_ to the author of a mail, or
to "all" which includes Cc: and To: fields.
If you want everybody answering you on the list to use his mail client
in non-standard manners specifically for replying to you, you have an
upstream battle before you. Alternatively, try convincing the list
owners to set up the mailing list headers differently in order to have
them match your idea of "netiquette". That would likely involve setting
at least a "List-Reply-To:" header (which is sort of the strongest
standard hint) or a "Reply-To:" header which usually is frowned upon.
When using Evolution, a reply to all could invoke a reply to the mailing
list only. I'm using both kinds of MUAs, those that invoke a reply to
the mailing list only by reply and those who do that by reply to all.
Both have got pitfalls when using it for different kind of mailing löist
settings and different mailing list approaches, however, regarding the
duplicated mail issue, that e.g. makes filtering by mailing list
impossible, even if I would receive both mails, just one could be
filtered.
Naturally, you can yourself set a "Reply-To:
linux-audio-user(a)linuxaudio.org" header when posting to the list in
order to express your desire _never_ to receive personal replies. Or a
"List-Reply-To:" header for expressing your desire to not receive copies
for replies to the list.
This comes with pitfalls, lists could have different settings. You are
simply not doing the right thing.
Since at the current point of time, the mailing list
apparently is set
up _not_ to tamper with those headers, they are free for you to
customize in order to have the default behavior of replies to the list
match your preferences even without requiring every single one of your
correspondants to hand-edit headers just for placating you.
In general, it will be a lot easier to teach your preferences to your
mail client than every single person on the mailing list.
You are doing it wrong!
2:56 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
If you wish people to reply to mails of yours in a particular manner,
set the Reply-To: header for mails to that mailing list.
Then set up your Reply-To: header appropriately when mailing to the
mailing list.
Which is _exactly_ what you want.
You just said that you use a mail client to sort mails according to the
list they belong to. So set your header preferences according to the
list you send to.
On Fri, 2018-07-20 at 00:25 +0200, David Kastrup
wrote:
Sigh. Do you even read what you are replying to?
According to the list page, this is an open list. The list page states:
Linux-audio-user is not a developer list, and it
is an open list
according to its list page
Correct!
https://lists.linuxaudio.org/listinfo/linux-audio-user which means that
posters to it are not necessarily subscribed.
Incorrect! Since it's not an open mailing list, you need to be
subscribed. Using Linux-audio-user
To post a message to all the list members, send email to
linux-audio-user(a)lists.linuxaudio.org.
I will not rule out that unsubscribed members are automoderated and
nobody actually ever moderates. But at least formally, this is an open
list.
I don't
"break mailing list headers". I use "Reply to All" in order
to reply to all. The alternative would be "Reply", replying to just
you. Other options would be more esoteric.
No there is the option to reply to a mailing list only. If your MUA
doesn't support it, do it manually. The mail I
replied to had the following headers regarding routing:
From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
To: linux-audio-user(a)lists.linuxaudio.org
That's it. No "Mail-Reply-To:", no "List-Reply-To:", no
"Reply-To:".
The mailing list itself was in the "Sender:" header, but it's not normal
to reply to that.
I receive emails from mailman mailing lists, if they are send to the
mailing list only!
Plese reply to the mailing list only.
Look, you set your mailing list options _exactly_ to "avoid duplicates"
in order _not_ to receive duplicate mails. Now you complain that you
don't receive mails sent via the mailing list. At some point of time, you need to decide
yourself.
Yes, one mail only, from the mailing list only! The way the
mailing list is set up to operate, the options for replying
with standard mail clients are either _only_ to the author of a mail, or
to "all" which includes Cc: and To: fields.
If you want everybody answering you on the list to use his mail client
in non-standard manners specifically for replying to you, you have an
upstream battle before you. Alternatively, try convincing the list
owners to set up the mailing list headers differently in order to have
them match your idea of "netiquette". That would likely involve setting
at least a "List-Reply-To:" header (which is sort of the strongest
standard hint) or a "Reply-To:" header which usually is frowned upon.
When using Evolution, a reply to all could invoke a reply to the mailing
list only. I'm using both kinds of MUAs, those that invoke a
reply to the mailing
list only by reply and those who do that by reply to all. Both have
got pitfalls when using it for different kind of mailing löist
settings and different mailing list approaches, however, regarding the
duplicated mail issue, that e.g. makes filtering by mailing list
impossible, even if I would receive both mails, just one could be
filtered.
What kind of mail client is unable to recognize a mail belongs to a
certain mailing list when the mailing list is in the Cc: field?
I am _not_ talking about multiple replies, one to list-only, one to
sender-only. Those are annoying as hell because when you don't notice,
you end up replying to the sender-only reply, ending up not sending
anything to the list.
What we are talking about here is a Reply-All where the mailing list, as
the original To: header entry, gets placed in Cc: .
Naturally, you
can yourself set a "Reply-To:
linux-audio-user(a)linuxaudio.org" header when posting to the list in
order to express your desire _never_ to receive personal replies. Or a
"List-Reply-To:" header for expressing your desire to not receive copies
for replies to the list.
This comes with pitfalls, lists could have different settings. You are simply not doing the right thing.
References?
--
David Kastrup
Since at the current point of time, the mailing
list apparently is set
up _not_ to tamper with those headers, they are free for you to
customize in order to have the default behavior of replies to the list
match your preferences even without requiring every single one of your
correspondants to hand-edit headers just for placating you.
In general, it will be a lot easier to teach your preferences to your
mail client than every single person on the mailing list.
You are doing it wrong!
3:21 a.m.
On Fri, 2018-07-20 at 00:56 +0200, David Kastrup wrote:
Then set up your Reply-To: header appropriately when
mailing to the
mailing list.
I'm not using this email address for only one mailing list.
Does the forwarded message look like a message to an open mailing list?
Begin forwarded message:
Date: Fri, 20 Jul 2018 01:02:18 +0200
From: linux-audio-user-owner(a)lists.linuxaudio.org
To: unknown.crewman(a)rocketship.com
Subject: This doesn't work
Your message has been rejected, probably because you are not
subscribed to the mailing list and the list's policy is to prohibit
non-members from posting to it. If you think that your messages are
being rejected in error, contact the mailing list owner at
linux-audio-user-owner(a)lists.linuxaudio.org.
The Claws way to invoke a mailing list reply could be better for some
mailing list, however, neither the "reply" nor the "reply to all"
approach does solves issues caused by subscribers like you.
What kind of mail client is unable to recognize a mail
belongs to a
certain mailing list when the mailing list is in the Cc: field?
What kind of filter by ID does work? What kind of a MUA's List-Help
feature does work, if the header is missing etc.?
References?
Are you serious? I'm the fist person who asked you to reply to a mailing
list only?
However, lets stop this discussion.
In way more than 10 years subscription to many mailing lists, you are
the first one who is not able or willing to listen to reason regarding
this issue.
3:22 a.m.
On Thu, Jul 19, 2018 at 6:56 PM, David Kastrup <dak(a)gnu.org> wrote:
What kind of mail client is unable to recognize a mail belongs to a
certain mailing list when the mailing list is in the Cc: field?
gmail? see enclosed image of the To: line it sets up when using the
default "Reply" to this mailing list:
×
3:27 a.m.
Paul Davis <paul(a)linuxaudiosystems.com> writes:
On Thu, Jul 19, 2018 at 6:56 PM, David Kastrup
<dak(a)gnu.org> wrote:
What kind of mail client is unable to recognize a mail belongs to a
certain mailing list when the mailing list is in the Cc: field?
gmail? see enclosed image of the To: line it sets up when using the default
"Reply"
to this mailing list:
Standard Reply-to-all behavior (namely Ralf, me, list) but this question
was not about the default reply-to behavior but rather whether a mail
client ordered to sort incoming mails according to mailing lists was
unable to recognize the mailing list when not written in the To: header
but instead in Cc: .
--
David Kastrup
3:37 a.m.
On Thu, Jul 19, 2018 at 7:27 PM, David Kastrup <dak(a)gnu.org> wrote:
Standard Reply-to-all behavior (namely Ralf, me, list) but this question
was not about the default reply-to behavior but rather whether a mail
client ordered to sort incoming mails according to mailing lists was
unable to recognize the mailing list when not written in the To: header
but instead in Cc: .
Ah right. Missed the context. sorry.
4:13 a.m.
On Thu, 19 Jul 2018 19:22:36 -0400, Paul Davis wrote:
On Thu, Jul 19, 2018 at 6:56 PM, David Kastrup
<dak(a)gnu.org> wrote:
Since a lot of people often don't know how to e.g. unsubscribe, some
MUAs provide a menu for mails from mailing lists, with intact mailing
list headers, see attachment.
What kind of mail client is unable to recognize a mail belongs to a
certain mailing list when the mailing list is in the Cc: field?
gmail? see enclosed image of the To: line it sets up when using the
default "Reply" to this mailing list: 
4:23 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Thu, 19 Jul 2018 19:22:36 -0400, Paul Davis wrote:
Well, if you value that, don't set the mailing list options to avoid the
duplicates.
Simple as that.
How do real people on real mailing lists, let's say a developer list, do
this?
Like, say, the following?
From: Linus Torvalds <torvalds(a)linux-foundation.org>
Subject: Re: [PATCH] random: fix rdrand mix-in
To: "Theodore Ts'o" <tytso(a)mit.edu>du>, Arnd Bergmann
<arnd(a)arndb.de>de>,
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>rg>,
Jann Horn <jannh(a)google.com>om>, tcharding <me(a)tobin.cc>cc>,
Rasmus Villemoes <linux(a)rasmusvillemoes.dk>dk>,
Eric Biggers <ebiggers(a)google.com>om>,
Linux Kernel Mailing List <linux-kernel(a)vger.kernel.org>
Date: Tue, 17 Jul 2018 17:01:06 -0700
On Tue, Jul 17, 2018 at 2:12 PM Theodore Y. Ts'o <tytso(a)mit.edu> wrote:
On Thu, Jul 19, 2018 at 6:56 PM, David Kastrup
<dak(a)gnu.org> wrote:
Since a lot of people often don't know how to e.g. unsubscribe, some
MUAs provide a menu for mails from mailing lists, with intact mailing
list headers, see attachment.
What kind of mail client is unable to recognize a mail belongs to a
certain mailing list when the mailing list is in the Cc: field?
gmail? see enclosed image of the To: line it sets up when using the
default "Reply" to this mailing list:
I wasn't sure how quickly the HW entropy would replenish itself; I
know that on first RDRAND platforms it would effectively never fail
(as in if six of the eight cores were calling RDRAND in a tight loop
_maybe_ you could exhaust the HW entropy).
I suspect you can't hit it in practice on Intel systems, but maybe you
can on others. And maybe future other architectures might be different
yet.
But rdrand has the potential of being pretty slow, and it's almost
certainly not worth continuing if it stopped giving us data.
Linus
(actually, I had to look a bit to get a mail that was not crossposted to
several lists in order to have a fair example).
Seems like all those guys stacking up in the To: header are incapable of
heeding basic mailing list netiquette, right?
--
David Kastrup
4:39 a.m.
On Fri, 20 Jul 2018 02:23:40 +0200, David Kastrup wrote:
How do real people on real mailing lists, let's say
a developer list,
do this?
A developer list is used in a different way. The developers are
subscribed, but not necessary follow everything, so if a group of
developers should take attention of something, there is the need to send
the mail to them directly. Actually I was the one in this discussion
who first mentioned two exceptions, the open mailing list and the
developer mailing list.
However, you are just trolling, since you even claim that it is an open
mailing list, while this list explicitly mentions, that it isn't, again:
"Your message has been rejected, probably because you are not
subscribed to the mailing list and the list's policy is to prohibit
non-members from posting to it."
It's also no a developers mailing list.
You are completely wrong!
Instead of continuing this off-topic, consider to provide the missing
information I requested by this:
"Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio
CODEC".
I'm not aware that a lot of people got this to work at all.
Is there any evidence for your claim? Perhaps a link to one of those lot
of people who get a setup like this right without rt priority for the
USB device? Such a link would be very helpful for the OP."
Where is the link to at least one of those many people using the
PCM2902C with 64 frames at 48K?
10:45 a.m.
On 07/19/2018 02:39 PM, someone back in the depths of time wrote:
On Fri, 20 Jul 2018 02:23:40 +0200, someone else back
in the depths of time wrote:
"Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio
CODEC".
I'm not aware that a lot of people got this to work at all.
Don't know about a link to anything, but lsusb on my laptop just know
returned:
Bus 003 Device 004: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
Where is the link to at least one of those many people
using the
PCM2902C with 64 frames at 48K?
It's currently running with buffer size 512 and 3 periods at 48K,
10.7msec latency. On a non-RT kernel.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
12:26 p.m.
On Thu, 19 Jul 2018 20:45:30 -1000, david wrote:
On 07/19/2018 02:39 PM, someone back in the depths of
time wrote:
512 and 3 periods at 48K is not such a setup as the OP wants and we
were not arguing about non-RT kernels, we were arguing about non-rt
priority, you could use a generic Ubuntu kernel with 'threadirqs' to
get rt priority for USB devices. The lowlatency kernel is a non-rt
kernel, too, just with minor configuration changes, for the official
lowlatency kernel e.g. 'threadirqs' needs not to be added to the boot
line options.
On Fri, 20 Jul 2018 02:23:40 +0200, someone else
back in the depths
of time wrote: "Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at
48kHz 2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200
wrote "Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C
Audio CODEC".
I'm not aware that a lot of people got this to work at all.
Don't know about a link to anything, but lsusb on my laptop just know
returned:
Bus 003 Device 004: ID 08bb:2902 Texas Instruments PCM2902 Audio Codec
Where is the link to at least one of those many
people using the
PCM2902C with 64 frames at 48K?
It's currently running with buffer size 512 and 3 periods at 48K,
10.7msec latency. On a non-RT kernel.
10:56 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Fri, 20 Jul 2018 02:23:40 +0200, David Kastrup
wrote:
Not on its list page. There is asks people to just post to the list.
How do real people on real mailing lists,
let's say a developer list,
do this?
However, you are just trolling, since you even claim that it is an open
mailing list, while this list explicitly mentions, that it isn't, again:
"Your message has been rejected, probably because you are not
subscribed to the mailing list and the list's policy is to prohibit
non-members from posting to it." It's also no a developers mailing list.
You are completely wrong!
Instead of continuing this off-topic, consider to provide the missing
information I requested by this:
"Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio
CODEC".
I'm not aware that a lot of people got this to work at all.
Here is some discussion about comparable latencies (at 96kHz):
https://forum.renoise.com/index.php/topic/46412-low-latency-and-xrun-optimi…
--
David Kastrup
3:29 a.m.
On Fri, 20 Jul 2018 01:21:13 +0200, Ralf Mardorf wrote:
On Fri, 2018-07-20 at 00:56 +0200, David Kastrup
wrote:
And not necessarily a folder for each mailing list.
IOW this could become unnecessarily complicated doing this, just for
one person named David Kastrup.
However, I know what to do instead, so we could stop arguing.
Then set up your Reply-To: header appropriately
when mailing to the
mailing list.
I'm not using this email address for only one mailing list.
3:36 a.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Fri, 20 Jul 2018 01:21:13 +0200, Ralf Mardorf
wrote:
Cf <http://david.woodhou.se/reply-to-list.html>.
--
David Kastrup
On Fri, 2018-07-20 at 00:56 +0200, David Kastrup
wrote:
And not necessarily a folder for each mailing list.
IOW this could become unnecessarily complicated doing this, just for
one person named David Kastrup.
However, I know what to do instead, so we could stop arguing. Then set up your Reply-To: header appropriately
when mailing to the
mailing list.
I'm not using this email address for only one mailing list.
2:57 a.m.
PS:
Without those headers, a lot of MUA mailing list features don't work,
also filtering doesn't work and for some MUAs, such as Claws even a
"reply to all" workaround doesn't work, since the mailing list reply is
invoked by a reply:
List-Id: A list for linux audio users <linux-audio-user.lists.linuxaudio.org>
List-Unsubscribe: <https://lists.linuxaudio.org/options/linux-audio-user>,
<mailto:linux-audio-user-request@lists.linuxaudio.org?subject=unsubscribe>
List-Archive: <https://lists.linuxaudio.org/archives/linux-audio-user>
List-Post: <mailto:linux-audio-user@lists.linuxaudio.org>
List-Help: <mailto:linux-audio-user-request@lists.linuxaudio.org?subject=help>
List-Subscribe: <https://lists.linuxaudio.org/listinfo/linux-audio-user>,
<mailto:linux-audio-user-request@lists.linuxaudio.org?subject=subscribe>
On many mailing lists most, if not all subscribers would ask you to
stop replying directly. It's common to reply to mailing löists only,
even on a lot of open mailing lists.
1:25 p.m.
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> writes:
On Thu, 2018-07-19 at 22:44 +0200, David Kastrup
wrote:
I missed the PCM2902C bit. That chip is described in
http://www.ti.com/product/PCM2902C/technicaldocuments and is USB full
speed (namely USB1.1 speeds). It is described as
– USB Adaptive Mode for Playback
– USB Asynchronous Mode for Record
It sports something like 16bit/48kHz with 89dB SNR. That is both with
regard to attainable sound quality as well as USB bus behavior
completely lacklustre. I'd expect this kind of interface to be mostly
soldered to mainboards directly where one would not expect to be able to
change buses at all.
Or be part of some USB sound interface in the $10 price class.
So the idea to take this into low-latency realms with a view on realtime
effects seems a bit optimistic indeed. Actually out of place. Maybe
this isn't actually the interface we are dealing with but just something
hardwired to the motherboard and thus cropping up in the lsusb output?
--
David Kastrup
You are babbling. [snip]
A lot of people get setups like that to work without rtirq .
Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC".
I'm not aware that a lot of people got this to work at all.
1:56 p.m.
On Fri, 20 Jul 2018 11:24:57 +0200, David Kastrup wrote:
So the idea to take this into low-latency realms with a
view on
realtime effects seems a bit optimistic indeed.
;)
On Thu, 19 Jul 2018 22:52:45 -1000, _another_ david wrote:
I first tried it with 4.13.x and decided that items
like random
kernel panios, system freezes and crashes weren't very good ways to
defend against Spectre/Meltdown/DOS. ;)
Actually freezes and crashes do defend against attacks :D. But you are
right, for Claws and Firefox I'm experiencing way to often serious
issues and for virtualbox at least way to often an annoyance for an
unexplained reason.
I at least should test using it with PTI disabled.
The current default on my machine is:
[rocketmouse@archlinux ~]$ ls -hAl /sys/devices/system/cpu/vulnerabilities/; cat
/sys/devices/system/cpu/vulnerabilities/*
total 0
-r--r--r-- 1 root root 4.0K Jul 20 10:12 meltdown
-r--r--r-- 1 root root 4.0K Jul 20 10:12 spec_store_bypass
-r--r--r-- 1 root root 4.0K Jul 20 10:12 spectre_v1
-r--r--r-- 1 root root 4.0K Jul 20 10:12 spectre_v2
Mitigation: PTI
Vulnerable
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB, IBRS_FW
'nopti' only would disable PTI, but keep the spectre mitigations. While
PTI is part of the kernel, the spectre mitigations are likely part
of the µcode. However, if I would run my CPU without the µcode, I
perhaps would get rid of the spectre mitigation, but IIRC I
unfortunately would get rid of TSC, too.
21 Jul
21 Jul
12:02 p.m.
On 07/19/2018 11:56 PM, Ralf Mardorf wrote:
On Fri, 20 Jul 2018 11:24:57 +0200, David Kastrup
wrote:
The Spectre mitigations don't seem to affect the performance on my
desktop, which is running with PTI off but with the mitigation microcode
patches. I also have Spectre mitigations on my Intel laptop with no
performance impact.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
So the idea to take this into low-latency realms
with a view on
realtime effects seems a bit optimistic indeed.
;)
On Thu, 19 Jul 2018 22:52:45 -1000, _another_ david wrote:
I first tried it with 4.13.x and decided that
items like random
kernel panios, system freezes and crashes weren't very good ways to
defend against Spectre/Meltdown/DOS. ;)
Actually freezes and crashes do defend against attacks :D. But you are
right, for Claws and Firefox I'm experiencing way to often serious
issues and for virtualbox at least way to often an annoyance for an
unexplained reason.
I at least should test using it with PTI disabled.
The current default on my machine is:
[rocketmouse@archlinux ~]$ ls -hAl /sys/devices/system/cpu/vulnerabilities/; cat
/sys/devices/system/cpu/vulnerabilities/*
total 0
-r--r--r-- 1 root root 4.0K Jul 20 10:12 meltdown
-r--r--r-- 1 root root 4.0K Jul 20 10:12 spec_store_bypass
-r--r--r-- 1 root root 4.0K Jul 20 10:12 spectre_v1
-r--r--r-- 1 root root 4.0K Jul 20 10:12 spectre_v2
Mitigation: PTI
Vulnerable
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB, IBRS_FW
'nopti' only would disable PTI, but keep the spectre mitigations. While
PTI is part of the kernel, the spectre mitigations are likely part
of the µcode. However, if I would run my CPU without the µcode, I
perhaps would get rid of the spectre mitigation, but IIRC I
unfortunately would get rid of TSC, too.
12:48 p.m.
On Fri, 20 Jul 2018 22:02:05 -1000, david wrote:
On 07/19/2018 11:56 PM, Ralf Mardorf wrote:
At the moment I test 'nopti' again for a non-audio session.
[rocketmouse@archlinux ~]$ ls -hAl /sys/devices/system/cpu/vulnerabilities/; cat
/sys/devices/system/cpu/vulnerabilities/*
total 0
-r--r--r-- 1 root root 4.0K Jul 21 02:34 meltdown
-r--r--r-- 1 root root 4.0K Jul 21 02:34 spec_store_bypass
-r--r--r-- 1 root root 4.0K Jul 21 02:34 spectre_v1
-r--r--r-- 1 root root 4.0K Jul 21 02:34 spectre_v2
Vulnerable
Vulnerable
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB, IBRS_FW
It doesn't solve some issues on my machine and at least for non-audio a
possible better performance of my computer isn't of value to disable
PTI.
I'll build 4.16.18-rt10 now, maybe it takes less time than I needed to
build 4.16.18-rt9 with PTI enabled.
Mitigation: PTI
Vulnerable
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB, IBRS_FW
'nopti' only would disable PTI, but keep the spectre mitigations.
While PTI is part of the kernel, the spectre mitigations are likely
part of the µcode. However, if I would run my CPU without the µcode,
I perhaps would get rid of the spectre mitigation, but IIRC I
unfortunately would get rid of TSC, too.
The Spectre mitigations don't seem to affect the performance on my
desktop, which is running with PTI off but with the mitigation
microcode patches. I also have Spectre mitigations on my Intel laptop
with no performance impact.
10:28 a.m.
On 07/19/2018 11:24 PM, David Kastrup wrote:
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
Mine's in a Behringer UCA202 that was $19 when I got it many years ago.
On Thu, 2018-07-19 at 22:44 +0200, David Kastrup
wrote:
I missed the PCM2902C bit. That chip is described in
http://www.ti.com/product/PCM2902C/technicaldocuments and is USB full
speed (namely USB1.1 speeds). It is described as
– USB Adaptive Mode for Playback
– USB Asynchronous Mode for Record
It sports something like 16bit/48kHz with 89dB SNR. That is both with
regard to attainable sound quality as well as USB bus behavior
completely lacklustre. I'd expect this kind of interface to be mostly
soldered to mainboards directly where one would not expect to be able to
change buses at all.
Or be part of some USB sound interface in the $10 price class. You are babbling. [snip]
A lot of people get setups like that to work without rtirq .
Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC".
I'm not aware that a lot of people got this to work at all. So the idea to take this into low-latency realms with
a view on realtime
effects seems a bit optimistic indeed. Actually out of place. Maybe
this isn't actually the interface we are dealing with but just something
hardwired to the motherboard and thus cropping up in the lsusb output?
Don't know about the original poster, but my built-in audio shows up on
the PCI bus.
--
David W. Jones
gnome(a)hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com
29 Jul
29 Jul
8:54 p.m.
On 20.07.2018 11:24, David Kastrup wrote:
Ralf Mardorf <ralf.mardorf(a)alice-dsl.net>
writes:
It's actually a behringer mixer (now legacy model afaik)... all right I
will try a different card.
I bought the docking station which has 6 more USB ports (4 USB 3.0 and 2
USB 2.0)
however:
lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 17ef:304f Lenovo
Bus 004 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 004 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 8087:07dc Intel Corp.
Bus 003 Device 011: ID 046a:b090 Cherry GmbH
Bus 003 Device 030: ID 1686:0045 ZOOM Corporation H4 Digital Recorder
Bus 003 Device 028: ID 0fce:01e1 Sony Ericsson Mobile Communications AB
Bus 003 Device 010: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 009: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 006: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 008: ID 17ef:304e Lenovo
Bus 003 Device 007: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC
Bus 003 Device 004: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 003 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 003 Device 005: ID 0bda:5719 Realtek Semiconductor Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
no matter where I plug in the devices I can't seem to find how to use
the Bus 4 USB 3.0. Could it be that it is only on the motherboard but
not actually available to the user?
m.
On Thu, 2018-07-19 at 22:44 +0200, David Kastrup
wrote:
I missed the PCM2902C bit. That chip is described in
http://www.ti.com/product/PCM2902C/technicaldocuments and is USB full
speed (namely USB1.1 speeds). It is described as
– USB Adaptive Mode for Playback
– USB Asynchronous Mode for Record
It sports something like 16bit/48kHz with 89dB SNR. That is both with
regard to attainable sound quality as well as USB bus behavior
completely lacklustre. I'd expect this kind of interface to be mostly
soldered to mainboards directly where one would not expect to be able to
change buses at all.
Or be part of some USB sound interface in the $10 price class.
So the idea to take this into low-latency realms with a view on realtime
effects seems a bit optimistic indeed. Actually out of place. Maybe
this isn't actually the interface we are dealing with but just something
hardwired to the motherboard and thus cropping up in the lsusb output? You are babbling. [snip]
A lot of people get setups like that to work without rtirq .
Hi,
the OP on Wed, 2018-07-18 at 21:28 +0200 wrote "64 buffer size at 48kHz
2 Periods/Buffer" and the OP on Thu, 2018-07-19 at 14:32 +0200 wrote
"Bus 003 Device 002: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC".
I'm not aware that a lot of people got this to work at all.
9:02 p.m.
Max <abonnements(a)revolwear.com> writes:
It's actually a behringer mixer (now legacy model
afaik)... all right
I will try a different card.
I bought the docking station which has 6 more USB ports (4 USB 3.0 and
2 USB 2.0)
however:
lsusb
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 004: ID 17ef:304f Lenovo
Bus 004 Device 003: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 004 Device 002: ID 2109:0812 VIA Labs, Inc. VL812 Hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 8087:07dc Intel Corp.
Bus 003 Device 011: ID 046a:b090 Cherry GmbH
Bus 003 Device 030: ID 1686:0045 ZOOM Corporation H4 Digital Recorder
Bus 003 Device 028: ID 0fce:01e1 Sony Ericsson Mobile Communications AB
Bus 003 Device 010: ID 0424:2640 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 009: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 003 Device 006: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 003 Device 008: ID 17ef:304e Lenovo
Bus 003 Device 007: ID 08bb:29c2 Texas Instruments PCM2902C Audio CODEC
Bus 003 Device 004: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 003 Device 002: ID 2109:2812 VIA Labs, Inc. VL812 Hub
Bus 003 Device 005: ID 0bda:5719 Realtek Semiconductor Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
no matter where I plug in the devices I can't seem to find how to use
the Bus 4 USB 3.0. Could it be that it is only on the motherboard but
not actually available to the user?
Well, what's the bus topology?
lsusb -t
should be good for that.
--
David Kastrup
30 Jul
30 Jul
5:52 p.m.
On 29.07.2018 19:01, David Kastrup wrote:
Max <abonnements(a)revolwear.com> writes:
Well, what's the bus topology?
lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class,
Driver=r8152, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
|__ Port 4: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 31, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 3: Dev 33, If 1, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 3: Dev 33, If 0, Class=Human Interface Device,
Driver=usbhid, 1.5M
|__ Port 1: Dev 32, If 0, Class=Hub, Driver=hub/3p, 480M
|__ Port 1: Dev 34, If 0, Class=Mass Storage,
Driver=usb-storage, 480M
|__ Port 1: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 1: Dev 7, If 3, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 1: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 8, If 2, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 8, If 0, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 4: Dev 8, If 3, Class=Human Interface Device,
Driver=usbhid, 12M
|__ Port 4: Dev 8, If 1, Class=Audio, Driver=snd-usb-audio, 12M
|__ Port 6: Dev 37, If 0, Class=Vendor Specific Class,
Driver=tickle, 12M
|__ Port 7: Dev 3, If 0, Class=Wireless, Driver=btusb, 12M
|__ Port 7: Dev 3, If 1, Class=Wireless, Driver=btusb, 12M
|__ Port 12: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M
|__ Port 12: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
6:06 p.m.
Max <abonnements(a)revolwear.com> writes:
On 29.07.2018 19:01, David Kastrup wrote:
[...] and lots of slower devices.
Uh, that looks like you have an Ethernet interface on USB3.0 currently.
Probably a Gigabit one. Definitely a good use case but it's not clear
whether that USB3.0 speed is available on anything else externally.
--
David Kastrup
Max <abonnements(a)revolwear.com> writes:
Well, what's the bus topology?
lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class,
Driver=r8152, 5000M
20 Jul
20 Jul
2:15 a.m.
On Thu, 19 Jul 2018 23:24:56 +0200, Ralf Mardorf wrote:
I don't care about your continuously derogatory
tone of voice,
My apologies,
I've mistaken your identity with another person. You aren't the one
with the "continuously derogatory tone of voice".
but its annoying when you continuously break mailing
list headers.
However, you are doing this, please reply to the mailing list only.
Regards,
Ralf
19 Jul
19 Jul
7:05 p.m.
On Wed, July 18, 2018 4:20 pm, Will Godfrey wrote:
Something nobody seems to have mentioned is the
command lsusb.
Of course, thanks for bringing that up. The original poster provided
output that shows his device is using a PCM2902C from Texas Instruments.
USB2 speeds on modern cards can easily
manage 64/2 at 48k. Indeed, mine can
(just) manage 16/2 at 48k.
The PCM2902C is a "full speed" device, not "high speed," so the
transmission window is 1ms, not 125us. As the document you linked pointed
out you have to assume that the start of transmission can shift within the
window, so you have to allow for two transmission windows worth of time.
Given that the device in use is not high speed I think my original
warning applies, 1.3ms latency is feasible for some devices but not all,
doubling the buffer size would provide some breathing room, increasing the
number of buffers from 2 to 3 also would.
And of course as you pointed out moving the audio device to a USB bus
without other devices would help, and as Ralf pointed out getting
threadirqs applied to the kernel command line so that RT scheduling will
work would help as well.
--
Chris Caudle
20 Jul
20 Jul
10:09 a.m.
Hi Max,
Please ignore all the bickering. Some of us are trying to help you as, and where
we can.
--
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
2100
days inactive
2112
days old
linux-audio-user@lists.linuxaudio.org
45 comments
9 participants
participants (9)
-
Chris Caudle -
david -
David Kastrup -
Jacek Konieczny -
Jeanette C. -
Max -
Paul Davis -
Ralf Mardorf -
Will Godfrey