From owner-freebsd-multimedia Thu Jul 31 18:56:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA16900 for multimedia-outgoing; Thu, 31 Jul 1997 18:56:32 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id SAA16854 for ; Thu, 31 Jul 1997 18:55:42 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 31 Jul 1997 21:55:04 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA23678; Thu, 31 Jul 97 21:55:01 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id VAA08047; Thu, 31 Jul 1997 21:52:33 -0400 Message-Id: <19970731215232.36119@ct.picker.com> Date: Thu, 31 Jul 1997 21:52:32 -0400 From: Randall Hopper To: multimedia@freebsd.org Cc: Amancio Hasty Subject: [snddrv] guspnp14 testing results References: <19970729194122.25341@ct.picker.com> <199707310331.UAA01018@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707310331.UAA01018@rah.star-gate.com>; from Amancio Hasty on Wed, Jul 30, 1997 at 08:31:53PM -0700 Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk |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?