Timur Tabi kirjoitti: > 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? > SNDCTL_DSP_SYNC waints until the device has played all the data written by the application. Then it does the same than SNDCTL_DSP_HALT to stop the device. Next write to the device will restart the playback.
The only situation when applications should use this call is when it needs to change the sampling rate/etc. This call will cause a short pause to output so it cannot be used in the middle of "file". > --------------- > > 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. > SNDCTL_DSP_SYNC and SNDCTL_DSP_RESET are likely to cause problems with emulations. Many applications use these calls in wrong situations "just to make sure" which causes many kind of problems. OSS emulations may also do whatever they see necessary instead of doing just the right thing. Another problem point seems to be that OSS emulations don't tolerate blocking writes. So applications need to use various methods to prevent writing more data than there is space available in the buffers. Unfortunately many of these alternative approaches are broken. The result is that applications modified for ALSA's OSS emulation will not work any more (even with OSS4). Best regards, Hannu _______________________________________________ oss-devel mailing list oss-devel@mailman.opensound.com http://mailman.opensound.com/mailman/listinfo/oss-devel
