Re: PC Engines APU alternative for OpenBSD - 2022h2
On Fri, Jan 13, 2023, at 8:34 PM, patrick keshishian wrote: >> Search with keywords like "mini pc router", "pfsense router" etc, >> you will find a load of boxes along these lines (to pick the first >> one I found, there are loads of choices of all very similar hardware) >> - https://www.aliexpress.com/item/1005004420642522.html? >> They do have video out as well but you can just configure OpenBSD >> to use serial console. >> >> Now that the 1G em(4) chips are out of stock everywhere, the common >> NICs these days are igc(4) 2.5G ethernet (very common, to the extent that >> "I225" will probably also do as a search term ..). > > I picked up one of these and just got it unpacked. > I am failing to figure out how to boot from an external > USB CDR to get OpenBSD installed on there. > > I'm connecting through the serial/COM port, but it > automatically goes through the Pfsense/FreeBSD > boot process and starts the "configuration" questions. > > Some reddit discussions seem to suggest pressing > either F2 or Delete key at the first beep. But either > I'm not quick enough, or I'm misunderstand something. > > Can someone offer any hints? > > --patrick While they might exist, none of the mini PC/firewalls I've received from China support BIOS redirection over serial. If yours is the same, you'll want to hook up a monitor and keyboard and then either redirect bsd.rd over serial, or complete the installation and then set up a serial console going forward. Another issue I've run into are BIOSes that disable all the CPU C-states by default. You will likely want to enable those for decent power management/cooling/power consumption. Overall, I've enjoyed my AliExpress cheapies, but the firmware leaves a lot to be desired. They seem to be compiled with every option under the sun present, even if they don't apply to the hardware in question - other than the aforementioned serial BIOS redirection. Brian Conway
Re: Relinking to create unique kernel... failed!
Thanks for the tips. I opened up the case and checked the cables, nothing obviously damaged or poorly connected, but certainly dusty in there. I reseated the cables and rebooted into single-user mode. fsck -f on each partition didn't reveal any issues, but after rebooting again the ahci0 errors went away. However, the reorder_kernel error remained. BUT your pointers got me to think "maybe the files in /usr/share/relink/kernel/GENERIC.MP/ are corrupt and overwriting them might fix things." I didn't know the best way to go about doing that, so I forced an OS "update" via bsd.rd and what do you know, things seem to be running smoothly again, relinking/reodering and everything. I may have a failing harddrive, but for now this immediate problem seems to be resolved. Thanks! -Nick On Fri, Jan 13, 2023 at 2:00 PM Crystal Kolipe wrote: > > On Fri, Jan 13, 2023 at 11:45:31AM -0800, Philip Guenther wrote: > > On Fri, Jan 13, 2023 at 10:59 AM Nick Templeton > > wrote: > > > > > Ever since upgrading my machine to 7.2 I've been unable to relink my > > > kernel, anybody have any idea why? > > > > ... > > > > > Running "/usr/libexec//reorder_kernel" manually resulted in a kernel > > > panic: > > > > > > mode = 0100600, inum = 7, fs = /tmp > > > panic: ffs_valloc: dup alloc > > > Stopped at db_enter+0x10: popq %rbp > > > > > > > You have at least one filesystem with latent corruption. You should reboot > > in single-user mode and run fsck with the -f option on each partition. > > But it would be wise to check the hardware first, because he also mentions: > > > Rebooting the machine results in this at the login prompt: > > > > login: ahci0: attempting to idle device > > ahci0: couldn't recover NCQ error, failing all outstanding commands. > > ahci0: attempting to idle device > > ahci0: couldn't recover NCQ error, failing all outstanding commands. > > This could be caused by a faulty sata cable, dirty connector, or something > more serious. > > Probably not a great idea to get half way through an fsck and have the drive > start failing commands.
Re: sndio and bit perfect playback
On Jan 13 15:58:20, euryd...@riseup.net wrote: > On 23/01/13 12:42, Jan Stary wrote: > > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > > I was able to distinguish between samples created by > > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > > Carbon > > > with HiFiMan Sundara headphones plugged in. To describe the circumstances > > > + > > > outcome briefly: 9 out of 10 correct in 10 trials > > > > http://stare.cz/.tmp/resample/ > > Which is which? > > That's not how AB/X tests work, but it also doesn't matter because they're all > the same file. Aaaah, now you have spoiled that as well :-)
Question about pf.conf queues
Hello, I have a question regarding queuing and priorities in pf.conf on OpenBSD 7.2. I have a basic gateway configuration - a PC with two NIC's (em0, em1). One interface is connected to the LAN and one interface is connected to the Internet with a public IP and with a bandwidth of approximately 60 Mbps down and 10 Mbps up. I perform NAT on the gateway. In terms of queuing, I'd like to make use of the following: ** Queue using HFSC for all outbound traffic ** Flow manager for the queue for fair queue utilization ** For TCP traffic I would like to use two priorities - one for TCP data packets and one for TCP ACKs (as mentioned in Peter Hansteen's "Book of pf 3rd edition" in chapter 7) Current configuration pf.conf: ext_if = "em0" int_if = "em1" set skip on lo0 queue rootq on $ext_if bandwidth 55M max 55M queue dataq parent rootq bandwidth 55M max 55M flows 1024 \ qlimit 1024 default match out on $ext_if inet from ($int_if:network) to any nat-to ($ext_if:0) block all match in on $int_if inet tag LAN match out on $ext_if inet queue dataq set prio (5, 6) tag INTERNET pass in quick on $int_if tagged LAN pass out quick on $ext_if tagged INTERNET My question are: 1. For better utilization of TCP traffic I have two priorities assigned to the queue. Do I require more than one sub queue for this to work ? I don't intend to subdivide my traffic up (i.e. a SSH queue, and HTTP/S queue, etc.), I just want all my TCP traffic to benefit from better utilization with the two priorities. 2. If this configuration is currently correct, are they any other changes I should make for better queuing (ie: better bandwidth utilization) ? 3. Given the importance of time keeping, would it be a good idea to have another queue for NTP traffic and use the highest priority of 7 for it ? Thanks, - J
Re: sndio and bit perfect playback
On 23/01/13 12:42, Jan Stary wrote: > On Jan 09 13:10:09, euryd...@riseup.net wrote: > > I was able to distinguish between samples created by > > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 > > Carbon > > with HiFiMan Sundara headphones plugged in. To describe the circumstances + > > outcome briefly: 9 out of 10 correct in 10 trials > > http://stare.cz/.tmp/resample/ > Which is which? That's not how AB/X tests work, but it also doesn't matter because they're all the same file. $ for num in $(seq -w 1 10); do ftp http://stare.cz/.tmp/resample/$num.wav > /dev/null 2>&1; done $ for num in $(seq -w 1 10); do sha256 ./$num.wav; done SHA256 (./01.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./02.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./03.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./04.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./05.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./06.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./07.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./08.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./09.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 SHA256 (./10.wav) = 772559e7f4df296757a449832d60da46efe7bed84d3af816d5a0d287f7dd9099 https://en.wikipedia.org/wiki/ABX_test
Re: Issue with acpi0 on Intel NUC11TNHi3
Hello Stuart, I have tried a snapshot but will give that a go again Won't be able to try the random disabling of acpi devices until I'm back hands on with them next week. Thanks On Fri, 13 Jan 2023, 15:18 Bradley Latus, wrote: > Some additional information: > > When running iperf3 between two of these machines (connected back/back) > the throughput is very low. > > PF is running with just the 'default' ruleset on both machines. > # pfctl -s rules > block return all > pass all flags S/SA > block return in on ! lo0 proto tcp from any to any port 6000:6010 > block return out log proto tcp all user = 55 > block return out log proto udp all user = 55 > > Considering these IGC interfaces are 2.5Gbit/s, I cannot help feeling it > is being hampered by this constant ACPI spam. > > So raw IP > # iperf3 -c 192.168.99.2 -P5 > [ ID] Interval Transfer Bitrate > [SUM] 0.00-10.01 sec 171 MBytes 143 Mbits/sec > sender > [SUM] 0.00-10.02 sec 170 MBytes 143 Mbits/sec > receiver > > Adding wireguard on top: > # iperf3 -c 172.16.1.1 -P5 > [SUM] 0.00-10.01 sec 55.6 MBytes 46.6 Mbits/sec > sender > [SUM] 0.00-10.03 sec 55.5 MBytes 46.4 Mbits/sec > receiver > > > Thanks > > On Fri, 13 Jan 2023 at 10:02, Bradley Latus wrote: > >> Hello all, >> >> I have an issue with my new intel NUC that I am trying to use as a PF >> firewall box. >> I have already tried upgrading to the latest BIOS but that does not >> appear to have worked. >> >> Basically when you look at systat all I see 100% usage of 1 core >> servicing ACPI0, on a completely otherwise idle system. >> >> Is there a way to isolate what is causing this issue? >> I understand that I can rebuild with acpi_debug turned on but when I >> tried the system was basically unresponsive as so many messages went by. >> >> Systat outputs: >> 2 users Load 1.66 1.24 0.57 carpenter 09:54:21 >> >> PID USER NAME CPU10\ 20\ >> 30\ 40\ 50\ 60\ 70\ 80\ 90\ 100\ >>46868 root acpi0 89.26 >> # >> 46.19 >> ### >>65226 carpentersystat 1.27 >>38804 root sensors 1.12 >> >> 2 users Load 1.34 1.21 0.59 carpenter 09:55:04 >> >> memory totals (in KB)PAGING SWAPPING >> Interrupts >> realvirtualfree in out in out >>361 total >> Active35480 35480 6367572 ops >>200 clock >> All 1400840 1400840 10568564 pages >>16 ipi >> >> 143 acpi0 >> Proc:r d s wCsw Trp Sys Int Sof Flt >> forksinteldrm >> 83 301 111 145514 >> fkppw nvme0 >> >> fksvm xhci1 >>4.9%Int 1.0%Spn 46.6%Sys 0.0%Usr 47.5%Idle pwait >>igc0:0 >> ||||||||||| >> relckigc0 >> ||@=== rlkok >>2igc1:0 >> >> noram igc1:1 >> Namei Sys-cacheProc-cacheNo-cache ndcpy >> igc1 >> Calls hits%hits %miss % >>fltcp >>10 10 100 >> zfod >> >> cow >> Disks sd0 >>64736 fmin >> seeks >> 86314 ftarg >> xfers >> itarg >> speed >> 29 wired >> sec >> pdfre >> >> pdscn >> >> pzidl 3 IPKTS >> >>10 kmape 1 OPKTS >> >> dmesg output: >> >> >> carpenter$ dmesg >> OpenBSD 7.2 (GENERIC.MP) #758: Tue Sep 27 11:57:54 MDT 2022 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> real mem = 8212676608 (7832MB) >> avail mem = 7946371072 (7578MB) >> random: good seed from bootblocks >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 3.3 @ 0x414c8000 (124 entries) >> bios0: vendor Intel Corp. version "TNTGL357.0070.2022.1028.1209" date >> 10/28/2022 >> bios0: Intel(R) Client Systems NUC11TNHi3 >> acpi0 at bios0: ACPI 6.2 >> acpi0: sleep states S0 S3 S4 S5 >> acpi0: tables DSDT FACP SSDT FIDT SSDT SSDT SSDT HPET APIC SSDT SSDT NHLT >> UEFI LPIT WDAT SSDT SSDT DBGP DBG2 DMAR FPDT SSDT MCFG SSDT BGRT TPM2 PTDT >> WSMT >> acpi0: wakeup devices PEGP(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4) >> SIO1(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) >> PXSX(S4) RP05(S4) PXSX(S4) [...] >> acpitimer0 at acpi0: 3579545 Hz, 24 bits >> acpihpet0 at acpi0: 1920 Hz >> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat >> cpu0 at mainbus0: apid 0 (boot processor)
Re: BiDi sfp in ix
On Wed, Jan 11, 2023 at 11:53 AM Hrvoje Popovski wrote: > Hi all, > > claudio@ suggested to try same setup with FreeBSD. So I've tried FreeBSD > and Linux and results are same, 1G BiDi from FS.COM coded for Cisco > won't work with Intel 82599 10G card. > If I boot FreeBSD and Linux with that sfp in 82599 or X710 card that > interface will be disabled at boot and won't show up in OS. > On OpenBSD i could see it but mac address is 00:00:00:00:00:00 > > I've tried all combinations with unsupported_sfp statements for FreeBSD > and Linux but I couldn't see that interface in OS. > If I put that sfp in card after boot status is no carrier whatever I do, > at least on FreeBSD. I'm still playing with Linux.. > > > it seems that I've missed out all football here :) Definitely seems like the "Intel NIC unsupported SFP" behavior, nothing specific to BiDi. (But thanks to everyone in this thread for educating me about BiDi! I doubt I'll be using it any time soon, but it's neat how it works, and I definitely see the appeal if you have a limited number of fibres.) Note that in Linux, it actually disables the card until you unload and reload the driver, for example: Dec 8 17:01:19 lambda kernel: [ 1428.680975] ixgbe :24:00.0 enp36s0f0: NIC Link is Down Dec 8 17:01:19 lambda systemd-networkd[83876]: enp36s0f0: Lost carrier Dec 8 17:01:24 lambda kernel: [ 1433.830686] ixgbe :24:00.0: failed to initialize because an unsupported SFP+ module type was detected. Dec 8 17:01:24 lambda kernel: [ 1433.832843] ixgbe :24:00.0: Reload the driver after installing a supported module. Dec 8 17:01:24 lambda kernel: [ 1433.852297] ixgbe :24:00.0: removed PHC on enp36s0f0 Dec 8 17:01:24 lambda systemd-networkd[83876]: enp36s0f0: Link DOWN That was with an Intel X520-DA2 (82599). I had to 'rmmod ixgbe' and then 'modprobe ixgbe' (optionally with 'allow_unsupported_sfp=1') to get the card active again, even with an Intel SFP+ module. Apparently there is a bit you can toggle in the EEPROM to make that setting permanent in all OSes: https://forums.servethehome.com/index.php?threads/patching-intel-x520-eeprom-to-unlock-all-sfp-transceivers.24634/page-3#post-324427 Note that this only applies to the 500 series cards (ix), the 700 series (ixl) have a different EEPROM that doesn't easily allow unsupported modules, although in my experience they do allow more modules, e.g. Finisar, and AFAIK don't require reloading the driver after swapping in a "supported" SFP. I'm not exactly sure how the vendor-lock works, but I think it looks at the "Vendor OUI" bits in the SFP's EEPROM. My FS.com generic 10GBASE-SR modules have 00:00:00 there, while an "Intel" one from FS has 00:1b:21, but still the FS vendor name and PN. I don't know if OpenBSD's 'ifconfig transceiver' reports all of that, but Linux 'ethtool -m ' does. -Andrew
Re: Relinking to create unique kernel... failed!
On Fri, Jan 13, 2023 at 11:45:31AM -0800, Philip Guenther wrote: > On Fri, Jan 13, 2023 at 10:59 AM Nick Templeton > wrote: > > > Ever since upgrading my machine to 7.2 I've been unable to relink my > > kernel, anybody have any idea why? > > ... > > > Running "/usr/libexec//reorder_kernel" manually resulted in a kernel panic: > > > > mode = 0100600, inum = 7, fs = /tmp > > panic: ffs_valloc: dup alloc > > Stopped at db_enter+0x10: popq %rbp > > > > You have at least one filesystem with latent corruption. You should reboot > in single-user mode and run fsck with the -f option on each partition. But it would be wise to check the hardware first, because he also mentions: > Rebooting the machine results in this at the login prompt: > > login: ahci0: attempting to idle device > ahci0: couldn't recover NCQ error, failing all outstanding commands. > ahci0: attempting to idle device > ahci0: couldn't recover NCQ error, failing all outstanding commands. This could be caused by a faulty sata cable, dirty connector, or something more serious. Probably not a great idea to get half way through an fsck and have the drive start failing commands.
Re: Relinking to create unique kernel... failed!
On Fri, Jan 13, 2023 at 10:59 AM Nick Templeton wrote: > Ever since upgrading my machine to 7.2 I've been unable to relink my > kernel, anybody have any idea why? ... > Running "/usr/libexec//reorder_kernel" manually resulted in a kernel panic: > > mode = 0100600, inum = 7, fs = /tmp > panic: ffs_valloc: dup alloc > Stopped at db_enter+0x10: popq %rbp > You have at least one filesystem with latent corruption. You should reboot in single-user mode and run fsck with the -f option on each partition. Philip Guenther
Relinking to create unique kernel... failed!
Ever since upgrading my machine to 7.2 I've been unable to relink my
kernel, anybody have any idea why? I was reminded of this when I
attempted to apply the latest errata today:
$ doas syspatch
Get/Verify syspatch72-009_xserver... 100% |*| 4384 KB00:01
Installing patch 009_xserver
Get/Verify syspatch72-010_vmd.tgz 100% || 2338 00:00
Installing patch 010_vmd
Get/Verify syspatch72-011_gpuinv.tgz 100% |*| 197 KB00:00
Installing patch 011_gpuinv
Get/Verify syspatch72-012_acme.tgz 100% |***| 40197 00:00
Installing patch 012_acme
Get/Verify syspatch72-013_tcp.tgz 100% || 508 KB00:00
Installing patch 013_tcp
Relinking to create unique kernel... failed!
!!! "/usr/libexec/reorder_kernel" must be run manually to install the new kernel
Running "/usr/libexec//reorder_kernel" manually resulted in a kernel panic:
mode = 0100600, inum = 7, fs = /tmp
panic: ffs_valloc: dup alloc
Stopped at db_enter+0x10: popq %rbp
TID PID UID PRFLAGS PFLAGS CPU COMMAND
* 47548 27451 0 0x13 0 4K sh
db_enter() at db_enter+0x10
panic (81f1612f) at panic+0xbf
ffs_inode_alloc(fd820bedf878,8180, fd81fe987008,
800022e4f528) at ffs_inode_alloc+0x42e
ufs_makeinode (8180, fd8200b73130,
800022e4f820,800022e4f850) at ufs_makeinode+0x79
ufs_create(800022e4f5d8) at ufs_create+0x3c
VOP CREATE (fd8200b73130,800022e4f820, 800022e4f850,
800022e4f630) at VOP_CREATE+0x3f
vn_open(800022e4f7f0, a03,180) at vn_open+0x162
doopenat (800022ba8a88, ff9c, 5d2b50be3b0, a02, 180,
800022e4f9d0) at doo penat+0x1cd
syscall(800022e4fa40) at syscall+0x35f
Xsyscall at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7c9820, count: 5
https://www.openbsd.org/ddb.html describes the minimum info required in bug
reports. Insufficient info makes it difficult to find and fix bugs.
ddb{4}> show panic
cpu4: ffs_valloc: dup alloc
ddb{4}) trace
db_enter() at db_enter+0x10
panic (81f1612f) at panic+0xbf|
ffs_inode_alloc(fd820bedf878,8180, fd81fe987008,
800022e4f528) at ffs_inode_alloc+0x42e
ufs_makeinode (8180,
fd8200b73130,800022e4f820,800022e4f850) at ufs_m ake
inode+0x79
ufs_create(800022e4f5d8) at ufs_create+0x3c
VOP_CREATE(fd8200b73130,800022e4f820,800022e4f850,800022e4f630)
at VOP_CREATE+0x3f
vn_open(800022e4f7f0, a03,180) at vn_open+0x162
doopenat (800022ba8a88, ff9c, 5d2b50be3b0, a02, 180,
800022e4f9d0) at doo penat+0x1cd
syscall(800022e4fa40) at syscall+0x35f
Xsyscall at Xsyscall+0x128
end of kernel end trace frame: 0x7f7c9820, count: -10
ddb{4}> mach ddbcpu 0
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(822c7ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi +0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle(822c7ff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb {0}> mach ddbcpu 1
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(800022509ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle(800022509ff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb{1}> mach ddbcpu 2
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(800022512ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_id le+0x203
sched_idle(800022512ff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb{2}> mach ddbcpu 3
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(80002251bff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle(80002251bff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb{3}> mach ddbcpu 5
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(80002252dff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler+0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle(80002252dff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb{5}) mach ddbcpu 6
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(800022536ff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler +0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_id le+0x203
sched_idle(800022536ff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb {6}) mach ddbcpu 7
Stopped at x86_ipi_db+0x12: leave
x86_ipi_db(80002253fff0) at x86_ipi_db+0x12
x86_ipi_handler() at x86_ipi_handler +0x80
Xresume_lapic_ipi() at Xresume_lapic_ipi+0x23
acpicpu_idle() at acpicpu_idle+0x203
sched_idle (80002253fff0) at sched_idle+0x280
end trace frame: 0x0, count: 10
ddb{7}>
(ps output from the kernel debugger is not copy/pasting well, but I
can provide it if it is truly necessary as mentioned on
Re: sndio and bit perfect playback
On Fri, Jan 13, 2023 at 01:10:56PM +0100, Jan Stary wrote: > > > > I'd certainly be interested in the ability to play audio in a way > > > > that avoids resampling altogether, > > > > > > If you have a 48kHz file, and your audio device can only do 44100, > > > then you have to resample, no way around it. > > > > > similar to what a user can do on FreeBSD with the > > > > following sysctl tweaks: > > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1 > > > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do > > > if the sample rate (or some other characteristics) is not what the device > > > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10 > > On Jan 10 09:36:28, a...@caoua.org wrote: > > chown /dev/audio* > > rcctl stop sndiod > > After doing that, > > $ play -V 48000.wav > play:SoX v14.4.2 > play INFO formats: detected file format type `wav' > > Input File : '48000.wav' > Channels : 2 > Sample Rate: 48000 > Precision : 16-bit > Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors > File Size : 4.80M > Bit Rate : 1.54M > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > > Output File: 'default' (sndio) > Channels : 2 > Sample Rate: 48000 > Precision : 16-bit > Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > play INFO sox: effects chain: input 48000Hz 2 channels > play INFO sox: effects chain: output 48000Hz 2 channels > In:15.4% 00:00:03.84 [00:00:21.16] Out:184kk [---=|=--- ] > Clip:0 > > $ play -V 44100.wav > play:SoX v14.4.2 > play INFO formats: detected file format type `wav' > > Input File : '44100.wav' > Channels : 2 > Sample Rate: 44100 > Precision : 16-bit > Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors > File Size : 4.41M > Bit Rate : 1.41M > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > Output File: 'default' (sndio) > Channels : 2 > Sample Rate: 44100 > Precision : 16-bit > Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors > Sample Encoding: 16-bit Signed Integer PCM > Endian Type: little > Reverse Nibbles: no > Reverse Bits : no > > play INFO sox: effects chain: input 44100Hz 2 channels > play INFO sox: effects chain: output 44100Hz 2 channels > In:25.3% 00:00:06.32 [00:00:18.68] Out:279kk [ =|= ] Clip:0 > Aborted. > > $ aucat -i 44100.wav > default: unsupported audio params > > $ aucat -i 48000.wav > default: unsupported audio params > > > It seems sox negotiates either 48000 or 44100 with sndio > (meaning the sndio library, not the non-running sndiod) and sends that, > but aucat errors out. But the device itself can do 48000 (says audioctl), > so is that a bug in aucat? > It's not related to the sample rate. Internally aucat uses 24-bit samples lsb-aligned in 32-bit words. Then, it assumes the device supports everything and doesn't bother setting up a conversion layer.
Re: sndio and bit perfect playback
> > > I'd certainly be interested in the ability to play audio in a way > > > that avoids resampling altogether, > > > > If you have a 48kHz file, and your audio device can only do 44100, > > then you have to resample, no way around it. > > > similar to what a user can do on FreeBSD with the > > > following sysctl tweaks: > > > # sysctl hw.snd.maxautovchans=0 dev.pcm.0.bitperfect=1 > > It's off topis of course, but What is dev.pcm.%d.bitperfect gonna do > > if the sample rate (or some other characteristics) is not what the device > > itself supports? As in e.g. $ play -r 12345 -c 3 -n synth 10 On Jan 10 09:36:28, a...@caoua.org wrote: > chown /dev/audio* > rcctl stop sndiod After doing that, $ play -V 48000.wav play: SoX v14.4.2 play INFO formats: detected file format type `wav' Input File : '48000.wav' Channels : 2 Sample Rate: 48000 Precision : 16-bit Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors File Size : 4.80M Bit Rate : 1.54M Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no Output File: 'default' (sndio) Channels : 2 Sample Rate: 48000 Precision : 16-bit Duration : 00:00:25.00 = 120 samples ~ 1875 CDDA sectors Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input48000Hz 2 channels play INFO sox: effects chain: output 48000Hz 2 channels In:15.4% 00:00:03.84 [00:00:21.16] Out:184kk [ ---=|=--- ]Clip:0 $ play -V 44100.wav play: SoX v14.4.2 play INFO formats: detected file format type `wav' Input File : '44100.wav' Channels : 2 Sample Rate: 44100 Precision : 16-bit Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors File Size : 4.41M Bit Rate : 1.41M Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no Output File: 'default' (sndio) Channels : 2 Sample Rate: 44100 Precision : 16-bit Duration : 00:00:25.00 = 1102500 samples = 1875 CDDA sectors Sample Encoding: 16-bit Signed Integer PCM Endian Type: little Reverse Nibbles: no Reverse Bits : no play INFO sox: effects chain: input44100Hz 2 channels play INFO sox: effects chain: output 44100Hz 2 channels In:25.3% 00:00:06.32 [00:00:18.68] Out:279kk [ =|= ]Clip:0 Aborted. $ aucat -i 44100.wav default: unsupported audio params $ aucat -i 48000.wav default: unsupported audio params It seems sox negotiates either 48000 or 44100 with sndio (meaning the sndio library, not the non-running sndiod) and sends that, but aucat errors out. But the device itself can do 48000 (says audioctl), so is that a bug in aucat? Jan
Re: sndio and bit perfect playback
On Jan 09 13:10:09, euryd...@riseup.net wrote: > I was able to distinguish between samples created by > audio/sox and aucat(1) in informal AB/X testing on my 7th generation X1 Carbon > with HiFiMan Sundara headphones plugged in. To describe the circumstances + > outcome briefly: 9 out of 10 correct in 10 trials http://stare.cz/.tmp/resample/ Which is which?
Re: Issue with acpi0 on Intel NUC11TNHi3
On 2023-01-12, Bradley Latus wrote: > I have an issue with my new intel NUC that I am trying to use as a PF > firewall box. > I have already tried upgrading to the latest BIOS but that does not appear > to have worked. > > Basically when you look at systat all I see 100% usage of 1 core servicing > ACPI0, on a completely otherwise idle system. First I would try a -current snapshot. Changes to gpio acpi devices might have fixed this. If that doesn't help, use sendbug run as root to generate a report, this includes the ACPI tables from the machine. (If you don't have mail setup on the machine itself, use sendbug -P > sendbug.txt and copy it to another machine where you can send mail). > Is there a way to isolate what is causing this issue? If you can isolate it to a particular acpi device that would reduce the size of the haystack of acpi tables - "boot -c" at the boot loader prompt, type e.g. "disable acpiec" (or some other device from "xxx at acpi0" in dmesg) and "quit". But -current first.
