On Tuesday 20 May 2008 22:04:51 Timur Tabi wrote: > I'm working with a customer that has discovered a possible problem with OSS > emulation on ALSA. Unfortunately, I don't have a lot of experience with OSS, > so > I need help understanding whether the customer's observations point to a real > problem or not. > > The customer is using an old application called "bplay" to test OSS audio > support on our hardware. The application works fine on x86, but fails on our > PowerPC board. It could be an endian issue, but I doubt it. > > Here is the forwarded email (slightly edited). Can someone familiar with the > OSS "sync" functionality comment? What exactly does SNDCTL_DSP_SYNC do, and > why > would an application call it? > > --------------- > > They reported that it seemed some ioctl commands in the OSS emulation did not > work correctly. > > The tested procedure of the ioctl commands are as following, > > #1) Stopped audio stream output after doing followings: > 1. Opening /dev/mixer > 2. Getting a channel value (0x00000001) that is used for "ioctl(fd, > SOUND_MIXER_READ_DEVMASK, &Sndsts);". > 3. Write audio volume information by "ioctl(fd, > SOUND_MIXER_WRITE_VOLUME, &Value);", > > #2) Stopped audio stream output after doing following: > 1. Opening /dev/dsp > 2. Executing command "ioctl(fd, SNDCTL_DSP_SYNC, NULL);", > > XXXX found that by commenting out the "sync_audio" function on the source > code of "bplay" made "bplay" work. So XXXX suspects the implementation of the > ioctl on the OSS emulation may have a problem. >
I wonder which bplay they using - is it the same as the Debian package? Per its bug tracker, it had all sorts of endianess issues (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=126257, tp://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293531), and unless patched won't play WAVs correctly on big-endian hardware. bplay calls SNDCTL_DSP_SYNC at the start of snd_parm function which sets device parameters. This function should suspend the app until all samples previously written to device have been played [1]. The old OSSv3 (this is the version which is emulated by ALSA, current is OSSv4) manual says the first calls to device must set its parameters or the result is undefined [2]. In short: ALSA may well have a bug somewhere, but what bplay is doing is very likely wrong (If I can judge by the code obtained via Debian. Your client may use a different package?). bplay should probably either call SNDCTL_DSP_RESET after the SNDCTL_DSP_SYNC, or close and reopen the device. ossplay has a very similar, but correctly implemented method [3]. [1] http://manuals.opensound.com/developer/SNDCTL_DSP_SYNC.html (OSSv4) [2] http://www.opensound.com/pguide/oss.pdf (page 31) [3] http://mercurial.opensound.com/?file/d695f17413b2/cmd/ossplay/ossplay.c see line 267 or so (SNDCTL_DSP_HALT is an OSSv4 synonym for SNDCTL_DSP_RESET). [4] This is merely my opinion, and carries no other weight. I don't work for 4front, I just post here once in a while. Yours, Yair K. _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
