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

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

The following reply was made to PR port-sparc/55876; it has been noted by GNATS.

From: Tetsuya Isaki <isaki%pastel-flower.jp@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: port-sparc-maintainer%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost,
	gson%gson.org@localhost (Andreas Gustafsson)
Subject: Re: port-sparc/55876: sparc tests hang at lib/libossaudio/t_ossaudio
Date: Tue, 15 Dec 2020 16:39:03 +0900

 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>