Description of problem: Using an 'out of the box' nasd configuration, when I attempt to play a .wav file using auplay, only the first few milliseconds of the sample are played, and the client stalls. On interrrupting the client with CTRL/C I can try again and get the same behaviour. If I try to run another client while the first is stalled, that one stalls and produces no sound. Terminating the nasd server causes the clients to exit. If I run nasd under strace, nasd behaves as expected, and plays sounds to completion. Version-Release number of selected component (if applicable): nas-1.9-2.fc7 strace-4.5.15-1.fc7 How reproducible: Completely. Steps to Reproduce: FAILING CASE 1. service nasd start 2. auplay <some sample>.wav 3. Note that only a few milliseconds of sound are output 4. Note that the client stalls 5a. CTRL/C will terminate the client 5b. Alternatively, shutting down the server will cause the client to exit WORKAROUND/DIAGNOSTIC: 1. service nasd start 2. Identify the pid of the nasd process 3. strace -p<pid> 4. auplay <some sample>.wav 5. The sound plays as expected, to completion, and auplay exits Actual results: If nasd is not run under strace, it stalls after producing a small amount of sound. The client stalls too. Expected results: The entire sample should be played, and the client should exit once that has happened. Running a program under strace should not affect its operation. Additional info: I am running on a Dell Inspiron 6000 laptop and will attach some debug and strace logs, along with my scsconfig.log and nasd.conf
Created attachment 157862 [details] Sound config log
Created attachment 157863 [details] nasd configuration
Created attachment 157865 [details] nasd debug output, annotated to show points at which stalls happen
Created attachment 157866 [details] strace log of running nasd (which playing the sample correctly)
Created attachment 157867 [details] strace log of nasd with debug turned on too (played sample correctly)
Created attachment 157868 [details] strace of auplay when it stalls
Created attachment 157869 [details] strace of auplay running to completion (i.e. when nasd is under strace)
So please set the next time the correct attachment type!!! I have send the report to the developer of nasd.
I have the first answer from the developers. They say, that more infos are needed. Regarding the bug report: Since nasd uses OSS the contents of /proc/asound/oss/devices and /proc/asound/oss/sndstat are important as well. And using a high debug value (e.g. 99) in nasd.conf might be useful as well.
Next information from the developers. Interesting... A couple of questions: - does this happen with _any_ wav file? - If you start the client, wait for it to stall, and _then_ strace nasd does it recover? strace can effect the behavior of a running application if what you are seeing is a race condition of some sort. Adding an osLogMsg() call to intervalProc() might provide a clue. If intervalProc is only called once, then there is a signal problem of some sort.
This happens with any wav file. If I start the client, wait for stall and then strace, nasd does NOT recover. The only way I've gotten output to complete is by having strace attached to nasd before I run the client. I will attach the files requested from /proc/asound/oss
Created attachment 160244 [details] /proc/asound/oss/devices
Created attachment 160245 [details] /proc/asound/oss/sndstat
At the mailing list for nas it sound's like an kernel problem, but I have forward your files.
So now they have send an test patch. So please test the last devel version 1.9-4.
The developers have release an new test version 1.9a. So please test it.
nas-1.9a-3.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
I've just tested nas-1.9-4.fc8 with kernel-2.6.23.1-10.fc7 and this combination works fine, thanks.
nas-1.9a-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.