[oss-devel] Need help with OSS application and syncing

[Hannu Savolainen]

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