Re: sox - package is broken

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

Re: sox - package is broken

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

Re: sox - package is broken

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[David Stacey]

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

Re: sox - package is broken

[Christopher Faylor]

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

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[PolarStorm]

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? 



--
View this message in context: http://cygwin.1069669.n5.nabble.com/Re-sox-package-is-broken-tp106970p107200.html
Sent from the Cygwin list mailing list archive at Nabble.com.

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[David Stacey]

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

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

Re: sox - package is broken

[Christopher Faylor]

On Wed, Mar 19, 2014 at 08:14:16PM +0000, David Stacey wrote:
>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.

That should be fixed in the latest snapshot.

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

I get a usage message from sox if I attempt the above:

play FAIL formats: no handler for given file type 'ao'

Without the AUDIODRIVER, it works as expected.

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

Re: sox - package is broken

[Yaakov (Cygwin/X)]

On 2014-03-19 19:39, Christopher Faylor wrote:
> On Wed, Mar 19, 2014 at 08:14:16PM +0000, 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.
>
> I get a usage message from sox if I attempt the above:
>
> play FAIL formats: no handler for given file type 'ao'

The sox-fmt-ao package is required for AUDIODRIVER=ao.


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

Re: sox - package is broken

[Christopher Faylor]

On Wed, Mar 19, 2014 at 08:46:51PM -0500, Yaakov (Cygwin/X) wrote:
>On 2014-03-19 19:39, Christopher Faylor wrote:
>> On Wed, Mar 19, 2014 at 08:14:16PM +0000, 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.
>>
>> I get a usage message from sox if I attempt the above:
>>
>> play FAIL formats: no handler for given file type 'ao'
>
>The sox-fmt-ao package is required for AUDIODRIVER=ao.

Thanks.  This will be fixed in the next 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

Re: sox - package is broken

[David Stacey]

On 20/03/2014 02:26, Christopher Faylor wrote:
> On Wed, Mar 19, 2014 at 08:46:51PM -0500, Yaakov (Cygwin/X) wrote:
>> On 2014-03-19 19:39, Christopher Faylor wrote:
>>> On Wed, Mar 19, 2014 at 08:14:16PM +0000, 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.
>>> I get a usage message from sox if I attempt the above:
>>>
>>> play FAIL formats: no handler for given file type 'ao'
>> The sox-fmt-ao package is required for AUDIODRIVER=ao.
> Thanks.  This will be fixed in the next snapshot.

I have tried the snapshot dated 2014-03-20, and I can confirm that all 
of the following commands work perfectly:

     cp ding.wav /dev/dsp
     cat ding.wav > /dev/dsp
     AUDIODRIVER=ao play ding.wav

Many thanks for all your work in fixing these.

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

Re: sox - package is broken

[Christopher Faylor]

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

Re: sox - package is broken

[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

Re: sox - package is broken

[David Stacey]

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

sox - package is broken

[Dr. Alexander Kleinsorge]

Hi Cygwin Team,

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

2nd sox problem:
setup for sox* packages seems to be broken too (download incomplete msg).
It is the first time I have problems installing cygwin-packages.
It is server independent (ftp:*.de).

-------------------------------
Possible solution: Why not using sounder.exe (freeware) which works
without any setup and can play RIFF-WAVE-PCM and RIFF-WAVE-MP3 from
command line.
Together with aplay.exe (my c-code to emulate linux aplay player (using
sounder internally).


Install this way:
--
wget http://www.physik.tu-berlin.de/~aleks/aplay.c
wget http://www.elifulkerson.com/projects/downloads/sounder2013/sounder.exe
gcc -O1 -o aplay.exe aplay.c
cp aplay.exe sounder.exe /usr/bin/
--


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

RE: sox - package is broken

[Buchbinder, Barry (NIH/NIAID) [E]]

David Stacey sent the following at Monday, February 24, 2014 3:27 PM
>On 24/02/2014 17:27, Dr. Alexander Kleinsorge wrote:
>> But after (export AUDIODRIVER=ao ; play ding.wav)
>> I see messages indicating successfull playing and application is waiting
>> the time the wav-file takes,
>> but no sound. But I can hear the sound using VLC-win32 or WindowsMediaPlayer.

The following works for me.

/bin/cp path/file.wav /dev/dsp
    or
cat path/file.wav > /dev/dsp

See http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.


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

Re: sox - package is broken

[Yaakov (Cygwin/X)]

On 2014-02-24 11:27, Dr. Alexander Kleinsorge wrote:
> But after (export AUDIODRIVER=ao ; play ding.wav)
> I see messages indicating successfull playing and application is waiting
> the time the wav-file takes, but no sound.

WFM. Does AUDIODRIVER=oss work?

If you're still having problems, then please follow the directions here:

http://cygwin.com/problems.html


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

Re: sox - package is broken

[David Stacey]

On 24/02/2014 17:27, Dr. Alexander Kleinsorge wrote:
> But after (export AUDIODRIVER=ao ; play ding.wav)
> I see messages indicating successfull playing and application is waiting
> the time the wav-file takes,
> but no sound. But I can hear the sound using VLC-win32 or WindowsMediaPlayer.

You could try using the pulseaudio driver, but this requires a little 
setting up. Firstly, make sure you have speakers and a microphone 
connected to your PC (pulseaudio will not be able to function unless you 
have input and output devices connected). Then set up some permissions:

     chown -R "username" "/home/username"
     chmod 755 "/home/username"
     rm -rf /tmp/pulse* ~/.pulse-cookie ~/.config/pulse

where 'username' is your user name. You will only have to do the above 
once. Then play your sound file:

     export AUDIODRIVER=pulseaudio
     play ding.wav

And prepare to be dinged unto. When you've finished playing sounds, kill 
the pulseaudio server:

     pulseaudio -k

This assumes that 'play' will start the pulseaudio server for you. If 
you get errors from the 'play' command, try starting the pulseaudio 
server manually:

     start-pulseaudio-x11

I know very little about pulseaudio, but the above works for me. If you 
still don't have any joy then you'll have to fall back to your VB wav 
player.

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

sox - package is broken

[Dr. Alexander Kleinsorge]

Hi Cygwin Team

As reply for my Post: aplay (audio) support for cygwin - solution
I got the hint to: " Install the Cygwin packages 'sox' and 'sox-fmt-*' "

But installation of these sox packages is broken!
I tried it on 3 computers and i have successfull installed Cygwin many
times before.
Error Message: "Download incomplete! Try agian? Yes/No" (at 99%)
Retry does not fix it.

my 3 Windows Computer, all Cygwin 1.7.28 - 32 bit:
a) Windows XP, 32bit
b) Windows 7 - 64bit, 1 year old installation of cygwin
c) Windows 7 - 64bit, 1 week new installation of cygwin - different location

I tried different german ftp*.de servers - same problem.
Always broken at 99%. Never had this problem before!

On Computer (b) I somehow made the package install:
After some retries with different servers I got a warning of an older
setup.ini and I could install it.
But after (export AUDIODRIVER=ao ; play ding.wav)
I see messages indicating successfull playing and application is waiting
the time the wav-file takes,
but no sound. But I can hear the sound using VLC-win32 or WindowsMediaPlayer.
Of course I tried different wav files.

Thanks,
Alexander


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