Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 31 Jul 1997 21:52:32 -0400
From:      Randall Hopper <rhh@ct.picker.com>
To:        multimedia@freebsd.org
Cc:        Amancio Hasty <hasty@rah.star-gate.com>
Subject:   [snddrv] guspnp14 testing results
Message-ID:  <19970731215232.36119@ct.picker.com>
In-Reply-To: <199707310331.UAA01018@rah.star-gate.com>; from Amancio Hasty on Wed, Jul 30, 1997 at 08:31:53PM -0700
References:  <19970729194122.25341@ct.picker.com> <199707310331.UAA01018@rah.star-gate.com>

next in thread | previous in thread | raw e-mail | index | archive | help
 |I got rid of the auto dma functionality and it appears that at least
 |over here it got rid of all the clicks for *.au without sun-style
 |headers.

Just ran some tests on the latest, and I've got good news and a little bad
news.  The good news is that all three of the specific problems I reported
for guspnp11 (most stable recent release on SB16+ cards) seem to be fixed.
(see below for a recap)  Great work!

The bad news is that with this version, we've picked an ugly new bug.  From
the symptoms, I "think" it's a problem with chaining the DMA transfers
together -- there's space between them.  The symptoms are:

        - regular clicks during playback and record
        - click frequency increases in rate with sample rate
        - click becomes more noticable as sample volume increases
        - prerecorded audio w/ higher sample rate plays back slower
          and at slightly lower frequency the same audio prerecorded 
          at a lower sample rate

I see this across the board in all apps and sample formats/rates.

Re the clicking, at 44KHz 16bit stereo, it's hard to pick out with many
samples, partly because the clicking is so fast--more of a warble.  Usually
its most easily heard when the sound sample is louder or playing a pure
tone.  Much easier to hear with a slower sample rate.  Try mpg123 on this
(22Khz 16bit stereo):

     http://www.eskimo.com/~miyaguch/startrek/trekthem.mp3

The tone in the first few seconds is very pure w/ the checked-in drivers.
pnp14 has very noticable clicks.  And generally as the sample rate drops,
the clicks get a good bit more noticeable since they're farther apart (down
to around 2 per sec @ 8Khz mono).

Re the lower playback speed and frequency, I've uploaded a simple dsp test
to rah.  Untar snddrv-dsptest.tgz and run:

      cat < aud8ulaw > /dev/audio
      dsp-play -b 16 -r 44100 -c 2 < aud44s16

After hearing 2 seconds of the first, Ctrl-C it and run the second.  You'll
see what I mean.  BTW, these were both recorded with the checked-in drivers
and sound the same, barring sample quality of course, when played with that
driver rev.  You can run GO.TEST for a more progressive jump between
44k-16-2 and 8k-ulaw-1.

Re clicks during record, I recorded a raw 44khz 16-bit stereo sound-bite
with guspnp14 (via dsp-record--also in the package), flipped over to the
checked-in drivers, played it, and heard clicks.  I hear double the clicks
playing it with guspnp14, so anyway that's my evidence for this problem
relating to record as well as playback.

Hopefully this DMA bug will be easy to identify and fix since it's tied to
a very recent change.

Hope this helps.

Randy


guspnp11 problems reported:
 |2) Load pops on start/end of AU playback.   Still there.  Don't see this
 |   with the checked-in driver.
 |
 |3) Attempts to record 16-bit samples gives "Input/Output Error" now instead
 |   of the "Interrupted system call" before.  For each failure, I get one of
 |   these in my console:
 |
 |          Sound: DMA (input) timed out - IRQ/DRQ config error?
 |
 |   16-bit record works with the checked-in driver.
 |
 |4) I think Louis or you mentioned this, but I also see probe output that's
 |   a little strange.  Looks fine except for that dma 7 in there.  Could this 
 |   be related to the DMA error doing 16-bit record?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970731215232.36119>