Re: sndio - sio_getcap() clarification

2017-05-09 Thread Alexandre Ratchov
On Sun, May 07, 2017 at 08:06:14PM -0400, Andre Smagin wrote:
> On Mon, 8 May 2017 00:03:02 +0200
> Alexandre Ratchov  wrote:
> 
> > On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote:
> > > 
> > > >From my limited testing it appears that sio_getcap() fails if audio
> > > device does not have identical recording and playback capabilities
> > > (examples at the end). If that is indeed the case, could it possibly be
> > > mentioned in the man page somewhere? Perhaps something like:
> > 
> > The encoding and sample rate are common to play and record.  I mean
> > the audio stack assumes play and record parameters (except channels
> > count) are the same in full-duplex.
> > 
> > What you observe seems to be a driver or libsndio bug.  Could you
> > send the output of your program (or "cap") with SNDIO_DEBUG=1
> > environment variable exported, and the related dmesg lines?
> 
> I see. Would the manpage bit about different capabilities for SIO_REC and
> SIO_PLAY modes still be of use? I know I failed to realize at first
> that capabilities could be different based on how the device was opened.
> 
> Here is the log from my worst offender system:
> $ export SNDIO_DEBUG=1
> $ export AUDIODEVICE=rsnd/0
> $ cap -p config 0
> enc: s16le s24le
> pchan: 2
> rchan:
> rate: 44100 48000 96000
> $ cap -r 
> config 0
> enc: s16le
> pchan:
> rchan: 2
> rate: 44100 48000 96000
> $ cap
> AUDIO_SETPAR: Operation not supported by device
> sio_getcap() failed
> $ cap 
> /dev/audio0: Operation not supported by device
> sio_open() failed
> $ cap 
> /dev/audio0: Operation not supported by device
> sio_open() failed
> $ cap -p
> config 0
> enc: s16le s24le
> pchan: 2
> rchan:
> rate: 44100 48000 96000
> $ cap
> /dev/audio0: Operation not supported by device
> sio_open() failed
> $ cap 
> AUDIO_SETPAR: Operation not supported by device
> sio_getcap() failed
> 
> On this system, after sio_getcap fails for the first time, any further
> sio_getpar and get_getcap requests become unreliable/inconsistent and
> occasionally completely lock-up the sound subsystem, so the device cannot
> be opened at all - have to reboot at this point. Opening the device
> only in SIO_PLAY or SIO_REC mode sometimes sort-of resets it (as you can see
> in the log above). Also get this on console for every failed sio_getcap:
> 
> audio0: different play and record parameters returned by hardware

This is a bug in the audio driver: the parameters are saved by the
audio(4) driver but not supported by the hardware; in this case
it's supposed to select other (working) parameters instead of
failing.  The fix is not trivial, I'll send you a diff soon,
hopefully.



Re: sndio - sio_getcap() clarification

2017-05-07 Thread Andre Smagin
On Mon, 8 May 2017 00:03:02 +0200
Alexandre Ratchov  wrote:

> On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote:
> > 
> > >From my limited testing it appears that sio_getcap() fails if audio
> > device does not have identical recording and playback capabilities
> > (examples at the end). If that is indeed the case, could it possibly be
> > mentioned in the man page somewhere? Perhaps something like:
> 
> The encoding and sample rate are common to play and record.  I mean
> the audio stack assumes play and record parameters (except channels
> count) are the same in full-duplex.
> 
> What you observe seems to be a driver or libsndio bug.  Could you
> send the output of your program (or "cap") with SNDIO_DEBUG=1
> environment variable exported, and the related dmesg lines?

I see. Would the manpage bit about different capabilities for SIO_REC and
SIO_PLAY modes still be of use? I know I failed to realize at first
that capabilities could be different based on how the device was opened.

Here is the log from my worst offender system:
$ export SNDIO_DEBUG=1
$ export AUDIODEVICE=rsnd/0
$ cap -p config 0
enc: s16le s24le
pchan: 2
rchan:
rate: 44100 48000 96000
$ cap -r 
config 0
enc: s16le
pchan:
rchan: 2
rate: 44100 48000 96000
$ cap
AUDIO_SETPAR: Operation not supported by device
sio_getcap() failed
$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap -p
config 0
enc: s16le s24le
pchan: 2
rchan:
rate: 44100 48000 96000
$ cap
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap 
AUDIO_SETPAR: Operation not supported by device
sio_getcap() failed

On this system, after sio_getcap fails for the first time, any further
sio_getpar and get_getcap requests become unreliable/inconsistent and
occasionally completely lock-up the sound subsystem, so the device cannot
be opened at all - have to reboot at this point. Opening the device
only in SIO_PLAY or SIO_REC mode sometimes sort-of resets it (as you can see
in the log above). Also get this on console for every failed sio_getcap:

audio0: different play and record parameters returned by hardware

>From dmesg (full dmesg at the end):
azalia1 at pci0 dev 20 function 2 "AMD Hudson-2 HD Audio" rev 0x02: apic 5 int 
16
azalia1: codecs: Realtek ALC662
audio0 at azalia1

Second system with the same symptoms, but without noticed
hard lock-ups yet (running "cap -p" or "cap -r" seems to reset it):

$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed
$ cap -r
config 0
enc: s16le
pchan:
rchan: 2
rate: 44100 48000 96000
$ cap -p 
config 0
enc: s16le s24le
pchan: 2
rchan:
rate: 44100 48000 96000
$ cap
AUDIO_SETPAR: Operation not supported by device
sio_getcap() failed
$ cap 
/dev/audio0: Operation not supported by device
sio_open() failed

This one is:
azalia0 at pci0 dev 20 function 2 "ATI SBx00 HD Audio" rev 0x40: apic 2 int 16
azalia0: codecs: Realtek ALC662
audio0 at azalia0

Dmesg for the first system:
OpenBSD 6.1-current (GENERIC.MP) #55: Fri Apr 14 13:54:33 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1535582208 (1464MB)
avail mem = 1484423168 (1415MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebe10 (16 entries)
bios0: vendor American Megatrends Inc. version "4.6.5" date 04/22/2014
bios0: BIOSTAR Group A68N-5000
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG HPET SSDT SSDT CRAT SSDT SSDT
acpi0: wakeup devices RTL_(S4) LOM_(S4) SBAZ(S4) OHC1(S4) EHC1(S4) OHC2(S4) 
EHC2(S4) OHC3(S4) EHC3(S4) XHC0(S4) BR11(S4) PWRB(S4)
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD A4-5000 APU with Radeon(TM) HD Graphics, 1497.40 MHz
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,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,ITSC,BMI1
cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 
16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
cpu0: TSC frequency 1497400130 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD A4-5000 APU with Radeon(TM) HD Graphics, 1497.20 MHz
cpu1: 

Re: sndio - sio_getcap() clarification

2017-05-07 Thread Alexandre Ratchov
On Sun, May 07, 2017 at 02:10:03PM -0400, Andre Smagin wrote:
> 
> >From my limited testing it appears that sio_getcap() fails if audio
> device does not have identical recording and playback capabilities
> (examples at the end). If that is indeed the case, could it possibly be
> mentioned in the man page somewhere? Perhaps something like:

The encoding and sample rate are common to play and record.  I mean
the audio stack assumes play and record parameters (except channels
count) are the same in full-duplex.

What you observe seems to be a driver or libsndio bug.  Could you
send the output of your program (or "cap") with SNDIO_DEBUG=1
environment variable exported, and the related dmesg lines?

thanks



sndio - sio_getcap() clarification

2017-05-07 Thread Andre Smagin

>From my limited testing it appears that sio_getcap() fails if audio
device does not have identical recording and playback capabilities
(examples at the end). If that is indeed the case, could it possibly be
mentioned in the man page somewhere? Perhaps something like:

Index: sio_open.3
===
RCS file: /build/openbsd/cvs/src/lib/libsndio/sio_open.3,v
retrieving revision 1.46
diff -u -p -r1.46 sio_open.3
--- sio_open.3  3 Jan 2017 20:29:28 -   1.46
+++ sio_open.3  7 May 2017 17:22:31 -
@@ -285,6 +285,17 @@ parameter combinations in advance can us
 .Fn sio_getcap
 function.
 .Pp
+.Fn sio_getcap
+function can return different results based on whether
+.Dv SIO_PLAY
+or
+.Dv SIO_REC
+mode was selected.
+It can fail for the device with differing recording and
+playback capabilities opened in
+.Dv SIO_PLAY | SIO_REC
+mode.
+.Pp
 The
 .Vt sio_cap
 structure contains the list of parameter configurations.



Examples that I am retrieving with sio_getpar() and sio_getcap()
with a program similar to src/regress/lib/libsndio/cap/cap.c:

rsnd/0 (play) parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (rec)  parameters: s16le/48000, 2 play/2 rec channels
rsnd/0 (play+rec) parameters: s16le/48000, 2 play/2 rec channels
rsnd/0 (play) capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 96000
Recording channels:
Playback channels: 2
rsnd/0 (rec)  capabilities:
Configuration 1 out of 1:
Encodings: s16le
Rates: 44100 48000 96000
Recording channels: 2
Playback channels:
rsnd/0 (play+rec) capabilities:
Error getting capabilities.


but on a different system with better audio hardware it succeeds:

rsnd/0 (play) parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (rec)  parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (play+rec) parameters: s24le/48000, 2 play/2 rec channels
rsnd/0 (play) capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 88200 96000
Recording channels:
Playback channels: 2 4 6 8 10
rsnd/0 (rec)  capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 88200 96000
Recording channels: 2
Playback channels:
rsnd/0 (play+rec) capabilities:
Configuration 1 out of 1:
Encodings: s16le s24le
Rates: 44100 48000 88200 96000
Recording channels: 2
Playback channels: 2 4 6 8 10