X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	q=dns; s=default; b=AjbL8RE4p+tnXR1CSMYoQsL/YzIma5tbyVmrlDxIcg0
	nwkpfxundxJVvWkM0NtrQXa9KEIgqXJRIU4+kcV5MycT+TnDgrWFg0c6IUd3W5l2
	JVjZNFOQC4LD+DiRU0RgA37d7BzEwJ3JjSFtMoWHQoBju+/VoTGH4iz/fGfGjkH4
	=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	s=default; bh=G+FMWoRQD4cMNrXzT/+3bNK83/I=; b=XA7d0qck5RFSrS7Dv
	GtvmjwTTZuO1TewL2XsbSa6v+ZDrm9vl2tbboAFbjhqxKQ91aH6l3Gh69svPdCm+
	4wnN5VqOK5NbNTl22uyhym32DSz6PH0FV3KLstYEOmcS8A8wMjAs3JN/RxawgMG4
	dlD9W5RIkrJZgc9poeTv4wPAXg=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=0.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_COUK,SPF_PASS autolearn=no version=3.3.2
X-HELO:	out.ipsmtp3nec.opaltelecom.net
X-IronPort-Anti-Spam-Filtered:	true
X-IronPort-Anti-Spam-Result:	AjkDADMmJlNPRtZh/2dsb2JhbAANS4ceu3GDBwMCgSyDGQEBAQQjBBFAEQsYAgIFFgsCAgkDAgECAUUTCAEBtzZ2oX8XgSmNRhaCWYFJAQOUWwWZQg
X-IPAS-Result:	AjkDADMmJlNPRtZh/2dsb2JhbAANS4ceu3GDBwMCgSyDGQEBAQQjBBFAEQsYAgIFFgsCAgkDAgECAUUTCAEBtzZ2oX8XgSmNRhaCWYFJAQOUWwWZQg
Message-ID:	<5326276F.1050103@tiscali.co.uk>
Date:	Sun, 16 Mar 2014 22:36:31 +0000
From:	David Stacey <drstacey AT tiscali DOT co DOT uk>
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: sox - package is broken
References:	<b0f9be09644f90eadb0a5d479b74ad56 DOT squirrel AT www DOT physik DOT tu-berlin DOT de> <20140310111427 DOT GE2828 AT calimero DOT vinschen DOT de> <5324E98D DOT 2090806 AT tiscali DOT co DOT uk> <20140316114332 DOT GB400 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20140316114332.GB400@calimero.vinschen.de>
X-IsSubscribed:	yes

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

- Raw text -