Re: bought an Audigy soundcard hoping it'd work.

[Jan Stary]

On Aug 17 01:52:44, lukensm...@gmail.com wrote:
> I have a cheap 6450 radeon graphics card with unsupported audio and an
> Audigy FX
> 
> I hoped Audigy card would work on the emu(4) driver, but doesn't seem to.

What help do you expect to get
saying "it doesn't seem to work"?

Go through https://www.openbsd.org/faq/faq13.html
show what exactly you have done and what happened.

> I turned on sysctl kern.audio.record=1

> dmesg:
> ...
> azalia0 at pci3 dev 0 function 1 "ATI Radeon HD 6400 Audio" rev 0x00: msi
> azalia0: no supported codecs

That's the unsupported audio on the radeon.

> azalia1 at pci13 dev 0 function 0 vendor "Creative Labs", unknown product
> 0x0012 rev 0x01: msi
> azalia1: codecs: Realtek/0x0899
> audio0 at azalia1

That's the supported audio on the Audigy card.

So first, what does mixerctl -av say?

envy(4) timeouts with ESI Wave Terminal 192M

[Jan Stary]

This is current/amd64 on an older PC (full dmesg below)
using an ESI Wave Terminal 192M attaching as

envy0 at pci4 dev 4 function 0 "IC Ensemble Envy24PT/HT Audio" rev 0x01: apic 2 
int 20
envy0: unknown 1724-based card, 2 inputs, 8 outputs
audio0 at envy0
midi0 at envy0: 

This is what audioctl and mixerctl show
as the exposed controls:

# audioctl
name=envy0
mode=
pause=1
active=0
nblks=4
blksz=480
rate=48000
encoding=s24le4msb
play.channels=8
play.bytes=0
play.errors=0
record.channels=2
record.bytes=0
record.errors=0

# mixerctl -av
outputs.line-0_source=play-0  [ line-0 line-1 play-0 ]
outputs.line-1_source=play-1  [ line-0 line-1 play-1 ]
outputs.line-2_source=play-2  [ line-0 line-1 play-2 ]
outputs.line-3_source=play-3  [ line-0 line-1 play-3 ]
outputs.line-4_source=play-4  [ line-0 line-1 play-4 ]
outputs.line-5_source=play-5  [ line-0 line-1 play-5 ]
outputs.line-6_source=play-6  [ line-0 line-1 play-6 ]
outputs.line-7_source=play-7  [ line-0 line-1 play-7 ]
record.enable=sysctl  [ off on sysctl ]

Is this expected? With other audio devices
I usualy also see some mixer and volume controls.


I am seeing timeouts with both recording and playback:

$ aucat -o file.wav
$ default: audio device gone, stopping

$ aucat -i file.wav
$ default: audio device gone, stopping

While this happens, dmesg says:

envy0: output DMA halt timeout
envy0: input DMA halt timeout
envy0: output DMA halt timeout
envy0: input DMA halt timeout

How can I help debug this?

Jan

OpenBSD 6.9-current (GENERIC.MP) #186: Sun Aug 15 20:36:45 MDT 2021
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4242145280 (4045MB)
avail mem = 4097613824 (3907MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xfccb0 (23 entries)
bios0: vendor American Megatrends Inc. version "5.13" date 03/03/2010
bios0: Hewlett-Packard Compaq 500B Microtower
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S3 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT
acpi0: wakeup devices P0P2(S4) P0P3(S4) P0P1(S4) MC97(S4) P0P4(S4) P0P5(S4) 
P0P6(S4) P0P7(S4) LAN1(S1) P0P8(S4) P0P9(S4) USB0(S3) USB1(S3) USB2(S3) 
USB3(S3) EUSB(S3)
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)2 Duo CPU E7500 @ 2.93GHz, 2933.71 MHz, 06-17-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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 277MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz, 3050.68 MHz, 06-17-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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 2 (P0P4)
acpiprt3 at acpi0: bus 3 (P0P5)
acpiprt4 at acpi0: bus -1 (P0P6)
acpiprt5 at acpi0: bus -1 (P0P7)
acpiprt6 at acpi0: bus -1 (P0P8)
acpiprt7 at acpi0: bus -1 (P0P9)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
acpicpu0 at acpi0
acpi0: SSDT checksum error: C1(@1 halt!), PSS
acpicpu1 at acpi0: C1(@1 halt!), PSS
cpu0: Enhanced SpeedStep 2933 MHz: speeds: 2936, 2670, 2403, 2136, 1870, 1603 
MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel G41 Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel G45 PCIE" rev 0x03: msi
pci1 at ppb0 bus 1
nvme0 at pci1 dev 0 function 0 "Toshiba NVMe" rev 0x01: msix, NVMe 1.2
nvme0: KBG30ZMV128G TOSHIBA, firmware ADHA0102, serial 29OPC7NPPZWP
scsibus1 at nvme0: 2 targets, initiator 0
sd0 at scsibus1 targ 1 lun 0: 
sd0: 122104MB, 512 bytes/sector, 250069680 sectors
inteldrm0 at pci0 dev 2 function 0 "Intel G41 Video" rev 0x03
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0: apic 2 int 16, G45, gen 4
ppb1 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x01: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 1 "Intel 82801GB PCIE" rev 0x01: msi
pci3 at ppb2 bus 3
re0 at pci3 dev 0 function 0 "Realtek 8101E" rev 0x02: RTL8102EL (0x2480), msi, 
address d8:d3:85:7f:58:94
rlphy0 at re0

Re: scim input method not show up

[Rasmus Liland]

Hello!  Also there is ibus [1] but it 
seems to have less input methods.  
Somehow, I ended up using sunpinyin [2] 
on arch [3] ...  R

[1] https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/inputmethods/ibus/Makefile 
[2] https://github.com/sunpinyin/sunpinyin
[3] https://archlinux.org/packages/community/x86_64/ibus-sunpinyin/ 

Re: envy(4) timeouts with ESI Wave Terminal 192M

[Alexandre Ratchov]

On Tue, Aug 17, 2021 at 03:31:55PM +0200, Jan Stary wrote:
> This is current/amd64 on an older PC (full dmesg below)
> using an ESI Wave Terminal 192M attaching as
> 
> envy0 at pci4 dev 4 function 0 "IC Ensemble Envy24PT/HT Audio" rev 0x01: apic 
> 2 int 20
> envy0: unknown 1724-based card, 2 inputs, 8 outputs
> audio0 at envy0
> midi0 at envy0: 
> 
> This is what audioctl and mixerctl show
> as the exposed controls:
> 
> # audioctl
> name=envy0
> mode=
> pause=1
> active=0
> nblks=4
> blksz=480
> rate=48000
> encoding=s24le4msb
> play.channels=8
> play.bytes=0
> play.errors=0
> record.channels=2
> record.bytes=0
> record.errors=0
> 
> # mixerctl -av
> outputs.line-0_source=play-0  [ line-0 line-1 play-0 ]
> outputs.line-1_source=play-1  [ line-0 line-1 play-1 ]
> outputs.line-2_source=play-2  [ line-0 line-1 play-2 ]
> outputs.line-3_source=play-3  [ line-0 line-1 play-3 ]
> outputs.line-4_source=play-4  [ line-0 line-1 play-4 ]
> outputs.line-5_source=play-5  [ line-0 line-1 play-5 ]
> outputs.line-6_source=play-6  [ line-0 line-1 play-6 ]
> outputs.line-7_source=play-7  [ line-0 line-1 play-7 ]
> record.enable=sysctl  [ off on sysctl ]
> 
> Is this expected? With other audio devices
> I usualy also see some mixer and volume controls.
> 
> 
> I am seeing timeouts with both recording and playback:
> 
>   $ aucat -o file.wav
>   $ default: audio device gone, stopping
> 
>   $ aucat -i file.wav
>   $ default: audio device gone, stopping
> 
> While this happens, dmesg says:
> 
>   envy0: output DMA halt timeout
>   envy0: input DMA halt timeout
>   envy0: output DMA halt timeout
>   envy0: input DMA halt timeout
> 
> How can I help debug this?
> 

Hi,

You could start by enabling ENVY_DEBUG option rebuild kernel and see
if you get additional information.

The "DMA halt timeout" errors probably indicate that DMA never
started, which is very strange. You can check this by writing zeros to
/dev/audio1 and see if there are interrupts (ex. with "systat
vmstat").  No interrupts indicates DMA didn't start.

Basically, these cards have an Envy chip which is the interface to the
PCI bus and handles DMA and interrupts. The Envy chip is connected to
one or more DACs and/or ADCs (or to a complete AC97-style codec). The
Envy chip simply reads data from hosts memory and sends it to the DAC.

For sound to work ADC/DACs may need to be configured; this is done
either by setting GPIO pins or sending few bytes through a I2C link.
As your card is not known by OpenBSD driver, the code for ADC/DAC
initialization is missing. You can figure-out what ADC/DAC your card
is using by looking at the ICs on the board (the big one is the Envy
chip, aka ICE, the other big one(s) are the ADC/DAC), then google
for the corresponding datasheets

The interesting part in your dmesg is that DMA doesn't seem to start,
I thought DMA would start even if the ADC/DAC is not initialized, but
I may be wrong.