All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: "Kristofer T. Karas" <ktk@bigfoot.com>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: [ALSA BUG] VIA 82xx broken by 0.9.0rc7 patch
Date: Thu, 27 Mar 2003 12:04:07 +0100	[thread overview]
Message-ID: <s5hk7elnk9k.wl@alsa2.suse.de> (raw)
In-Reply-To: <1048713467.12394.29.camel@pinhead>

At 26 Mar 2003 16:17:46 -0500,
Kristofer T. Karas <ktk@bigfoot.com> wrote:
> 
> On Tue, 2003-03-25 at 06:58, Takashi Iwai wrote:
> > could you try the attached patch?  it might solve the problem if you
> > mentioned about OSS applications.
> 
> Hi Takashi,
> 
> The patch made no obvious difference (tried it on 0.9.2).
> 
> > except for such a hidden bug, the difference between 0.9.0rc6 and rc7
> > is the use of the DSX channels as the first pcm device.  if the above
> > patch doesn't fix, please try to use hw:0,1 (for alsa native) or
> > /dev/adsp (for oss) as the sound device.
> 
> Tried, and the results are indeed interesting.  FWIW, I used Sarah
> Brightman's "Eden" as my reference sample, as it has some extended notes
> that let you pick up aberrations.  I used 'play' (sox) and 'madplay' to
> reproduce via OSS, and 'aplay' for ALSA native.
> 
> 0.9.0rc6 was my reference driver, to which I attribute a "perfect" score
> (though the S/N ratio is admitedly poor due to background noise on the
> motherboard in combination with poor shielding).  No difference in
> reproduction regardless of output device or client program.
> 
> 0.9.2, /dev/dsp, 'play': Output chopped/clipped irregularly and at high
> speed, lots of artifacts.
> 
> 0.9.2, ALSA/aplay: Nearly identical to above.  Subjective feel is that
> artifacts/clipping/distortions occur at a slightly higher rate (rate
> conversion?).
> 
> 0.9.2, /dev/dsp, 'madplay': As with 'play' and /dev/dsp, but seems to be
> passed though a low-pass filter with a cutoff of several hundred Hz.

hmm, then apparently the DSX channel cannot be used properly on your
chip model.  do you get the kernel debug messages?

just to be sure: please prepare the WAV files (16bit 2ch) with
different sample rates (44100 and 48000 would be enough).
compile the driver with POINTER_DEBUG enabled (around line 63),
install it, and and play the samples above via aplay -Dhw:0.
then check any kernel debug messages.


> 0.9.2, /dev/adsp, 'play' and/or 'madplay': Nearly perfect output.  The
> test sample was effectively identical to that under 0.9.0rc6 until the
> final 20 seconds of the music sample, when some clipping occurred. 
> Repeated the A/B comparison several times, and the clipping (though soft
> and unobtrusive) was specific to 0.9.2 only.  Subjectively, I thought I
> heard an accentuation of the high frequencies under 0.9.2 not heard
> under 0.9.0rc6 (a particular sharpness to the sung "S" sound), but am
> not positive; the difference was quite minor if there was one.

do you see any kernel messages such as "invalid via82xx_cur_ptr"?
also, please try the driver with POINTER_DEBUG enabled and check the
kernel messages.
the only obvious difference from 0.9.0rc6 is the check of the pointer
callback, and if it's the cause, it should put any debug messages.

> 
> 0.9.0, hw:0,1: Same as for 0.9.0 /dev/adsp; nearly perfect output again,
> soft clipping at tail end of sample, etc.
> 
> > if the second pcm device works, then your chip model doesn't support
> > DSX channels well.  maybe it's better to put the module option to
> > specify the chip model explicitly...
> 
> I'm surprised that 0.9.0rc6 would correctly identify the specific
> hardware but not 0.9.0.  The aberations made by 0.9.2 are the same as
> those made by 0.9.0rc1 or 0.9.0betaN.  (Weenie: Even after a short
> perusal of the module init code, it wasn't obvious what I would pass in
> to specify the chipset, or exactly which chipset.)

no, the 0.9.2 driver detects the exact chip model but it assumes that
your chip supports DSX channels, which looks incorrect.
please show the entry of /proc/asound/cards.  it includes the revision
number.


thanks,

Takashi


-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en

      parent reply	other threads:[~2003-03-27 11:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1048520403.18362.31.camel@pinhead>
2003-03-25 11:58 ` [ALSA BUG] VIA 82xx broken by 0.9.0rc7 patch Takashi Iwai
     [not found]   ` <1048713467.12394.29.camel@pinhead>
2003-03-27 11:04     ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hk7elnk9k.wl@alsa2.suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=ktk@bigfoot.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.