Re: kern/54264: audio(4) API fails to detect a capture-only device

[Takeshi Nakayama <nakayama%NetBSD.org@localhost>]

The following reply was made to PR kern/54264; it has been noted by GNATS.

From: Takeshi Nakayama <nakayama%NetBSD.org@localhost>
To: isaki%pastel-flower.jp@localhost
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54264: audio(4) API fails to detect a capture-only device
Date: Thu, 06 Jun 2019 10:25:54 +0900 (JST)

 >>> Tetsuya Isaki <isaki%pastel-flower.jp@localhost> wrote
 
 > At Sun,  2 Jun 2019 13:35:00 +0000 (UTC),
 > nia%netbsd.org@localhost wrote:
 > > First I query the device with AUDIO_GETPROPS.  It claims that the
 > > device has playback support.  This is incorrect.
 > 
 > Please try this patch.
 > uaudio doesn't return correct property on unidirectional device.
 > current audio (isaki-audio2) requires that the hardware driver's
 > get_props() returns exact property.
 > 
 > nakayama@-san,
 > dev/audio/audio.c,v 1.5 and 1.7 look wrong.  It assumes that the
 > hardware driver may return incorrect property.  But this assumption
 > is not right (and not good).  The condition
 >  (unidirection && full duplex), or
 >  (unidirection && the device can set play and rec independently)
 > are obviously strange and such hardware driver should be fixed.
 > Would you test this patch?
 
 The patch for uaudio.c works well on my USB speaker.
 
 Rev.1.7 of audio.c is workaround, so I agree with reverting it.
 But I don't think rev.1.5 is completely wrong.  Variable error is
 used for result of both audio_hw_probe_fmt(..., AUMODE_PLAY) and
 audio_hw_probe_fmt(..., AUMODE_RECORD), so the result for
 AUMODE_PLAY is overwritten by its for AUMODE_RECORD.
 
 I think both errors should be checked and audio_hw_probe returns
 error if both are in error as of rev.1.5, or if one or the other is
 in error.
 
 Also, if such a strange hardware driver should be fixed, I think
 that you should add KASSERT or else to detect such a driver.
 
 -- Takeshi Nakayama