On Sun, May 07, 2017 at 08:06:14PM -0400, Andre Smagin wrote: > On Mon, 8 May 2017 00:03:02 +0200 > Alexandre Ratchov <[email protected]> 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.
