On Tue, Mar 18, 2014 at 07:29:14PM +0000, David Stacey wrote: >On 18/03/2014 17:53, Christopher Faylor wrote: >> On Mon, Mar 17, 2014 at 11:53:10PM +0000, David Stacey wrote: >>> On 17/03/2014 04:42, Christopher Faylor wrote: >>>> On Sun, Mar 16, 2014 at 10:28:29PM -0400, Christopher Faylor wrote: >>>>> On Sun, Mar 16, 2014 at 09:57:36PM -0400, Christopher Faylor wrote: >>>>>> On Sun, Mar 16, 2014 at 10:36:31PM +0000, David Stacey wrote: >>>>>>> The issue I have is that close_audio_out() isn't working as you'd >>>>>>> expect: for some reason, the 'audio_out_' member pointer is null >>>>>> This was because all of the I/O operations were ignoring the archetype >>>>>> for the device. So, this is likely an old bug. >>>>>> >>>>>> So, good news/bad news. Good news: I checked in a fix which causes the >>>>>> missing >>>>>> 1.5 seconds to be played. Bad news: The process now hangs in >>>>>> waveOutClose() >>>>>> in fhandler_dev_dsp::Audio_out::stop. There seem to be a few threads >>>>>> hanging >>>>>> around waiting for something so obviously something isn't cleaning up >>>>>> right >>>>>> in the audio code. >>>>> Nope. Wrong theory. I know what's causing this but I don't yet know how >>>>> to >>>>> fix it. >>>> This should all be fixed in the upcoming snapshot. >>> Thank you for looking at this. I've tried the 32-bit snapshot dated >>> '2014-03-17', but whenever I pipe a wav file to /dev/dsp I get a >>> segmentation fault. The error is produced immediately, and no sound is >>> heard. I've tried wav files both longer and shorter than 1.5s. >> What does "pipe a wav file" mean? I was testing this by doing: >> >> cp h.wav /dev/dsp > >I was testing with > > cat ding.wav > /dev/dsp > >This gives a segmentation fault with the latest (2014-03-18) snapshot; >no sound is heard However, if I repeat your test: > > cp ding.wav /dev/dsp > >Then that works and the ding dings. Which confuses me greatly - I've >been using *nix for nearly 20 years, and I honestly would have said that >the two lines above were synonymous - they're obviously not!
Ok. I see a SEGV with "cat >". Investigating. FWIW, they are not the same. There's lots of dup'ing going on under the hood with "cat >". cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple