Re: new USB audio class v2.0 driver

[chohag]

Alexandre Ratchov writes:
> On Wed, Sep 25, 2019 at 05:15:22PM +0100, cho...@jtan.com wrote:
> > I have a similar problem to Alexander Hof with a presonus audio usb
> > device, where attaching it reports 'only one AC iface allowed' and the
> > device remains (apparently totally) inaccessible.
> >
> > dmes and lsusb included below.
> >
>
> According to dmesg, this is 6.5, which doesn't contain the fix for
> this problem. Could you try the device on a -current system?

I did look through the post 6.5 changes in CVS but couldn't see anything
relevent, possibly for reasons that will become clear.

> Programmable clocks are OK, the comment states that we don't support
> multiple clock sources simultaneously. When audio starts, all parts of
> the device must be clocked by the same clock source.
>
> Pro audio interfaces use necessarily a single clock because otherwise
> they wouldn't be unstable in DAWs and/or for real-time effects.
>
> FWIW, I've never seen -- or even heard of -- devices using multiple
> clock sources simultaneously.

Good, because that was a complete red herring. The _other_ instance of
'%s: only one AC iface allowed' is the one associated with the fault, in
uaudio_process_conf(). Perhaps the error message at the end of
uaudio_process_ac() could read '%s: only one distinct clock source
allowed'?

There is good news and bad news about -current. The good news is that
the upgrade was seamless and the device is registered without reporting
an error. The bad news is that I'd eventually managed to notice the
empty (?) control interface and skip it, but it still didn't/doesn't
work:

uaudio0 at uhub3 port 2 configuration 1 interface 1 "PreSonus AudioBox USB 96" 
rev 2.00/1.12 addr 4
uaudio0: class v2, high-speed, async, channels: 2 play, 2 rec, 0 ctls
audio1 at uaudio0
umidi0 at uhub3 port 2 configuration 1 interface 4 "PreSonus AudioBox USB 96" 
rev 2.00/1.12 addr 4
umidi0: (genuine USB-MIDI)
umidi0: out=1, in=1
midi0 at umidi0: 
ugen1 at uhub3 port 2 configuration 1 "PreSonus AudioBox USB 96" rev 2.00/1.12 
addr 4

ludmilla$ audioctl -f /dev/audioctl1
name=uaudio0
mode=
pause=0
active=0
nblks=2
blksz=960
rate=48000
encoding=s16le
play.channels=2
play.bytes=0
play.errors=0
record.channels=2
record.bytes=0
record.errors=0

ludmilla$ mixerctl -f /dev/mixer1
record.enable=sysctl

ludmilla$ sysctl |grep -e mix -e audio
kern.audio.record=0

And from mplayer with AUDIODEVICE=snd/1:
...
ao2: can't open sndio
...

Matthew

Re: new USB audio class v2.0 driver

[chohag]

I have a similar problem to Alexander Hof with a presonus audio usb
device, where attaching it reports 'only one AC iface allowed' and the
device remains (apparently totally) inaccessible.

dmes and lsusb included below.

The device and the box it plugs into are both available for prodding and
poking if it might help as neither is in use (but note I am not on tech@).

It would appear that this assumption doesn't fully hold on some,
professional?, usb audio hardware:

/*
 * Find common clock unit. We assume all terminals
 * belong to the same clock domain (ie are connected
 * to the same source)
 */

A cheap USB sound card I have to hand does not include the programmable
clock in its lsusb output, or indeed anything marked CLOCK_SOURCE.

Matthew

OpenBSD 6.5 (GENERIC.MP) #0: Wed Apr 24 23:38:54 CEST 2019

r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34191831040 (32607MB)
avail mem = 33145958400 (31610MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7a9bc000 (99 entries)
bios0: vendor American Megatrends Inc. version "N.1.03" date 05/16/2018
bios0: MEDION ERAZER X6805 MD61140
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT MSDM SSDT SSDT HPET SSDT 
SSDT UEFI LPIT DBGP DBG2 SSDT DMAR BGRT TPM2 SSDT WSMT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2096.92 MHz, 06-9e-0a
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2095.14 MHz, 06-9e-0a
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2095.14 MHz, 06-9e-0a
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2095.13 MHz, 06-9e-0a
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 8 (application processor)
cpu4: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz, 2095.13 MHz, 06-9e-0a
cpu4: 

Re: ed(1) man page doesn't mention use of single / and ?

[chohag]

ropers writes:
> > matthew: "ed reacts differently depending whether or not it's included".
> > can you explain how?

If I recall correctly, if the trailing delimiter is _not_ included then ed 
prints the result of the substitution. Possibly only if interactive.

> W/r/t Matthew's concerns, I also note that the
> > (.,.)s/re/replacement/
> section does mention this in its second paragraph:
> >> If one or two of the last delimiters is omitted, then the last line
> >> affected is printed as though the print suffix p were specified.
> I'm not quite sure what is meant by omission of *two* of the last
> delimiters there, but this does at least seem relevant to what we're
> discussing here.

Yes that sounds about right. Looks like some part of this behaviour is in 
documented already.

The pedantic part of me likes getting this pointless thing right but the 
pedantic part of me also wants to make sure it's actually right before changing 
something that evidently works already and isn't bothering anybody. I managed 
to learn ed with the manpage as it is.

It sounds like there might be a bit of confusion wrt. what does/doesn't happen 
vs. what's documented. Can the various interactions under discussion be 
actually clarified and enumerated to be sure we're not changing a minor mistake 
for a new mistake? I can do this tomorrow if nobody else jumps in but I'd get 
it wrong if I tried it now.

Matthew