Re: Patch 20040321 for audio recording with /dev/dsp (indented), test issues

[Nicholas Wourms]

cgf wrote:

On Tue, Mar 23, 2004 at 12:09:33PM +0100, Corinna Vinschen wrote:

Chris, do you have a personally approved set of indent options which
give a useful result, perhaps?


No, I don't use indent very often.

Gdb has an indent script, though.  I've attached it to this message.  I
can't confirm or deny if it works well for c++, though.
Indent is really for C code only, so it totally botches C++ 
constructors, destructors, classes, templates, virtuals, and just about 
anything else not C (especially templates).  I was not aware that GNU 
had any style standards for C++-specific code.  But then again, I find 
their standards to be boring, so I really haven't read them.  Like 
Corinna, I usually run it through ident using -gnu and fix it up 
afterwards.  Sometimes, if you pass private, public, class names and 
method names using -Tname1 -Tname2 it won't totally screw up.  It 
still will treat labels (both C++ public/private and C goto) as if they 
were part of a switch statement, indenting them.  Also, you'll want to 
use -T to declare any non-basic typedefs, such as off_t, clock_t, or 
size_t.  If you don't, it will indent a pointer declaration as if it 
were a multiplication statement.  Anyhow, IIRC, I believe these extra 
flags can be stored in a local dot file in the directory of the source 
file being indented (.indent.pro?).

Cheers,
Nicholas

RE: Patch 20040321 for audio recording with /dev/dsp (indented), test issues

[Gerd Spalink]

Please find my answers inserted below.

On Monday, March 22, 2004 6:06 PM, Corinna Vinschen [SMTP:[EMAIL PROTECTED] wrote:
 On Mar 21 22:55, Gerd Spalink wrote:
  There were no comments about the test program I sent. Do you want to
  put it or something like it into the repository?
 
 I used your test application after applying the patch locally.
 
 Some of the tests don't emit a sound, is that correct?
 
   $ ./devdsp
   Set bits=16 stereo=1 rate=44100 sync=0x
   Buffer size=22080
   Formats=0018
 
   [Beeping starts here]
 
These are audio playback tests for various sampling rates

   Set bits= 8 stereo=0 rate=44100 sync=0x
   Set bits=16 stereo=0 rate=44100 sync=0x
   Set bits= 8 stereo=1 rate=44100 sync=0x
   Set bits=16 stereo=1 rate=44100 sync=0x
   Set bits= 8 stereo=0 rate=22050 sync=0x
   Set bits=16 stereo=0 rate=22050 sync=0x
   Set bits= 8 stereo=1 rate=22050 sync=0x
   Set bits=16 stereo=1 rate=22050 sync=0x
   Set bits= 8 stereo=0 rate= 8000 sync=0x
   Set bits=16 stereo=0 rate= 8000 sync=0x
   Set bits= 8 stereo=1 rate= 8000 sync=0x
   Set bits=16 stereo=1 rate= 8000 sync=0x
 
   [From now on, the tests make *no* sound]
 
This is correct, since the following are the tests for audio
recording. They record whatever is at your currently
selected analog audio source (could be MIC, LINE, CD),
and silently ignore the recorded sound data.

   Set bits= 8 stereo=0 rate=44100 sync=0x
   Set bits=16 stereo=0 rate=44100 sync=0x
   Set bits= 8 stereo=1 rate=44100 sync=0x
   Set bits=16 stereo=1 rate=44100 sync=0x
   Set bits= 8 stereo=0 rate=22050 sync=0x
   Set bits=16 stereo=0 rate=22050 sync=0x
   Set bits= 8 stereo=1 rate=22050 sync=0x
   Set bits=16 stereo=1 rate=22050 sync=0x
   Set bits= 8 stereo=0 rate= 8000 sync=0x
   Set bits=16 stereo=0 rate= 8000 sync=0x
   Set bits= 8 stereo=1 rate= 8000 sync=0x
   Set bits=16 stereo=1 rate= 8000 sync=0x
   Set bits=16 stereo=1 rate=44100 sync=0x
 
   [And now the beeping starts again]
 
   forked, child PID=1812 parent records
   [...]
 
 I'm not quite sure about putting the testcase into the testsuite.
 It's a good idea in general, but, well, I'm wondering if you'd
 like to use the libltp framework for the testresults, perhaps?

I agree. The printed results will be unambiguous, so no more
wondering about correctness or not.
 
 Btw., what happens if somebody without sound card and sound driver
 starts the test?  Did you check that?

I did not check it. I guess that the calls into the /dev/dsp device
will fail at some point, resulting in a premature exit of the test
with a non-zero exit code, indicating failure to the test suite.

 
 Other than that your latest patch looks pretty good, though there
 are still a few formatting issues, e. g.
 
   if (foo 
   bar
 
 should be
 
   if (foo
bar)
 
 in GNU coding style.  However, I'll apply it after 1.5.10 is out
 and run indent on it, as soon as you can explain to me (as a sound
 programming anaphylactic) why I can't hear a sound in the above
 tests.

Actually, I tried indent as distributed with cygwin, and it apparently
did strange things to the C++ code, e.g. delete[] foo; became delete[]foo;
I found also that the code in the class declarations looked worse than before.
Do you have a special set of options that work better than the default for C++?

 
 Since that code makes you to the one and only audio code maintainer
 for Cygwin, I'm wondering if you're also interested in maintaining
 some audio application which makes use of this new Cygwin code,
 as part of the Cygwin net distribution...

As far as my limited spare time allows...
Which applications were you thinking of?
 
 Thanks,
 Corinna
 
 -- 
 Corinna Vinschen  Please, send mails regarding Cygwin to
 Cygwin Developermailto:[EMAIL PROTECTED]
 Red Hat, Inc.