Re: sndio and bit perfect playback

2022-10-25 Thread Andre Smagin 
On Tue, 25 Oct 2022 16:44:59 +0200
Christian Weisgerber  wrote:

> Andre Smagin:
> 
> > There is possibly one more use case for "bit-perfect". I have a small
> > collection of surround sound (5.1, 4.1, quad, etc) recordings extracted
> > from various DVDs, SACDs, and other sources.
> 
> Yup.
> I even have a commercially released DTS-CD lying around somewhere,
> which is basically an ordinary CD except that the audio is encoded
> as DTS and not PCM.
> 
> > My desktop is connected to a receiver via optical SPDIF cable. To get
> > the surround sound, I use mpd with 'device "snd/0"' option and Ario to
> > control the mpd daemon.
> 
> I'm curious, what's the actual audio hardware?  azalia(4) or uaudio(4)?

It is azalia, built-in on the motherboard (dmesg at the end).
 
> > Bit depth does not seem to matter. I don't care about "bit-perfect", but
> > only about sending the dts stream to the receiver as-is, which works.
> 
> S/PDIF actually has a native depth of 20 bits per sample.  There
> are also 4 spare bits in the frame, which can optionally be used
> to transport 24 bits.  If an audio source provides only 16 bits per
> sample, those are fit into the 20 bit frame with the remaining bits
> unused.  DTS and AC3 encodings for S/PDIF only use 16 bits.

Ah, thank you for the explanation! I tried reading the DTS
specification once, but it is way over my head. 

-- 
Andre Smagin 

OpenBSD 7.2-current (GENERIC.MP) #778: Mon Oct 10 22:34:04 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 68596912128 (65419MB)
avail mem = 66500554752 (63419MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6cf0 (59 entries)
bios0: vendor American Megatrends International, LLC. version "A.I0" date 
08/10/2022
bios0: Micro-Star International Co., Ltd. MS-7C37
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT SSDT FIDT MCFG HPET SSDT IVRS FPDT PCCT SSDT 
CRAT CDIT SSDT SSDT SSDT SSDT WSMT APIC SSDT
acpi0: wakeup devices GPP0(S4) GPP2(S4) GPP3(S4) GPP4(S4) GPP5(S4) GPP6(S4) 
GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4) GPPE(S4) 
GPPF(S4) GP10(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0
acpimcfg0: addr 0xf000, bus 0-127
acpihpet0 at acpi0: 14318180 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 9 5950X 16-Core Processor, 3400.06 MHz, 19-21-00
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 100MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: AMD Ryzen 9 5950X 16-Core Processor, 3400.00 MHz, 19-21-00
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: AMD Ryzen 9 5950X 16-Core Processor, 3400.00 MHz, 19-21-00
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 
8-way L2 cache, 32MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: AMD Ryzen 9 5950X 16-Core Processor, 3400.00 MHz, 19-21-00
cpu3:

Re: sndio and bit perfect playback

2022-10-25 Thread Christian Weisgerber 
Andre Smagin:

> There is possibly one more use case for "bit-perfect". I have a small
> collection of surround sound (5.1, 4.1, quad, etc) recordings extracted
> from various DVDs, SACDs, and other sources.

Yup.
I even have a commercially released DTS-CD lying around somewhere,
which is basically an ordinary CD except that the audio is encoded
as DTS and not PCM.

> My desktop is connected to a receiver via optical SPDIF cable. To get
> the surround sound, I use mpd with 'device "snd/0"' option and Ario to
> control the mpd daemon.

I'm curious, what's the actual audio hardware?  azalia(4) or uaudio(4)?

> Bit depth does not seem to matter. I don't care about "bit-perfect", but
> only about sending the dts stream to the receiver as-is, which works.

S/PDIF actually has a native depth of 20 bits per sample.  There
are also 4 spare bits in the frame, which can optionally be used
to transport 24 bits.  If an audio source provides only 16 bits per
sample, those are fit into the 20 bit frame with the remaining bits
unused.  DTS and AC3 encodings for S/PDIF only use 16 bits.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Cannot edit a command in history in vi-mode

2022-10-25 Thread Maksim Rodin 
Hello,
My default shell is ksh and there is "set -o vi" in .profile

1) When I type in a command directly in the terminal window(xterm), I can
press "Esc" and then "v" and after that my $EDITOR opens (nvim) and I am
able to make modifications to this command. Then I press "Esc" and "ZZ" in
the editor, it closes and the final command is executed.
2) When I try to do the same with the command in the shell history, this
looks different:
I press "Esc" and then "/" and then something I want to find in the
history and then "Enter". Using "n" I find the command in history and
press "Esc" and "v" to edit this command. The $EDITOR opens, I make some
modifications, then save and exit the $EDITOR, and the old command is
executed without any changes I have just made.

Is case 2 the correct behaviour or do I do something wrong?
My current system is OpenBSD 7.2 amd64

-- 
Maksim Rodin

Re: spurious synproxy warning from pfctl

2022-10-25 Thread Stuart Henderson 
On 2022-10-24, Lyndon Nerenberg (VE7TFX/VE6BBM)  wrote:
> Given the rule
>
>   pass proto tcp from any to mail.example.com \
> port { 25 80 110 143 443 587 993 } synproxy state
>
> pfctl barks
>
>  /etc/pf.conf:586: warning: synproxy used for inbound rules only, ignored for 
> outbound
>
> It's pretty obvious from reading pf.conf(5) that the above is the
> default behaviour, and it seems perfectly reasonable to apply
> 'synproxy state' to pass rule that implies 'in'.  So I don't see
> the reason for pfctl to nag at me like that,

That pass rule doesn't just imply "in", it is "in and out".

"synproxy state" cannot work on outbound (for more details see
https://marc.info/?l=openbsd-tech=160686649524095=2).

Because pfctl is doing something other than what you asked it to do,
IMO the warning makes sense.

Alternatively it could be classed as an error but that won't be very
fun for people upgrading.