From: Ron Cococcia <ron.cococcia@request.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: intel8x0 dual codec issue
Date: Thu, 10 Feb 2005 14:16:12 -0500 [thread overview]
Message-ID: <420BB2FC.6070502@request.com> (raw)
In-Reply-To: <s5h8y5w1g2b.wl@alsa2.suse.de>
I had been looking through that block of code, and had made some of my
own "tweaks". What I did was make "reg_ok" an array (size 4, all
initialized to 0). I used the codec index (cidx) to index into that
array. The idea is that there would be a reg_ok for each codec, instead
of just 1 for all codecs. This correctly set the output on all codecs
after making the change.
Unfortunately, I was still noticing some audio distortions on the
secondary codec. Originally, some tones would sound "tinny". After the
change, the tinny sound went away, but I could hear distinct "clicks" in
the audio. What causes this is unknown to me, but I thought it might be
some kind of problem where both codecs are producing some information
(maybe interrupts) and causing some weirdness with loading the data. If
I knew more about what was going on I would have looked into this more,
but I am still just an novice driver "tweaker".
On a hunch, I figured that if the primary codec was doing something
weird, I might need to make it "forget" about the primary codec. I went
into intel8x0.c, and started to take a look, and was able to add a quick
test hack. If the number of codecs detected in snd_intel8x0_mixer was
2, set it to 1. In snd_intel8x0_codec_{read/write/read_test}, it would
add 1 to ac97->num, so it would access the secondary codecs values and
skip the primary.
After compiling and installing, alsamixer only knows of 1 codec
(CS4299), and the audio playback appears to be greatly improved with no
clicks or tinny sounds.
For now, I will be leaving my hack in, unless there is a better fix
available. A few hours after getting it working, I managed to hose my
development setup anyway, so it will be a little while before I can play
around again.
Thanks,
Ron
Takashi Iwai wrote:
> At Mon, 07 Feb 2005 23:43:39 -0500,
> Ron Cococcia wrote:
>
>>Hello,
>>
>>I'm having a little trouble with a dual codec setup that I am using.
>>The motherboard has an Intel 815 chip (82801BAICH2). The motherboard
>>has the primary (00) codec, which is an AD1885. A secondary (01) codec
>>has been added over a CNR connector. This one is a CS4299. The
>>secondary codec uses the timing values generated by the primary.
>>
>>I had been hearing some distortion in the audio. It was quite
>>noticeable. Using a wav file of sine waves that has different
>>frequencies (440, 880, 1760, 3520) at 44100Hz, I could see that there
>>was some jitter on a scope. As the frequencies went up, it got worse.
>>I then created another test file with the same frequencies, but sampled
>>at 48000Hz. Playback of that audio was extremely clean on the scope.
>>
>>Looking into it more, I noticed that the PCM front DAC (ac97#1-1) was
>>not adjusting itself to the appropriate frequency. The DAC on the
>>primary codec was switching between 44100Hz and 48000Hz when I played
>>the different samples.
>>
>>I'd like to have the secondary codec reflect the output rate that is
>>being sent to it. How might I get it to do this? Is it a bug (should
>>the codec front DAC on the secondary codec reflect the appropriate
>>frequency?), or how is it intended to work?
>
>
> I guess it's a bug. Could you try the attached patch?
>
>
> Takashi
>
>
> ------------------------------------------------------------------------
>
> Index: alsa-kernel/pci/ac97/ac97_pcm.c
> ===================================================================
> RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/ac97/ac97_pcm.c,v
> retrieving revision 1.19
> diff -u -r1.19 ac97_pcm.c
> --- alsa-kernel/pci/ac97/ac97_pcm.c 27 Dec 2004 13:19:32 -0000 1.19
> +++ alsa-kernel/pci/ac97/ac97_pcm.c 10 Feb 2005 17:19:45 -0000
> @@ -602,8 +602,10 @@
> snd_printk(KERN_ERR "invalid AC97 slot %i?\n", i);
> continue;
> }
> +#if 0
> if (reg_ok & (1 << (reg - AC97_PCM_FRONT_DAC_RATE)))
> continue;
> +#endif
> //printk(KERN_DEBUG "setting ac97 reg 0x%x to rate %d\n", reg, rate);
> err = snd_ac97_set_rate(pcm->r[r].codec[cidx], reg, rate);
> if (err < 0)
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
next prev parent reply other threads:[~2005-02-10 19:16 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-08 4:43 intel8x0 dual codec issue Ron Cococcia
2005-02-10 17:27 ` Takashi Iwai
2005-02-10 19:16 ` Ron Cococcia [this message]
2005-02-11 10:19 ` Takashi Iwai
2005-02-11 16:30 ` Ron Cococcia
2005-02-14 15:05 ` Takashi Iwai
2005-02-24 22:10 ` Ron Cococcia
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=420BB2FC.6070502@request.com \
--to=ron.cococcia@request.com \
--cc=alsa-devel@lists.sourceforge.net \
--cc=tiwai@suse.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox