Subject: [ecasound] warning about system freezes (solved!)
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Tue Oct 09 2001 - 17:44:42 EEST
The system-freeze I posted about yesterday, turned out to be a problem in
ecasound's handling of -z:nointbuf. SCHED_FIFO and root-priviledges made
the problem worse, but were not the cause). Here's more detailed
information I posted to alsa-devel (bug was especially bad with ALSA's
---------- Forwarded message ----------
Date: Tue, 9 Oct 2001 17:40:22 +0300 (EEST)
From: Kai Vehmanen <k_AT_eca.cx>
Subject: bug/feature in OSS-emulation (0.9b8)
You have /dev/dsp opened for playback. Then:
int enable_bits = ~PCM_ENABLE_OUTPUT; /* disables playback */
ioctl(audio_fd, SNDCTL_DSP_SETTRIGGER, &enable_bits) == -1)
... next you start writing data to the device, but forget to ever issue
the actual trigger call (ie.
int enable_bits = PCM_ENABLE_OUTPUT;
ioctl(audio_fd, SNDCTL_DSP_SETTRIGGER, &enable_bits);
). Now this causes a more-or-less complete system-freeze (SMP, user
priviledges). The latest ecasound development version (2.1dev0) failed to
ever start the audio device and thus triggered this bug. It took quite a
while to trace down the problem. Finally S.Massy was able to pinpoint the
problem to oss-emulation, and problem was resolved.
Of course, this is really an application side problem (fixed in ecasound
2.1dev1 btw), but it might make sense to add a safety-bealt to the
oss-emulation. OSS/comm drivers survived the buggy ecasound. Also ALSA's
native pcm-interface survived (SND_PCM_START_EXPLICIT set, after buffer
became full without an snd_pcm_start(), snd_pcm_writei() returned an
If nothing else, let this be stored to alsa-devel archives just in cases
the same bug bites someone else.
-- http://www.eca.cx Audio software for Linux!
-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Oct 09 2001 - 17:42:02 EEST