Hi Iain,
thank you for your response!
>
> your frames are 10ms - but is that also true of the OSS driver? (see
> questions below)..
>
I do not explicitly request a specific fragment size. Therefore I expect
the OSS driver to compute a suitable size.
> what size (and how many) fragments are you using (and what AFMT)?
>
<code_citation>
#define OSS_AFMT AFMT_S16_LE
</code_citation>
> > Do I have to 'open - write to - close' the device for every frame?
>
> No. That probably wouldn't work at all - there's a hint in the OSS manual
> that allows drivers to buffer two frames before starting output...
>
That's what I expected!
Actually I have tried to do so but not successfully.
> > Do I have to setup a signal handler for SIGTERM to close the audio
> > device properly?
>
> This shouldn't be necessary either.
>
You take a load off my mind!
>
> OK. This may depend on how well the OSS driver conforms to the OSS spec.
> and will depend on the fragment size. When you close the device audio that
> is already buffered may still be output (although I'd expect the driver to
> keep your application in sleep until it was finished).
>
Actually my problem only appears when my decoder is exec'ed by another
(GUI) application which is cappable of starting and killing (-9!)
several codecs.
I am not able to reconstruct this behaviour in a shell environment
directly!
But: All other codecs (e. g. mpg123) do not block /dev/dsp.
Any further comments are warmly welcome.
