sox - package is broken

[David Stacey]

On 16/03/2014 11:43, Corinna Vinschen wrote:
> If there are always samples at the end missing, maybe there's just some
> "flush audio queue" call missing in fhandler_dev_dsp::close_audio_out?
>
> I'm just glancing at this part of the code and what makes me a bit wary
> is the call
>
>    audio_out_->stop (immediately);
>
> This is called from fhandler_dev_dsp::close, just a few lines later
> like this:
>
>    close_audio_out (exit_state != ES_NOT_EXITING);
>
> Doesn't that mean that, if the application calls exit without calling
> close implicitely, the buffer will not be flushed?  That sounds wrong to
> me.

I imagine that somewhere in the Cygwin device handing code, there is a 
generic routine that looks a bit like this:

     device->open();
     device->write(data);
     device->close();

For /dev/dsp, at the point the function close() is called, there could 
still be 1.5s of sound in the circular buffer. I see the point of the 
'immediately' flag is to differentiate between close() being called 
because all the data has been written, or because the application is 
terminating. In the former instance, we want to hear the buffered sound 
(which is somewhat ironic...), whereas when the application is 
terminating we can exit immediately and not send the remaining data to 
the sound card. You may not agree with this logic, but I believe that is 
the intention.

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, so the 
call to stop() never happens. This explains why the audio is truncated: 
stop() sends the remaining audio data to the sound card (provided 
'immediately' is false), but this routine isn't being called.

So why is 'audio_out_' null? Well, I have no answers here. It is set to 
null in two routines (fixup_after_exec() and close_audio_out()), but the 
latter is never hit and I don't think the former is the cause of the 
problem. I'm not seeing the destructor for class 'Audio_out' being 
called either. Another option could be that another 'fhandler_dev_dsp' 
instance is being created and one copied over the other, but the 
constructor for fhandler_dev_dsp is only called once, so it isn't that.

I'd rather not entertain the possibility of a some buffer overrun 
scribbling over memory, but with so many dynamically created buffers and 
the use of memcpy(), this is always a possibility.

Anyway, enough for one night.

Dave.



--
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