Re: sox - package is broken

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Dr. Alexander Kleinsorge
Hi Dave,

yes, /dev/dsp seems to be broken.
short wav-files are silent, long ones (> 2sec) are ok (hearable).

Alexander

------------------
On 26/02/2014 22:38, Dr. Alexander Kleinsorge wrote:

    1st sox problem:
    in Cygwin 1.7.28 sound is broken. (sox + play)
    I followed all hints as reply to my first post last week.

    $ play blip.wav
    blip.wav:
      File Size: 1.33k     Bit Rate: 94.4k
       Encoding: Unsigned PCM
       Channels: 1 @ 8-bit
    Samplerate: 11025Hz
    Replaygain: off
       Duration: 00:00:00.11
    In:100%  00:00:00.11 [00:00:00.00] Out:1.25k [======|======]      
Clip:0
    Done.
    ==> BUT I DONT HEAR ANYTHING, but same file works with other windows
    players (==> soundcard + driver + speaker = ok).

I've been able to reproduce this using very short wav files (less than 2
seconds in duration); if I use a longer file then it seems to work OK.
Please could you try again with a longer wav file and report how you get
on.

This may be a Cygwin problem (rather than an issue with sox itself), as
piping the wav file to /dev/dsp has the same result, i.e. short wav files
are not heard.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Corinna Vinschen-2
On Mar  9 21:37, Dr. Alexander Kleinsorge wrote:

> Hi Dave,
>
> yes, /dev/dsp seems to be broken.
> short wav-files are silent, long ones (> 2sec) are ok (hearable).
>
> Alexander
>
> ------------------
> On 26/02/2014 22:38, Dr. Alexander Kleinsorge wrote:
>
>     1st sox problem:
>     in Cygwin 1.7.28 sound is broken. (sox + play)
>     I followed all hints as reply to my first post last week.
>
>     $ play blip.wav
>     blip.wav:
>       File Size: 1.33k     Bit Rate: 94.4k
>        Encoding: Unsigned PCM
>        Channels: 1 @ 8-bit
>     Samplerate: 11025Hz
>     Replaygain: off
>        Duration: 00:00:00.11
>     In:100%  00:00:00.11 [00:00:00.00] Out:1.25k [======|======]      
> Clip:0
>     Done.
>     ==> BUT I DONT HEAR ANYTHING, but same file works with other windows
>     players (==> soundcard + driver + speaker = ok).
>
> I've been able to reproduce this using very short wav files (less than 2
> seconds in duration); if I use a longer file then it seems to work OK.
> Please could you try again with a longer wav file and report how you get
> on.
>
> This may be a Cygwin problem (rather than an issue with sox itself), as
> piping the wav file to /dev/dsp has the same result, i.e. short wav files
> are not heard.
Does anybody feel up to the task to debug this issue in the Cygwin DLL?
The DSP code is practically only in a single file called fhandler_dsp.cc.

Maybe it's something obvious for somebody knowing how this works on
Windows.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

David Stacey
On 10/03/2014 11:14, Corinna Vinschen wrote:
> Does anybody feel up to the task to debug this issue in the Cygwin DLL?
> The DSP code is practically only in a single file called fhandler_dsp.cc.

I've started looking at this, but it is at the very bottom of my
priority queue so progress might be slow. Thus far, I've determined that
the last 1.5s are missing from *all* wav files piped to /dev/dsp. If
your wav file happens to be less that 1.5s then you get nothing. This
hasn't been noticed to date because most audio files (e.g. songs)
contain an amount of silence at the end of the file to separate the tracks.

The code mentioned above maintains a circular buffer that holds 1.5s
worth of sample data, so it is probable that this buffer isn't getting
flushed properly. I've spent an evening debugging the code, but haven't
turned up anything yet. It doesn't help that the code is rather sparsely
commented.

I'll post again if I learn more.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Corinna Vinschen-2
On Mar 16 00:00, David Stacey wrote:

> On 10/03/2014 11:14, Corinna Vinschen wrote:
> >Does anybody feel up to the task to debug this issue in the Cygwin DLL?
> >The DSP code is practically only in a single file called fhandler_dsp.cc.
>
> I've started looking at this, but it is at the very bottom of my
> priority queue so progress might be slow. Thus far, I've determined
> that the last 1.5s are missing from *all* wav files piped to
> /dev/dsp. If your wav file happens to be less that 1.5s then you get
> nothing. This hasn't been noticed to date because most audio files
> (e.g. songs) contain an amount of silence at the end of the file to
> separate the tracks.
>
> The code mentioned above maintains a circular buffer that holds 1.5s
> worth of sample data, so it is probable that this buffer isn't
> getting flushed properly. I've spent an evening debugging the code,
> but haven't turned up anything yet. It doesn't help that the code is
> rather sparsely commented.
>
> I'll post again if I learn more.
Cool, many thanks for looking into this.

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.

OTOH, I don't know if that's really the case here.  I'm just musing.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
On Mon, Mar 17, 2014 at 12:42:30AM -0400, 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.

I forgot to say, BIG thanks for tracking this down far enough for me to
slap my forehead after realizing what caused the problem that you were
describing.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Dr. Alexander Kleinsorge
In reply to this post by Dr. Alexander Kleinsorge
Hi

thanks for all participants in this audio thread.
(I hope this post is auto-connected to the thread with this name - I
seldom use mailinglists. If not, sorry for that)

This weekend, I was also woundering about the way the exit/stop/close is
donw or if it can work.

But I found another issue in fhandler_dsp.cc:
"bits / 8" should be "((bits+7) / 8)" , see below.
as described in the german wikipedia-article (not in engl. one)
https://de.wikipedia.org/wiki/RIFF_WAVE#.E2.80.9EFormat.E2.80.9C-Abschnitt
this makes even more sence:
then cygwin can support 1..16 bit (which is allowed for riff/wave/pcm),
not only 8 and 16 bit.

Alexander
--------------------------
void
fhandler_dev_dsp::Audio::fillFormat (WAVEFORMATEX * format,
                                     int rate, int bits, int channels)
{
  memset (format, 0, sizeof (*format));
  format->wFormatTag = WAVE_FORMAT_PCM;
  format->wBitsPerSample = bits;
  format->nChannels = channels;
  format->nSamplesPerSec = rate;
  format->nAvgBytesPerSec = format->nSamplesPerSec * format->nChannels
    * ((bits+7) / 8);
  format->nBlockAlign = format->nChannels * ((bits+7) / 8);
}

// calculate a good block size
unsigned
fhandler_dev_dsp::Audio::blockSize (int rate, int bits, int channels)
{
  unsigned blockSize;
  blockSize = (((bits+7) / 8) * channels * rate) / 8; // approx 125ms per
block
  // round up to multiple of 64
  blockSize +=  0x3f;
  blockSize &= ~0x3f;
  return blockSize;
}



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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
On Mon, Mar 17, 2014 at 08:59:26AM +0100, Dr. Alexander Kleinsorge wrote:
>thanks for all participants in this audio thread.
>(I hope this post is auto-connected to the thread with this name - I
>seldom use mailinglists. If not, sorry for that)
>
>This weekend, I was also woundering about the way the exit/stop/close is
>donw or if it can work.

I don't know if you got this but hopefully you understand that the
problem is fixed by the latest Cygwin snapshot:

http://cygwin.com/snapshots/

>But I found another issue in fhandler_dsp.cc:
>"bits / 8" should be "((bits+7) / 8)" , see below.
>as described in the german wikipedia-article (not in engl. one)
>https://de.wikipedia.org/wiki/RIFF_WAVE#.E2.80.9EFormat.E2.80.9C-Abschnitt
>this makes even more sence:
>then cygwin can support 1..16 bit (which is allowed for riff/wave/pcm),
>not only 8 and 16 bit.

If you have a patch, please send it to cygwin-patches along with a
ChangeLog.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

David Stacey
In reply to this post by Christopher Faylor-8
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
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

But there seemed to be something inexplicably wrong with the 32-bit
snapshot.  The cygwin dll was incorrectly built.  I don't know how
I could have done that but the new snapshot seems to work better.
The old snapshot didn't work for me at all even though my locally
built non-snapshot builds worked fine.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

David Stacey
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!

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
On Tue, Mar 18, 2014 at 03:32:18PM -0400, Christopher Faylor wrote:
>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 >".

Should be fixed in the current snapshot.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

PolarStorm
In reply to this post by David Stacey
David Stacey wrote
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!
Two things I can think of:

1) With "cat" the output file is created/handled by the shell, whereas "cp" is doing its own file creation. You should see what's going on by:
   strace cat ding.wav > /dev/dsp
   strace cp ding.wav /dev/dsp

2) Cat is trying to expand sparse files and perhaps it thinks of your ding.wav as containing sparse data?

Also, I would guess, that the dsp driver should handle bit streamed input differently than a block copy/dump?
Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Christopher Faylor-8
On Tue, Mar 18, 2014 at 05:49:48PM -0700, PolarStorm wrote:

>David Stacey wrote
>> 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!
>
>Two things I can think of:
>
>1) With "cat" the output file is created/handled by the shell, whereas "cp"
>is doing its own file creation. You should see what's going on by:
>   strace cat ding.wav > /dev/dsp
>   strace cp ding.wav /dev/dsp
>
>2) Cat is trying to expand sparse files and perhaps it thinks of your
>ding.wav as containing sparse data?
>
>Also, I would guess, that the dsp driver should handle bit streamed input
>differently than a block copy/dump?

Actually it was the improper passing of /dev/dsp file data to an execed
process that was the problem.

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

David Stacey
In reply to this post by Christopher Faylor-8
On 18/03/2014 23:16, Christopher Faylor wrote:
> On Tue, Mar 18, 2014 at 03:32:18PM -0400, Christopher Faylor wrote:
>> Ok.  I see a SEGV with "cat >".  Investigating.
> Should be fixed in the current snapshot.

Thank you for taking another look at this. I've tried with the latest
snapshot, dated 2014-03-19. This behaves as follows:

     cp ding.wav /dev/dsp

The above command works fine; all of the audio file is heard.

     cat ding.wav > /dev/dsp

The segmentation fault is fixed - thanks. The sound is heard, but the
last 1.5s are truncated. If the wav file is less than 1.5s long then no
sound is produced.

     AUDIODRIVER=ao play ding.wav

This is playing the audio through sox, which is where this whole thread
started. No sound at all, and no output to the console to indicate that
sox is attempting to play the file. The command exits (with return code
0) after a couple of seconds (approximately), irrespective of the
duration of the wav file supplied. Cranking up the verbosity with 'play
-V6' doesn't offer any assistance.

Reverting to cygwin-1.7.28-2, all of the above commands function
identically: the sound is heard but the last 1.5s are omitted, and no
sound is produced if the wav file is less than 1.5s in duration.

Sadly, I'm too busy with other matters to give this any real attention
right now. However, if we still haven't got to the bottom of this then
I'll have a dive into the code early next week.

Cheers,

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

Reply | Threaded
Open this post in threaded view
|

Re: sox - package is broken

Yaakov (Cygwin/X)
On 2014-03-19 15:14, David Stacey wrote:

>      AUDIODRIVER=ao play ding.wav
>
> This is playing the audio through sox, which is where this whole thread
> started. No sound at all, and no output to the console to indicate that
> sox is attempting to play the file. The command exits (with return code
> 0) after a couple of seconds (approximately), irrespective of the
> duration of the wav file supplied. Cranking up the verbosity with 'play
> -V6' doesn't offer any assistance.
>
> Reverting to cygwin-1.7.28-2, all of the above commands function
> identically: the sound is heard but the last 1.5s are omitted, and no
> sound is produced if the wav file is less than 1.5s in duration.
>
> Sadly, I'm too busy with other matters to give this any real attention
> right now. However, if we still haven't got to the bottom of this then
> I'll have a dive into the code early next week.

Could you do the following:

echo "debug" >> $HOME/.libao

And, for the sake of your testing, verify that the oss driver is being used.


Yaakov


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

12