Re: port-sparc/55876: sparc tests hang at lib/libossaudio/t_ossaudio

[Tetsuya Isaki <isaki%pastel-flower.jp@localhost>]

At Mon, 14 Dec 2020 15:10:01 +0000 (UTC),
nia wrote:
>  "audiocfg list" would be useful to see.
>  I suspect, if your userspace is up to date, this has uncovered a bug.

AUDIO_SETINFO requires to be set to -1 for items that you don't want
to change.  But AUDIO_GETBUFINFO returns(fills) 0 for untouched items.
Therefore you can't reuse audio_info_t you get from AUDIO_GETBUFINFO.
This has been the behavior since AUDIO_GETBUFINFO was first committed
in 2007.  (and it's undocumented...)

This patch (for libossaudio) fixes oss_dsp_init test.
# But the next test hangs (on sparc/qemu).  While a quick look,
# audiocs(4) seems to have another problem...)

--- src/lib/libossaudio/ossaudio.c.ORG	2020-12-07 19:03:36.348518216 +0900
+++ src/lib/libossaudio/ossaudio.c	2020-12-15 13:44:06.157851712 +0900
@@ -183,12 +183,12 @@
 		/* This call is merely advisory, and may be a nop. */
 		break;
 	case SNDCTL_DSP_SPEED:
-		AUDIO_INITINFO(&tmpinfo);
 		/*
 		 * In Solaris, 0 is used a special value to query the
 		 * current rate. This seems useful to support.
 		 */
 		if (INTARG == 0) {
+			AUDIO_INITINFO(&tmpinfo);
 			retval = ioctl(fd, AUDIO_GETBUFINFO, &tmpinfo);
 			if (retval < 0)
 				return retval;
@@ -204,6 +204,7 @@
 		 * NetBSD will reject unsupported sample rates, but OSS
 		 * applications need to be able to negotiate a supported one.
 		 */
+		AUDIO_INITINFO(&tmpinfo);
 		if (INTARG < 1000)
 			INTARG = 1000;
 		if (INTARG > 192000)


By the way, I personally think this AUDIO_GETBUFINFO behavior (in the
kernel) is very confusing.  But I don't know whether this behavior was
intended or not.  (So I kept it during my audio development to avoid
any other confusions)
Should we change it now?

Thanks,
---
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>