[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54264: audio(4) API fails to detect a capture-only device
>>> 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.
> 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
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
Main Index |
Thread Index |