RE: [linux-audio-dev] OSS question
On Mon, 30 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: Iain Sandoe schrieb: I wrote: Do I have to setup a signal handler for SIGTERM to close the audio device properly? This shouldn't be necessary either. Ok a replied too quickly - it is (only) when you get SIGTERM that you have the problem? I am sorry, actually it is a SIGKILL :( But a SIGTERM makes no difference. you cannot catch SIGKILL, but generally you shouldn't kill application using SIGKILL (only if it does not respond to SIGTERM) - precisely for that reason - it does not have a chance to exit gracefully. as for you problem - I guess setting a signal handler that closes audio device (if still opened!) is the right way to go. It should be done by the default exit routine though so I am not sure if you gain anything. You're on a UNIX system, so the kernel generally cleans up after you (i.e. it closes open fds, frees your memory, etc.), so if your soundcard /driver is not happy with being SIGKILLed then thats a driver bug I'd report to the appropriate place. Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
RE: [linux-audio-dev] OSS question
-Original Message- From: Richard Guenther [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 31, 2001 1:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [linux-audio-dev] OSS question On Mon, 30 Jul 2001, STEFFL, ERIK *Internet* (SBCSI) wrote: Iain Sandoe schrieb: I wrote: Do I have to setup a signal handler for SIGTERM to close the audio device properly? This shouldn't be necessary either. Ok a replied too quickly - it is (only) when you get SIGTERM that you have the problem? I am sorry, actually it is a SIGKILL :( But a SIGTERM makes no difference. you cannot catch SIGKILL, but generally you shouldn't kill application using SIGKILL (only if it does not respond to SIGTERM) - precisely for that reason - it does not have a chance to exit gracefully. as for you problem - I guess setting a signal handler that closes audio device (if still opened!) is the right way to go. It should be done by the default exit routine though so I am not sure if you gain anything. You're on a UNIX system, so the kernel generally cleans up after you (i.e. it closes open fds, frees your memory, etc.), so if your soundcard /driver is not happy with being SIGKILLed then thats a driver bug I'd report to the appropriate place. he was complaining about timing (soundcard device is actually closed about 2 s after program exits). if he closes device explicitly in program it might happen (significantly for him) sooner than when the default exit routine does it (or kernel). erik
Re: [linux-audio-dev] OSS question
Hi Jan, Mon, Jul 30, 2001, Jan Weil wrote: I really enjoy reading all your posts about GUI-Design, packaging and (sometimes ;) linux audio development. ;-) Now I have a question which probably will be answered in between. Writing a frame based (10 ms) decoder/player, how do I ensure that the (OSS) audio device is not blocked (still open) when my application is killed? your frames are 10ms - but is that also true of the OSS driver? (see questions below).. In detail: At the moment I do the following: open device decode frame, play frame decode frame, play frame [...] close device When my process (I do not use threads) is killed the audio device is blocked for at least two seconds. what size (and how many) fragments are you using (and what AFMT)? 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... Do I have to setup a signal handler for SIGTERM to close the audio device properly? This shouldn't be necessary either. --- 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). You could try issuing a SNDCTL_DSP_POST (which tells the driver you're through with sending audio) - or, if that fails, a SNDCTL_DSP_RESET. If that doesn't work ... then maybe you could look at the driver and see if there's something missing from the OSS implementation. ciao, Iain.
Re: [linux-audio-dev] OSS question
I wrote: Do I have to setup a signal handler for SIGTERM to close the audio device properly? This shouldn't be necessary either. Ok a replied too quickly - it is (only) when you get SIGTERM that you have the problem? Well, in that case, you might need to put in a handler and issue the SNDCTL_DSP_POST/RESET in that ... otherwise the app will (probably) sleep on the output queue until it is empty. You should be able to see that with 'ps' if it's taking 2 seconds. ciao, Iain
Re: [linux-audio-dev] OSS question
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.
Re: [linux-audio-dev] OSS question
Iain Sandoe schrieb: I wrote: Do I have to setup a signal handler for SIGTERM to close the audio device properly? This shouldn't be necessary either. Ok a replied too quickly - it is (only) when you get SIGTERM that you have the problem? I am sorry, actually it is a SIGKILL :( But a SIGTERM makes no difference. -- Jan Weil Heinrich-Hertz-Institut für Nachrichtentechnik Berlin GmbH Dept. Image Processing - Embedded Multimedia Group Phone: +49 30 31002-876
Re: [linux-audio-dev] OSS question
Mon, Jul 30, 2001, Jan Weil wrote: 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. Hmm. Can you try it with some suitable explicit setting - the guidelines for 'driver-set-suitable' are quite loose. 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. so you have: GUI-app -- your-codec -- /dev/dsp ? that is each of the codecs that the GUI app exec()s talks to /dev/dsp and is responsible for open()-ing and close()-ing it? It might be worth looking at the /dev/dsp set-up/close-down code in one of the other codecs to see what they do, if that's the case ;-) I am not able to reconstruct this behaviour in a shell environment directly! Interesting... Iain.
