* hda-intel/ALC260: mixer control issues
@ 2005-09-01 23:35 Jonathan Woithe
2005-09-02 10:00 ` Takashi Iwai
0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-01 23:35 UTC (permalink / raw
To: alsa-devel; +Cc: Jonathan Woithe
Hi all
I am currently trying to get ALSA working correctly on a laptop equipped
with an ALC260 hda chip (Fujitsu S7020). It seems to me that the converters
themselves are working but the mixer controls are slightly amiss. Playing
something with aplay sends something to the internal speakers, but only
if the control labelled "headphone" is turned up. No signal is sent to
the "headphone/line out" jack even if every single mixer control is
set to its maximum setting.
There is also a "PCM" control which sometimes affects the PCM output level
(but I haven't been able to work out the circumstances surrounding the
different behaviour yet). Curiously it's not mutable whereas every other
control is.
On the input side it seems that no signal gets to the ADC from the
mic/line-in jack regardless of what is set as the capture source. Data is
captured though, suggesting a mixer routing issue again. The signal which
is captured is noisy, although I haven't yet determined exactly what it
is - it's clearly unrelated to what's presented at the input jack though.
This is with ALSA as present in the 2.6.13 kernel release (making it 1.0.9
or there abouts I think). I will try the 1.0.10 release candidates since
there seems to have been some movement in the hda driver since 1.0.9, but
if anyone has other ideas I'm most interested to hear them.
Could it be a case that this laptop maps the ALC260 resources in a strange
way? If this is true, I'm guessing the first port of call would be the
port/address numbers of the controls defined in hda/patches-realtek.c.
Thanks and regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-01 23:35 hda-intel/ALC260: mixer control issues Jonathan Woithe
@ 2005-09-02 10:00 ` Takashi Iwai
2005-09-05 0:18 ` Jonathan Woithe
2005-09-05 0:29 ` hda-intel/ALC260: crackly playback and DC offset on recording Jonathan Woithe
0 siblings, 2 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-02 10:00 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Fri, 2 Sep 2005 09:05:13 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi all
>
> I am currently trying to get ALSA working correctly on a laptop equipped
> with an ALC260 hda chip (Fujitsu S7020). It seems to me that the converters
> themselves are working but the mixer controls are slightly amiss. Playing
> something with aplay sends something to the internal speakers, but only
> if the control labelled "headphone" is turned up. No signal is sent to
> the "headphone/line out" jack even if every single mixer control is
> set to its maximum setting.
Adjust "Front" mixer.
> There is also a "PCM" control which sometimes affects the PCM output level
> (but I haven't been able to work out the circumstances surrounding the
> different behaviour yet). Curiously it's not mutable whereas every other
> control is.
This is a software volume control, and no mute switch is provided.
The others are hardware mixer controls.
> On the input side it seems that no signal gets to the ADC from the
> mic/line-in jack regardless of what is set as the capture source. Data is
> captured though, suggesting a mixer routing issue again. The signal which
> is captured is noisy, although I haven't yet determined exactly what it
> is - it's clearly unrelated to what's presented at the input jack though.
Did you raise "Capture" volume and turn on "Capture" switch?
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-02 10:00 ` Takashi Iwai
@ 2005-09-05 0:18 ` Jonathan Woithe
2005-09-05 10:35 ` Takashi Iwai
2005-09-05 0:29 ` hda-intel/ALC260: crackly playback and DC offset on recording Jonathan Woithe
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-05 0:18 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > I am currently trying to get ALSA working correctly on a laptop equipped
> > with an ALC260 hda chip (Fujitsu S7020). It seems to me that the converters
> > themselves are working but the mixer controls are slightly amiss. Playing
> > something with aplay sends something to the internal speakers, but only
> > if the control labelled "headphone" is turned up. No signal is sent to
> > the "headphone/line out" jack even if every single mixer control is
> > set to its maximum setting.
> Adjust "Front" mixer.
It made no difference at all. With every control at maximum there was no
audio coming from the "line out" jack.
> > There is also a "PCM" control which sometimes affects the PCM output level
> > (but I haven't been able to work out the circumstances surrounding the
> > different behaviour yet). Curiously it's not mutable whereas every other
> > control is.
> This is a software volume control, and no mute switch is provided.
> The others are hardware mixer controls.
Having explored the ALC260 datasheet over the weekend this is now clear.
Thanks.
> > On the input side it seems that no signal gets to the ADC from the
> > mic/line-in jack regardless of what is set as the capture source. Data is
> > captured though, suggesting a mixer routing issue again. The signal which
> > is captured is noisy, although I haven't yet determined exactly what it
> > is - it's clearly unrelated to what's presented at the input jack though.
> Did you raise "Capture" volume and turn on "Capture" switch?
Yes - again there was nothing.
I had the opportunity to sit down over the weekend and work through the
issues. It turns out that this particular laptop has its sound hardware
wired up in an odd way. I was able to get the external plugs working but
had to write my own custom ALC260 initialisation verb list to do so.
To cut a long story short, the audio inputs/outputs are connected to the
following ALC260 output pins.
* Internal speaker: ALC260 "headphone" pin
* "Stereo line in jack": ALC260 "mic 1" pin
* "Stereo line out jack": ALC260 "line 1" pin (ie: NOT the "line out" pin)
* CD audio: ALC260 "CD" pin
The reason I got nothing out of the jack is clear: ALSA configures the
ALC260 "line out" pin as output and the ALC260 "line 1" as input. However,
in the case of this laptop ALC260 "line 1" is actually the output, with line
level input appearing at the ALC260 "mic 1" pin. I also found I had to
explicitly unmute selected input/output widgets since the mixer doesn't
control these.
Anyway, with this understanding I was able to get audio in and out of this
laptop. The question now is: where to from here. I'd like to get the
revised initialisation verb list into ALSA but it's not clear how this can
be done. As far as I can tell the ALC260 in this laptop identifies itself
using a generic ID; unless there is some other unique ID we can find there
won't be any way for ALSA to deduce which initialisation verb list is
required. Perhaps a new module parameter? Let me know your thoughts.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-02 10:00 ` Takashi Iwai
2005-09-05 0:18 ` Jonathan Woithe
@ 2005-09-05 0:29 ` Jonathan Woithe
2005-09-05 10:38 ` Takashi Iwai
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-05 0:29 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi all
Further tests with the hda-intel driver with the ALC260 chip in my laptop
has shown that when audio is played, seemingly random crackling occurs
in the output. This affects only playback - recorded audio is fine. It
affected aplay (native alsa), wavplay (uses /dev/dsp and thus alsa's OSS
snd-pcm-oss module) and audacity 1.2.2 (also using /dev/dsp).
I found that the following change to hda_intel.c almost fixed the problem:
--- hda_intel.c 2005-09-03 23:02:18.000000000 +0930
+++ hda_intel.c-orig 2005-08-16 05:23:07.000000000 +0930
@@ -1026,7 +1026,7 @@
azx_setup_periods(azx_dev);
azx_setup_controller(chip, azx_dev);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
- azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE);
+ azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE) + 1;
else
azx_dev->fifo_size = 0;
If this patch was applied then playing audio using aplay was clean - no hint
of the crackling was evident. However, playing through audacity (which used
the ALSA OSS emulation) was still crackly. I then tested using wavplay (which
also uses the OSS devices) and it too was still crackly. I recompiled
audacity to use portaudio v19 (thus giving audacity native ALSA support) and
was slightly surprised to hear that the crackling remained with audacity even
when using the ALSA output options. Throughout all this, the aplay output
was clean so long as the above patch had been applied.
I must admit to not knowing exactly what the fifo_size does; my attention
was drawn to it because the +1 looked odd and it was an obvious point of
difference between the record path (which was fine) and the playback path
(which crackled).
On the subject of recording, there seems to be a DC offset in the ADC which
is dependent on the level of the "capture" mixer control - the higher the
control the higher the DC offset. The offset is present even when nothing
is plugged in to the laptop. With the control at maximum the DC offset
is as much as 10% FSD; at mimimum it's around 1-2%.
Any ideas on either of these?
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-05 0:18 ` Jonathan Woithe
@ 2005-09-05 10:35 ` Takashi Iwai
2005-09-06 0:24 ` Jonathan Woithe
0 siblings, 1 reply; 29+ messages in thread
From: Takashi Iwai @ 2005-09-05 10:35 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Mon, 5 Sep 2005 09:48:00 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > I am currently trying to get ALSA working correctly on a laptop equipped
> > > with an ALC260 hda chip (Fujitsu S7020). It seems to me that the converters
> > > themselves are working but the mixer controls are slightly amiss. Playing
> > > something with aplay sends something to the internal speakers, but only
> > > if the control labelled "headphone" is turned up. No signal is sent to
> > > the "headphone/line out" jack even if every single mixer control is
> > > set to its maximum setting.
> > Adjust "Front" mixer.
>
> It made no difference at all. With every control at maximum there was no
> audio coming from the "line out" jack.
>
> > > There is also a "PCM" control which sometimes affects the PCM output level
> > > (but I haven't been able to work out the circumstances surrounding the
> > > different behaviour yet). Curiously it's not mutable whereas every other
> > > control is.
> > This is a software volume control, and no mute switch is provided.
> > The others are hardware mixer controls.
>
> Having explored the ALC260 datasheet over the weekend this is now clear.
> Thanks.
>
> > > On the input side it seems that no signal gets to the ADC from the
> > > mic/line-in jack regardless of what is set as the capture source. Data is
> > > captured though, suggesting a mixer routing issue again. The signal which
> > > is captured is noisy, although I haven't yet determined exactly what it
> > > is - it's clearly unrelated to what's presented at the input jack though.
> > Did you raise "Capture" volume and turn on "Capture" switch?
>
> Yes - again there was nothing.
>
> I had the opportunity to sit down over the weekend and work through the
> issues. It turns out that this particular laptop has its sound hardware
> wired up in an odd way. I was able to get the external plugs working but
> had to write my own custom ALC260 initialisation verb list to do so.
>
> To cut a long story short, the audio inputs/outputs are connected to the
> following ALC260 output pins.
>
> * Internal speaker: ALC260 "headphone" pin
> * "Stereo line in jack": ALC260 "mic 1" pin
> * "Stereo line out jack": ALC260 "line 1" pin (ie: NOT the "line out" pin)
> * CD audio: ALC260 "CD" pin
>
> The reason I got nothing out of the jack is clear: ALSA configures the
> ALC260 "line out" pin as output and the ALC260 "line 1" as input. However,
> in the case of this laptop ALC260 "line 1" is actually the output, with line
> level input appearing at the ALC260 "mic 1" pin. I also found I had to
> explicitly unmute selected input/output widgets since the mixer doesn't
> control these.
>
> Anyway, with this understanding I was able to get audio in and out of this
> laptop. The question now is: where to from here. I'd like to get the
> revised initialisation verb list into ALSA but it's not clear how this can
> be done. As far as I can tell the ALC260 in this laptop identifies itself
> using a generic ID; unless there is some other unique ID we can find there
> won't be any way for ALSA to deduce which initialisation verb list is
> required. Perhaps a new module parameter? Let me know your thoughts.
Hmm, so you mean it has no unique PCI _subsystem_ ID, too?
The model is detected with the PCI SSID, not the PCI ID.
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-05 0:29 ` hda-intel/ALC260: crackly playback and DC offset on recording Jonathan Woithe
@ 2005-09-05 10:38 ` Takashi Iwai
2005-09-06 0:07 ` Jonathan Woithe
0 siblings, 1 reply; 29+ messages in thread
From: Takashi Iwai @ 2005-09-05 10:38 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Mon, 5 Sep 2005 09:59:58 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi all
>
> Further tests with the hda-intel driver with the ALC260 chip in my laptop
> has shown that when audio is played, seemingly random crackling occurs
> in the output. This affects only playback - recorded audio is fine. It
> affected aplay (native alsa), wavplay (uses /dev/dsp and thus alsa's OSS
> snd-pcm-oss module) and audacity 1.2.2 (also using /dev/dsp).
>
> I found that the following change to hda_intel.c almost fixed the problem:
>
> --- hda_intel.c 2005-09-03 23:02:18.000000000 +0930
> +++ hda_intel.c-orig 2005-08-16 05:23:07.000000000 +0930
> @@ -1026,7 +1026,7 @@
> azx_setup_periods(azx_dev);
> azx_setup_controller(chip, azx_dev);
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> - azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE);
> + azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE) + 1;
> else
> azx_dev->fifo_size = 0;
This is already in 1.0.10rc1. Or do you mean to revert this?
> If this patch was applied then playing audio using aplay was clean - no hint
> of the crackling was evident. However, playing through audacity (which used
> the ALSA OSS emulation) was still crackly. I then tested using wavplay (which
> also uses the OSS devices) and it too was still crackly. I recompiled
> audacity to use portaudio v19 (thus giving audacity native ALSA support) and
> was slightly surprised to hear that the crackling remained with audacity even
> when using the ALSA output options. Throughout all this, the aplay output
> was clean so long as the above patch had been applied.
Does position_fix=1 module option help?
> I must admit to not knowing exactly what the fifo_size does; my attention
> was drawn to it because the +1 looked odd and it was an obvious point of
> difference between the record path (which was fine) and the playback path
> (which crackled).
The fifo size fix isn't applied to the record path (as you seen the
above).
> On the subject of recording, there seems to be a DC offset in the ADC which
> is dependent on the level of the "capture" mixer control - the higher the
> control the higher the DC offset. The offset is present even when nothing
> is plugged in to the laptop. With the control at maximum the DC offset
> is as much as 10% FSD; at mimimum it's around 1-2%.
>
> Any ideas on either of these?
I guess it's in the codec side, not the controller side.
There might be missing initialization for ALC260...
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-05 10:38 ` Takashi Iwai
@ 2005-09-06 0:07 ` Jonathan Woithe
2005-09-06 9:44 ` Takashi Iwai
0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-06 0:07 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > Further tests with the hda-intel driver with the ALC260 chip in my laptop
> > has shown that when audio is played, seemingly random crackling occurs
> > in the output. This affects only playback - recorded audio is fine. It
> > affected aplay (native alsa), wavplay (uses /dev/dsp and thus alsa's OSS
> > snd-pcm-oss module) and audacity 1.2.2 (also using /dev/dsp).
> >
> > I found that the following change to hda_intel.c almost fixed the problem:
> >
> > --- hda_intel.c 2005-09-03 23:02:18.000000000 +0930
> > +++ hda_intel.c-orig 2005-08-16 05:23:07.000000000 +0930
> > @@ -1026,7 +1026,7 @@
> > azx_setup_periods(azx_dev);
> > azx_setup_controller(chip, azx_dev);
> > if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> > - azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE);
> > + azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE) + 1;
> > else
> > azx_dev->fifo_size = 0;
>
> This is already in 1.0.10rc1. Or do you mean to revert this?
Oops, it looks like I did the diff around the wrong way by accident - sorry
for the confusion. What I mean is that the "+1" should be removed. If the
"+1" was added in 1.0.10rc1 then I guess that means that it should be
reverted. As mentioned below though, without the "+1" aplay output is clean
but not everything is fixed, so this might not be the root cause of the
problem.
> > If this patch was applied then playing audio using aplay was clean - no hint
> > of the crackling was evident. However, playing through audacity (which used
> > the ALSA OSS emulation) was still crackly. I then tested using wavplay (which
> > also uses the OSS devices) and it too was still crackly. I recompiled
> > audacity to use portaudio v19 (thus giving audacity native ALSA support) and
> > was slightly surprised to hear that the crackling remained with audacity even
> > when using the ALSA output options. Throughout all this, the aplay output
> > was clean so long as the above patch had been applied.
> Does position_fix=1 module option help?
I will try this and advise of the outcome.
> > On the subject of recording, there seems to be a DC offset in the ADC which
> > is dependent on the level of the "capture" mixer control - the higher the
> > control the higher the DC offset. The offset is present even when nothing
> > is plugged in to the laptop. With the control at maximum the DC offset
> > is as much as 10% FSD; at mimimum it's around 1-2%.
> >
> > Any ideas on either of these?
>
> I guess it's in the codec side, not the controller side.
> There might be missing initialization for ALC260...
I thought of that, but there doesn't appear to be anything in the ALC260
datasheet related to a DC offset. There is talk about the option of setting
the Vref on these pins (50% or 80% of digital supply) but doing either
doesn't alter the DC offset in the sampled datastream compared to the "no
Vref" case which is what I'm currently using. Perhaps it's related to the
chip's impedence detection logic - I'll have a look at that area tonight.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-05 10:35 ` Takashi Iwai
@ 2005-09-06 0:24 ` Jonathan Woithe
2005-09-06 9:38 ` Takashi Iwai
0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-06 0:24 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > I had the opportunity to sit down over the weekend and work through the
> > issues. It turns out that this particular laptop has its sound hardware
> > wired up in an odd way. I was able to get the external plugs working but
> > had to write my own custom ALC260 initialisation verb list to do so.
> >
> > To cut a long story short, the audio inputs/outputs are connected to the
> > following ALC260 output pins.
> >
> > * Internal speaker: ALC260 "headphone" pin
> > * "Stereo line in jack": ALC260 "mic 1" pin
> > * "Stereo line out jack": ALC260 "line 1" pin (ie: NOT the "line out" pin)
> > * CD audio: ALC260 "CD" pin
> >
> > The reason I got nothing out of the jack is clear: ALSA configures the
> > ALC260 "line out" pin as output and the ALC260 "line 1" as input. However,
> > in the case of this laptop ALC260 "line 1" is actually the output, with line
> > level input appearing at the ALC260 "mic 1" pin. I also found I had to
> > explicitly unmute selected input/output widgets since the mixer doesn't
> > control these.
> >
> > Anyway, with this understanding I was able to get audio in and out of this
> > laptop. The question now is: where to from here. I'd like to get the
> > revised initialisation verb list into ALSA but it's not clear how this can
> > be done. As far as I can tell the ALC260 in this laptop identifies itself
> > using a generic ID; unless there is some other unique ID we can find there
> > won't be any way for ALSA to deduce which initialisation verb list is
> > required. Perhaps a new module parameter? Let me know your thoughts.
>
> Hmm, so you mean it has no unique PCI _subsystem_ ID, too?
> The model is detected with the PCI SSID, not the PCI ID.
The PCI SSID is just the thing listed under "subsystem" in lspci, right?
If so I guess it would be 10cf:1326. How unique is this?
I guess the correct way of dealing with this is to define a new model in
patches_realtek.c in the same way that the HP variant is currently done, and
use the alternative initialisation verb list if this new model is detected?
I'll do a patch up along these lines in the next day or so unless you advise
that there is a better way.
For completeness, here's the output of the relevant section of "lspci -v":
00:1b.0 Class 0403: Intel Corp.: Unknown device 2668 (rev 04)
Subsystem: Fujitsu Limited.: Unknown device 1326
Flags: bus master, fast devsel, latency 0, IRQ 17
Memory at b0000000 (64-bit, non-prefetchable) [size=16k]
Capabilities: <available only to root>
The first two lines if "lspci -vn" is used are:
00:1b.0 Class 0403: 8086:2668 (rev 04)
Subsystem: 10cf:1326
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-06 0:24 ` Jonathan Woithe
@ 2005-09-06 9:38 ` Takashi Iwai
2005-09-07 0:02 ` Jonathan Woithe
0 siblings, 1 reply; 29+ messages in thread
From: Takashi Iwai @ 2005-09-06 9:38 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Tue, 6 Sep 2005 09:54:01 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > I had the opportunity to sit down over the weekend and work through the
> > > issues. It turns out that this particular laptop has its sound hardware
> > > wired up in an odd way. I was able to get the external plugs working but
> > > had to write my own custom ALC260 initialisation verb list to do so.
> > >
> > > To cut a long story short, the audio inputs/outputs are connected to the
> > > following ALC260 output pins.
> > >
> > > * Internal speaker: ALC260 "headphone" pin
> > > * "Stereo line in jack": ALC260 "mic 1" pin
> > > * "Stereo line out jack": ALC260 "line 1" pin (ie: NOT the "line out" pin)
> > > * CD audio: ALC260 "CD" pin
> > >
> > > The reason I got nothing out of the jack is clear: ALSA configures the
> > > ALC260 "line out" pin as output and the ALC260 "line 1" as input. However,
> > > in the case of this laptop ALC260 "line 1" is actually the output, with line
> > > level input appearing at the ALC260 "mic 1" pin. I also found I had to
> > > explicitly unmute selected input/output widgets since the mixer doesn't
> > > control these.
> > >
> > > Anyway, with this understanding I was able to get audio in and out of this
> > > laptop. The question now is: where to from here. I'd like to get the
> > > revised initialisation verb list into ALSA but it's not clear how this can
> > > be done. As far as I can tell the ALC260 in this laptop identifies itself
> > > using a generic ID; unless there is some other unique ID we can find there
> > > won't be any way for ALSA to deduce which initialisation verb list is
> > > required. Perhaps a new module parameter? Let me know your thoughts.
> >
> > Hmm, so you mean it has no unique PCI _subsystem_ ID, too?
> > The model is detected with the PCI SSID, not the PCI ID.
>
> The PCI SSID is just the thing listed under "subsystem" in lspci, right?
> If so I guess it would be 10cf:1326. How unique is this?
No guarantee, but it should be fairly unique if the manufacturor cares
enough :)
> I guess the correct way of dealing with this is to define a new model in
> patches_realtek.c in the same way that the HP variant is currently done, and
> use the alternative initialisation verb list if this new model is detected?
> I'll do a patch up along these lines in the next day or so unless you advise
> that there is a better way.
Agreed. You need just to put your ssid there. Go ahead!
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-06 0:07 ` Jonathan Woithe
@ 2005-09-06 9:44 ` Takashi Iwai
2005-09-06 23:58 ` Jonathan Woithe
2005-09-09 0:08 ` Jonathan Woithe
0 siblings, 2 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-06 9:44 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Tue, 6 Sep 2005 09:37:20 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > Further tests with the hda-intel driver with the ALC260 chip in my laptop
> > > has shown that when audio is played, seemingly random crackling occurs
> > > in the output. This affects only playback - recorded audio is fine. It
> > > affected aplay (native alsa), wavplay (uses /dev/dsp and thus alsa's OSS
> > > snd-pcm-oss module) and audacity 1.2.2 (also using /dev/dsp).
> > >
> > > I found that the following change to hda_intel.c almost fixed the problem:
> > >
> > > --- hda_intel.c 2005-09-03 23:02:18.000000000 +0930
> > > +++ hda_intel.c-orig 2005-08-16 05:23:07.000000000 +0930
> > > @@ -1026,7 +1026,7 @@
> > > azx_setup_periods(azx_dev);
> > > azx_setup_controller(chip, azx_dev);
> > > if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> > > - azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE);
> > > + azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE) + 1;
> > > else
> > > azx_dev->fifo_size = 0;
> >
> > This is already in 1.0.10rc1. Or do you mean to revert this?
>
> Oops, it looks like I did the diff around the wrong way by accident - sorry
> for the confusion. What I mean is that the "+1" should be removed. If the
> "+1" was added in 1.0.10rc1 then I guess that means that it should be
> reverted. As mentioned below though, without the "+1" aplay output is clean
> but not everything is fixed, so this might not be the root cause of the
> problem.
It was necessary on my test system, but this might be the problem.
Anyway, I added the check of DMA position in the latest CVS code
yesterday. Please give a shot with the latest CVS version.
> > > On the subject of recording, there seems to be a DC offset in the ADC which
> > > is dependent on the level of the "capture" mixer control - the higher the
> > > control the higher the DC offset. The offset is present even when nothing
> > > is plugged in to the laptop. With the control at maximum the DC offset
> > > is as much as 10% FSD; at mimimum it's around 1-2%.
> > >
> > > Any ideas on either of these?
> >
> > I guess it's in the codec side, not the controller side.
> > There might be missing initialization for ALC260...
>
> I thought of that, but there doesn't appear to be anything in the ALC260
> datasheet related to a DC offset. There is talk about the option of setting
> the Vref on these pins (50% or 80% of digital supply) but doing either
> doesn't alter the DC offset in the sampled datastream compared to the "no
> Vref" case which is what I'm currently using. Perhaps it's related to the
> chip's impedence detection logic - I'll have a look at that area tonight.
Yes, this could be...
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-06 9:44 ` Takashi Iwai
@ 2005-09-06 23:58 ` Jonathan Woithe
2005-09-09 0:08 ` Jonathan Woithe
1 sibling, 0 replies; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-06 23:58 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > > > Further tests with the hda-intel driver with the ALC260 chip in my laptop
> > > > has shown that when audio is played, seemingly random crackling occurs
> > > > in the output. This affects only playback - recorded audio is fine. It
> > > > affected aplay (native alsa), wavplay (uses /dev/dsp and thus alsa's OSS
> > > > snd-pcm-oss module) and audacity 1.2.2 (also using /dev/dsp).
> > > >
> > > > I found that the following change to hda_intel.c almost fixed the problem:
> > > >
> > > > --- hda_intel.c 2005-09-03 23:02:18.000000000 +0930
> > > > +++ hda_intel.c-orig 2005-08-16 05:23:07.000000000 +0930
> > > > @@ -1026,7 +1026,7 @@
> > > > azx_setup_periods(azx_dev);
> > > > azx_setup_controller(chip, azx_dev);
> > > > if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
> > > > - azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE);
> > > > + azx_dev->fifo_size = azx_sd_readw(azx_dev, SD_FIFOSIZE) + 1;
> > > > else
> > > > azx_dev->fifo_size = 0;
> > >
> > > This is already in 1.0.10rc1. Or do you mean to revert this?
> >
> > Oops, it looks like I did the diff around the wrong way by accident - sorry
> > for the confusion. What I mean is that the "+1" should be removed. If the
> > "+1" was added in 1.0.10rc1 then I guess that means that it should be
> > reverted. As mentioned below though, without the "+1" aplay output is clean
> > but not everything is fixed, so this might not be the root cause of the
> > problem.
>
> It was necessary on my test system, but this might be the problem.
Overnight I tested with the position_fix=1 module parameter as you suggested
yesterday. This removed the crackly sound from wavplay (I ran out of time
and couldn't check audacity, but I expect it will be fixed too). I then
reverted my patch (ie: I added the "+1" back to the fifo_size calculation)
and again there was no crackles from either aplay or wavplay so long as
position_fix=1 was specified at module load time.
So it looks like "position_fix=1" is the "correct" fix for my hardware.
> Anyway, I added the check of DMA position in the latest CVS code
> yesterday. Please give a shot with the latest CVS version.
No worries - will try to get to this overnight and will advise the outcome.
> > > > On the subject of recording, there seems to be a DC offset in the ADC which
> > > > is dependent on the level of the "capture" mixer control - the higher the
> > > > control the higher the DC offset. The offset is present even when nothing
> > > > is plugged in to the laptop. With the control at maximum the DC offset
> > > > is as much as 10% FSD; at mimimum it's around 1-2%.
> > >
> > > I guess it's in the codec side, not the controller side.
> > > There might be missing initialization for ALC260...
> >
> > I thought of that, but there doesn't appear to be anything in the ALC260
> > datasheet related to a DC offset. There is talk about the option of setting
> > the Vref on these pins (50% or 80% of digital supply) but doing either
> > doesn't alter the DC offset in the sampled datastream compared to the "no
> > Vref" case which is what I'm currently using. Perhaps it's related to the
> > chip's impedence detection logic - I'll have a look at that area tonight.
>
> Yes, this could be...
I altered my initialisation verb list to explicitly disable all unused chip
I/O pins (ie: write 0 to the pin setup). The idea here was to avoid any
complications if multiple pins were in some way connected to the LineIn
jack. This however didn't make any difference.
In terms of the pin sense logic I can't see any direct control of that.
We have verb ID 0x709 to "execute" pin sense, and verb ID 0xF09 to get the
pin sense result, but there doesn't appear to be anything in the datasheet
which suggests that pinsense can be disabled. Perhaps there's something
obscure buried in the datasheet and I'll keep looking, but the first pass
suggests that there's nothing we can do in this area.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-06 9:38 ` Takashi Iwai
@ 2005-09-07 0:02 ` Jonathan Woithe
2005-09-07 8:44 ` Takashi Iwai
0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-07 0:02 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > > > I had the opportunity to sit down over the weekend and work through the
> > > > issues. It turns out that this particular laptop has its sound hardware
> > > > wired up in an odd way. I was able to get the external plugs working but
> > > > had to write my own custom ALC260 initialisation verb list to do so.
> > > >
> > > > To cut a long story short, the audio inputs/outputs are connected to the
> > > > following ALC260 output pins.
> > > >
> > > > * Internal speaker: ALC260 "headphone" pin
> > > > * "Stereo line in jack": ALC260 "mic 1" pin
> > > > * "Stereo line out jack": ALC260 "line 1" pin (ie: NOT the "line out" pin)
> > > > * CD audio: ALC260 "CD" pin
> > > >
> > > > :
> > > Hmm, so you mean it has no unique PCI _subsystem_ ID, too?
> > > The model is detected with the PCI SSID, not the PCI ID.
> >
> > The PCI SSID is just the thing listed under "subsystem" in lspci, right?
> > If so I guess it would be 10cf:1326. How unique is this?
>
> No guarantee, but it should be fairly unique if the manufacturor cares
> enough :)
No worries. We'll assume it is and see what happens.
> > I'll do a patch up along these lines in the next day or so unless you advise
> > that there is a better way.
> Agreed. You need just to put your ssid there. Go ahead!
Not a problem; will do. While I'm at it I'll probably also define a custom
mixer layout so it's clearer which controls are actually available on this
laptop and what they really do. For example, "IntSpeaker" instead of
"Headphone", "Mic/LineIn" instead of "Mic", "LineOut" instead of "Line", and
remove some controls (like "mono") which don't seem to be connected to any
physical hardware.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-07 0:02 ` Jonathan Woithe
@ 2005-09-07 8:44 ` Takashi Iwai
2005-09-08 0:57 ` Jonathan Woithe
0 siblings, 1 reply; 29+ messages in thread
From: Takashi Iwai @ 2005-09-07 8:44 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Wed, 7 Sep 2005 09:32:11 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > > > I had the opportunity to sit down over the weekend and work through the
> > > > > issues. It turns out that this particular laptop has its sound hardware
> > > > > wired up in an odd way. I was able to get the external plugs working but
> > > > > had to write my own custom ALC260 initialisation verb list to do so.
> > > > >
> > > > > To cut a long story short, the audio inputs/outputs are connected to the
> > > > > following ALC260 output pins.
> > > > >
> > > > > * Internal speaker: ALC260 "headphone" pin
> > > > > * "Stereo line in jack": ALC260 "mic 1" pin
> > > > > * "Stereo line out jack": ALC260 "line 1" pin (ie: NOT the "line out" pin)
> > > > > * CD audio: ALC260 "CD" pin
> > > > >
> > > > > :
> > > > Hmm, so you mean it has no unique PCI _subsystem_ ID, too?
> > > > The model is detected with the PCI SSID, not the PCI ID.
> > >
> > > The PCI SSID is just the thing listed under "subsystem" in lspci, right?
> > > If so I guess it would be 10cf:1326. How unique is this?
> >
> > No guarantee, but it should be fairly unique if the manufacturor cares
> > enough :)
>
> No worries. We'll assume it is and see what happens.
>
> > > I'll do a patch up along these lines in the next day or so unless you advise
> > > that there is a better way.
> > Agreed. You need just to put your ssid there. Go ahead!
>
> Not a problem; will do. While I'm at it I'll probably also define a custom
> mixer layout so it's clearer which controls are actually available on this
> laptop and what they really do. For example, "IntSpeaker" instead of
> "Headphone", "Mic/LineIn" instead of "Mic", "LineOut" instead of "Line", and
> remove some controls (like "mono") which don't seem to be connected to any
> physical hardware.
It's fine as long as you use ALSA native apps, but remember that some
apps require certain known controls. Also, OSS emulation wouldn't
work properly.
BTW, "Line" and "Line Out" are different. "Line Playback Volume"
is the volume of thruback signal from line-in jack to a certain
output. I guess "LineOut" corresponds to "Headphone", in your case.
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-07 8:44 ` Takashi Iwai
@ 2005-09-08 0:57 ` Jonathan Woithe
2005-09-08 9:14 ` Takashi Iwai
0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-08 0:57 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > > > I'll do a patch up along these lines in the next day or so unless you advise
> > > > that there is a better way.
> > > Agreed. You need just to put your ssid there. Go ahead!
> >
> > Not a problem; will do. While I'm at it I'll probably also define a custom
> > mixer layout so it's clearer which controls are actually available on this
> > laptop and what they really do. For example, "IntSpeaker" instead of
> > "Headphone", "Mic/LineIn" instead of "Mic", "LineOut" instead of "Line", and
> > remove some controls (like "mono") which don't seem to be connected to any
> > physical hardware.
>
> It's fine as long as you use ALSA native apps, but remember that some
> apps require certain known controls. Also, OSS emulation wouldn't
> work properly.
Note that the above names were abbreviated for brevity: "IntSpeaker" is
really "IntSpeaker Playback Volume", etc. I should have made that clear.
Are these "known special names" documented anywhere?
OSS emulation appears to be working fine with the names I'm currently using
(although admittedly I haven't tested an OSS mixer).
> BTW, "Line" and "Line Out" are different. "Line Playback Volume"
> is the volume of thruback signal from line-in jack to a certain
> output.
Yes, understood. Sorry, the above paragraph was written from memory and I
probably confused a few things when typing. The "Mic/LineIn Playback
Volume" corresponds to "Line" - I just figured that having the controls
labelled in a way which related to how the physical jacks were labelled was
a good thing. Given the troubles you flagged due to the unusual names
I might use "Line" for "Mic/LineIn" and "Headphone" for "LineOut though.
> I guess "LineOut" corresponds to "Headphone", in your case.
"LineOut" is the overall volume of the signal sent to the "Line Out" jack on
the laptop. Having said that the jack does have sufficient power to drive a
pair of headphones even without the internal amp enabled. The "headphone"
pin on the ALC260 chip goes to the internal speaker; hense the "IntSpeaker
Playback Volume" designation.
It'd be nice if we could have a mixer control which allowed the user to
switch the LineOut socket between a true LineOut and a "Headphone" output
(that is, a pin with the internal headphone amp turned on). I don't think
there's infrastructure to allow this, however. That might have to become
a module parameter (lineout_is_headphone, enable_hp_amp or something).
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-08 0:57 ` Jonathan Woithe
@ 2005-09-08 9:14 ` Takashi Iwai
2005-09-08 23:43 ` Jonathan Woithe
2005-09-12 0:10 ` Jonathan Woithe
0 siblings, 2 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-08 9:14 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Thu, 8 Sep 2005 10:27:11 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > > > I'll do a patch up along these lines in the next day or so unless you advise
> > > > > that there is a better way.
> > > > Agreed. You need just to put your ssid there. Go ahead!
> > >
> > > Not a problem; will do. While I'm at it I'll probably also define a custom
> > > mixer layout so it's clearer which controls are actually available on this
> > > laptop and what they really do. For example, "IntSpeaker" instead of
> > > "Headphone", "Mic/LineIn" instead of "Mic", "LineOut" instead of "Line", and
> > > remove some controls (like "mono") which don't seem to be connected to any
> > > physical hardware.
> >
> > It's fine as long as you use ALSA native apps, but remember that some
> > apps require certain known controls. Also, OSS emulation wouldn't
> > work properly.
>
> Note that the above names were abbreviated for brevity: "IntSpeaker" is
> really "IntSpeaker Playback Volume", etc. I should have made that clear.
>
> Are these "known special names" documented anywhere?
No, it depends on apps. Many apps want to use either "Master" or
"PCM" control.
> > I guess "LineOut" corresponds to "Headphone", in your case.
>
> "LineOut" is the overall volume of the signal sent to the "Line Out" jack on
> the laptop. Having said that the jack does have sufficient power to drive a
> pair of headphones even without the internal amp enabled. The "headphone"
> pin on the ALC260 chip goes to the internal speaker; hense the "IntSpeaker
> Playback Volume" designation.
>
> It'd be nice if we could have a mixer control which allowed the user to
> switch the LineOut socket between a true LineOut and a "Headphone" output
> (that is, a pin with the internal headphone amp turned on). I don't think
> there's infrastructure to allow this, however. That might have to become
> a module parameter (lineout_is_headphone, enable_hp_amp or something).
Basically the control names correspond their roles, not (always) the
pin assignment. For example, on ac97, the ture line-out is handled as
master (processed according to a quirk table or a module option).
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-08 9:14 ` Takashi Iwai
@ 2005-09-08 23:43 ` Jonathan Woithe
2005-09-12 0:10 ` Jonathan Woithe
1 sibling, 0 replies; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-08 23:43 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > > It's fine as long as you use ALSA native apps, but remember that some
> > > apps require certain known controls. Also, OSS emulation wouldn't
> > > work properly.
> >
> > Note that the above names were abbreviated for brevity: "IntSpeaker" is
> > really "IntSpeaker Playback Volume", etc. I should have made that clear.
> >
> > Are these "known special names" documented anywhere?
>
> No, it depends on apps. Many apps want to use either "Master" or
> "PCM" control.
No worries. I'm not touching the "PCM".
> > It'd be nice if we could have a mixer control which allowed the user to
> > switch the LineOut socket between a true LineOut and a "Headphone" output
> > (that is, a pin with the internal headphone amp turned on). I don't think
> > there's infrastructure to allow this, however. That might have to become
> > a module parameter (lineout_is_headphone, enable_hp_amp or something).
>
> Basically the control names correspond their roles, not (always) the
> pin assignment. For example, on ac97, the ture line-out is handled as
> master (processed according to a quirk table or a module option).
Sure, no worries. I guess the problem I have with "Master" in this case is
that "LineOut" on this laptop doesn't actually control every output (which
is what "master" tends to imply, at least to me) - the internal speaker is
separate. Anyway, I'll try to come up with something which is consistent and
submit a patch early next week for your consideration.
Regards
jonathan
--
* Jonathan Woithe jwoithe@physics.adelaide.edu.au *
* http://www.physics.adelaide.edu.au/~jwoithe *
***-----------------------------------------------------------------------***
** "Time is an illusion; lunchtime doubly so" **
* "...you wouldn't recognize a subtle plan if it painted itself purple and *
* danced naked on a harpsichord singing 'subtle plans are here again'" *
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-06 9:44 ` Takashi Iwai
2005-09-06 23:58 ` Jonathan Woithe
@ 2005-09-09 0:08 ` Jonathan Woithe
2005-09-09 10:09 ` Takashi Iwai
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-09 0:08 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > Oops, it looks like I did the diff around the wrong way by accident - sorry
> > for the confusion. What I mean is that the "+1" should be removed. If the
> > "+1" was added in 1.0.10rc1 then I guess that means that it should be
> > reverted. As mentioned below though, without the "+1" aplay output is clean
> > but not everything is fixed, so this might not be the root cause of the
> > problem.
>
> It was necessary on my test system, but this might be the problem.
>
> Anyway, I added the check of DMA position in the latest CVS code
> yesterday. Please give a shot with the latest CVS version.
I did this overnight. The CVS snapshot was taken on 7 Sept 2005 at around
1600 local time (UT+0930). I tried it both with and without the
position_fixed module parameter.
Without the position_fixed module parameter, playback via aplay was crackly.
This is new - aplay playback under 1.0.10rc1 without the position_fixed
parameter was fine. Playback via wavplay (OSS interface) was however *much*
worse than it used to be. Whereas under 1.0.10rc1 it would simply be
crackly, under the CVS snapshot large chunks of audio were being skipped. I
didn't have a change to quantify it, but it seemed to me that perhaps every
second block of data was being skipped.
Next I retried with the position_fixed=1 parameter. Both aplay (native alsa)
and wavplay (oss emulation) produced clean signal in this case, so the
position_fixed=1 has not changed in the CVS snapshot compared to 1.0.10rc1.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-09 0:08 ` Jonathan Woithe
@ 2005-09-09 10:09 ` Takashi Iwai
2005-09-09 10:42 ` Takashi Iwai
2005-09-13 0:37 ` Jonathan Woithe
0 siblings, 2 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-09 10:09 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Fri, 9 Sep 2005 09:38:09 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > Oops, it looks like I did the diff around the wrong way by accident - sorry
> > > for the confusion. What I mean is that the "+1" should be removed. If the
> > > "+1" was added in 1.0.10rc1 then I guess that means that it should be
> > > reverted. As mentioned below though, without the "+1" aplay output is clean
> > > but not everything is fixed, so this might not be the root cause of the
> > > problem.
> >
> > It was necessary on my test system, but this might be the problem.
> >
> > Anyway, I added the check of DMA position in the latest CVS code
> > yesterday. Please give a shot with the latest CVS version.
>
> I did this overnight. The CVS snapshot was taken on 7 Sept 2005 at around
> 1600 local time (UT+0930). I tried it both with and without the
> position_fixed module parameter.
>
> Without the position_fixed module parameter, playback via aplay was crackly.
> This is new - aplay playback under 1.0.10rc1 without the position_fixed
> parameter was fine. Playback via wavplay (OSS interface) was however *much*
> worse than it used to be. Whereas under 1.0.10rc1 it would simply be
> crackly, under the CVS snapshot large chunks of audio were being skipped. I
> didn't have a change to quantify it, but it seemed to me that perhaps every
> second block of data was being skipped.
Interesting. Then the DMA position is somewhat weird.
The patch below is
>
> Next I retried with the position_fixed=1 parameter. Both aplay (native alsa)
> and wavplay (oss emulation) produced clean signal in this case, so the
> position_fixed=1 has not changed in the CVS snapshot compared to 1.0.10rc1.
No, it's not changed. The only position_fix=0 (default value) is
changed. On CVS, the DMA position is compared with the expected value
and corrected only if necessary.
Anyway, the below is another fix. Now the DMA position check is done
with every position_fix value, but the corrected only with
position_fix=0. Compile with debug option, so that you can see debug
messages.
Index: alsa-kernel/pci/hda/hda_intel.c
===================================================================
RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/hda/hda_intel.c,v
retrieving revision 1.24
diff -u -r1.24 hda_intel.c
--- alsa-kernel/pci/hda/hda_intel.c 7 Sep 2005 14:17:29 -0000 1.24
+++ alsa-kernel/pci/hda/hda_intel.c 9 Sep 2005 10:04:17 -0000
@@ -1137,26 +1137,33 @@
pos = azx_sd_readl(azx_dev, SD_LPIB);
if (chip->position_fix == POS_FIX_FIFO)
pos += azx_dev->fifo_size;
- else if (chip->position_fix == POS_FIX_AUTO && azx_dev->period_updating) {
- /* check the validity of DMA position */
- unsigned int diff = 0;
- azx_dev->last_pos += azx_dev->fragsize;
- if (azx_dev->last_pos > pos)
- diff = azx_dev->last_pos - pos;
- if (azx_dev->last_pos >= azx_dev->bufsize) {
- if (pos < azx_dev->fragsize)
- diff = 0;
- azx_dev->last_pos = 0;
- }
- if (diff > 0 && diff <= azx_dev->fifo_size)
- pos += azx_dev->fifo_size;
- else {
- snd_printdd(KERN_INFO "hda_intel: DMA position fix %d, switching to posbuf\n", diff);
- chip->position_fix = POS_FIX_POSBUF;
- pos = *azx_dev->posbuf;
+ }
+ if (azx_dev->period_updating) {
+ /* check the validity of DMA position */
+ unsigned int diff = 0;
+ azx_dev->last_pos += azx_dev->fragsize;
+ if (azx_dev->last_pos > pos)
+ diff = azx_dev->last_pos - pos;
+ if (azx_dev->last_pos >= azx_dev->bufsize) {
+ if (pos < azx_dev->fragsize)
+ diff = 0;
+ azx_dev->last_pos = 0;
+ }
+ if (diff > 0) {
+ if (chip->position_fix == POS_FIX_AUTO) {
+ if (diff <= azx_dev->fifo_size)
+ /* pos += azx_dev->fifo_size; */
+ pos += diff;
+ else {
+ snd_printd("hda_intel: DMA position fix %d (fifo size=%d), switching to posbuf\n", diff, azx_dev->fifo_size);
+ chip->position_fix = POS_FIX_POSBUF;
+ pos = *azx_dev->posbuf;
+ }
+ } else {
+ snd_printd("hda_intel: DMA position invalid %d (diff %d)\n", pos, diff);
}
- azx_dev->period_updating = 0;
}
+ azx_dev->period_updating = 0;
}
if (pos >= azx_dev->bufsize)
pos = 0;
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-09 10:09 ` Takashi Iwai
@ 2005-09-09 10:42 ` Takashi Iwai
2005-09-13 0:37 ` Jonathan Woithe
1 sibling, 0 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-09 10:42 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Fri, 09 Sep 2005 12:09:27 +0200,
I wrote:
>
> At Fri, 9 Sep 2005 09:38:09 +0930 (CST),
> Jonathan Woithe wrote:
> >
> > Hi Takashi
> >
> > > > Oops, it looks like I did the diff around the wrong way by accident - sorry
> > > > for the confusion. What I mean is that the "+1" should be removed. If the
> > > > "+1" was added in 1.0.10rc1 then I guess that means that it should be
> > > > reverted. As mentioned below though, without the "+1" aplay output is clean
> > > > but not everything is fixed, so this might not be the root cause of the
> > > > problem.
> > >
> > > It was necessary on my test system, but this might be the problem.
> > >
> > > Anyway, I added the check of DMA position in the latest CVS code
> > > yesterday. Please give a shot with the latest CVS version.
> >
> > I did this overnight. The CVS snapshot was taken on 7 Sept 2005 at around
> > 1600 local time (UT+0930). I tried it both with and without the
> > position_fixed module parameter.
> >
> > Without the position_fixed module parameter, playback via aplay was crackly.
> > This is new - aplay playback under 1.0.10rc1 without the position_fixed
> > parameter was fine. Playback via wavplay (OSS interface) was however *much*
> > worse than it used to be. Whereas under 1.0.10rc1 it would simply be
> > crackly, under the CVS snapshot large chunks of audio were being skipped. I
> > didn't have a change to quantify it, but it seemed to me that perhaps every
> > second block of data was being skipped.
>
> Interesting. Then the DMA position is somewhat weird.
>
> The patch below is
Oops, just connect with the second paragraph below :)
>
> >
> > Next I retried with the position_fixed=1 parameter. Both aplay (native alsa)
> > and wavplay (oss emulation) produced clean signal in this case, so the
> > position_fixed=1 has not changed in the CVS snapshot compared to 1.0.10rc1.
>
> No, it's not changed. The only position_fix=0 (default value) is
> changed. On CVS, the DMA position is compared with the expected value
> and corrected only if necessary.
>
> Anyway, the below is another fix. Now the DMA position check is done
> with every position_fix value, but the corrected only with
> position_fix=0. Compile with debug option, so that you can see debug
> messages.
Also, try another value of position_fix. Currently,
0 = auto check the value and correct with fifo size if needed
if the value is over a fifo size, turns to posbuf mode
1 = none use a register value as it is
2 = posbuf use a position-buffer
3 = fifo always correct with the fifo size (corresponds to 0 in
the earlier version)
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-08 9:14 ` Takashi Iwai
2005-09-08 23:43 ` Jonathan Woithe
@ 2005-09-12 0:10 ` Jonathan Woithe
2005-09-12 10:24 ` Takashi Iwai
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-12 0:10 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]
Hi Takashi
> > I'll do a patch up along these lines in the next day or so unless you advise
> > that there is a better way.
> Agreed. You need just to put your ssid there. Go ahead!
Find attached a patch which adds support for the ALC260 as it is connected
in a Fujitsu S7020 laptop (and probably the S7021 too). A new
initialisation verb list is defined which sets up the somewhat unexpected
use of the ALC260 pins:
Headphone pin -> Internal speaker
mic 1 pin -> mic/LineIn jack
line 1 pin -> LineOut jack
CD pin -> Internal CD drive audio
As far as I can tell these are the only pins connected and in use. Thus
the others are effectively turned off.
The number of mixer controls have been reduced to include only the pins
which actually do something. The control names reflect the above usage
rather than the ALC260 pins they control. These control names appear to do
the right thing for the ALSA and OSS apps I've tested (audacity, aplay,
wavplay plus some OSS things I've written).
Capture is enabled for the mic 1 and CD pins.
The patch is against alsa-kernel/pci/hda/patch_realtek.c from 1.0.10rc1 but
I expect it will apply trivially to CVS. If there's a problem let me know.
The new mixer/initialisation is only activated if the subsystem vendor
and device IDs match those in the S7020, since there's no guarantee that
other Fujitsu models will share this device layout. I figure things can
always be relaxed later if it turns out this applies to other models.
The only outstanding mixer-related issue is control of the headphone amp
associated with the LineOut jack. In essence the ALC260 Line 1 pin has a
headphone amp which can be enabled to drive headphones harder than can be
done without it. However, the noise level increases if this is done, so if
the output is being fed to other equipment it's better to leave the amp off.
It would be nice to be able to turn this amp on and off dynamically but the
mixer API doesn't appear to have the ability to do this (although I'm still
looking). The alternative is to define a new module option which turns the
amp on if the user requests it. I'm still working on this and will submit a
patch addressing this if I can come up with something sensible.
Regards
jonathan
[-- Attachment #2: ASCII C program text --]
[-- Type: text/plain, Size: 6229 bytes --]
--- patch_realtek.c-orig 2005-08-16 04:31:40.000000000 +0930
+++ patch_realtek.c 2005-09-12 00:27:32.000000000 +0930
@@ -57,6 +57,7 @@
enum {
ALC260_BASIC,
ALC260_HP,
+ ALC260_FUJITSU_S702x,
ALC260_MODEL_LAST /* last tag */
};
@@ -2209,6 +2210,17 @@
},
};
+/* On Fujitsu S702x laptops capture only makes sense from Mic/LineIn jack
+ * and the internal CD lines.
+ */
+static struct hda_input_mux alc260_fujitsu_capture_source = {
+ .num_items = 2,
+ .items = {
+ { "Mic/LineIn", 0x0 },
+ { "CD", 0x4 },
+ },
+};
+
/*
* This is just place-holder, so there's something for alc_build_pcms to look
* at when it calculates the maximum number of channels. ALC260 has no mixer
@@ -2275,6 +2287,29 @@
{ } /* end */
};
+static snd_kcontrol_new_t alc260_fujitsu_mixer[] = {
+ HDA_CODEC_VOLUME("LineOut Playback Volume", 0x08, 0x0, HDA_OUTPUT),
+ ALC_BIND_MUTE("LineOut Playback Switch", 0x08, 2, HDA_INPUT),
+ HDA_CODEC_VOLUME("CD Playback Volume", 0x07, 0x04, HDA_INPUT),
+ HDA_CODEC_MUTE("CD Playback Switch", 0x07, 0x04, HDA_INPUT),
+ HDA_CODEC_VOLUME("Mic/LineIn Playback Volume", 0x07, 0x0, HDA_INPUT),
+ HDA_CODEC_MUTE("Mic/LineIn Playback Switch", 0x07, 0x0, HDA_INPUT),
+ HDA_CODEC_VOLUME("BeepGen Playback Volume", 0x07, 0x05, HDA_INPUT),
+ HDA_CODEC_MUTE("BeepGen Playback Switch", 0x07, 0x05, HDA_INPUT),
+ HDA_CODEC_VOLUME("IntSpeaker Playback Volume", 0x09, 0x0, HDA_OUTPUT),
+ ALC_BIND_MUTE("IntSpeaker Playback Switch", 0x09, 2, HDA_INPUT),
+ HDA_CODEC_VOLUME("Capture Volume", 0x04, 0x0, HDA_INPUT),
+ HDA_CODEC_MUTE("Capture Switch", 0x04, 0x0, HDA_INPUT),
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .name = "Capture Source",
+ .info = alc_mux_enum_info,
+ .get = alc_mux_enum_get,
+ .put = alc_mux_enum_put,
+ },
+ { } /* end */
+};
+
static struct hda_verb alc260_init_verbs[] = {
/* Line In pin widget for input */
{0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
@@ -2336,6 +2371,60 @@
{ }
};
+/* Initialisation sequence for ALC260 as configured in Fujitsu S702x
+ * laptops.
+ */
+static struct hda_verb alc260_fujitsu_init_verbs[] = {
+ /* Disable all GPIOs */
+ {0x01, AC_VERB_SET_GPIO_MASK, 0},
+ /* Internal speaker is connected to headphone pin */
+ {0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP},
+ /* Line-out jack is connected to Line1 pin, so make it an output */
+ {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
+ /* Line-in jack is connected to mic1 pin, so make it an input */
+ {0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
+ /* Ensure all other unused pins are disabled and muted.
+ * Note: trying to set widget 0x15 to anything blocks all audio
+ * output for some reason, so just leave that at the default.
+ */
+ {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+ {0x0f, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ {0x11, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+ {0x11, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ {0x13, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+ {0x13, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ /* Disable digital (SPDIF) pins */
+ {0x03, AC_VERB_SET_DIGI_CONVERT_1, 0},
+ {0x06, AC_VERB_SET_DIGI_CONVERT_1, 0},
+
+ /* Start with mixer outputs muted */
+ {0x08, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
+ {0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
+ {0x0a, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
+
+ /* Unmute HP pin widget amp left and right (no equiv mixer ctrl) */
+ {0x10, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
+ /* Unmute Line1 pin widget amp left and right (no equiv mixer ctrl) */
+ {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
+ /* Unmute pin widget used for Line-in (no equiv mixer ctrl) */
+ {0x12, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
+
+ /* Mute capture amp left and right */
+ {0x04, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ /* Set ADC connection select to line in (on mic1 pin) */
+ {0x04, AC_VERB_SET_CONNECT_SEL, 0x00},
+
+ /* Mute all inputs to mixer widget (even unconnected ones) */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, /* mic1 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, /* mic2 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, /* line1 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, /* line2 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, /* CD pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(5)}, /* Beep-gen pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(6)}, /* Line-out pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(7)}, /* HP-pin pin */
+};
+
static struct hda_pcm_stream alc260_pcm_analog_playback = {
.substreams = 1,
.channels_min = 2,
@@ -2351,6 +2440,7 @@
static struct hda_board_config alc260_cfg_tbl[] = {
{ .modelname = "hp", .config = ALC260_HP },
{ .pci_subvendor = 0x103c, .config = ALC260_HP },
+ { .pci_subvendor = 0x10cf, .pci_subdevice = 0x1326, .config = ALC260_FUJITSU_S702x },
{}
};
@@ -2377,14 +2467,23 @@
spec->mixers[spec->num_mixers] = alc260_hp_mixer;
spec->num_mixers++;
break;
+ case ALC260_FUJITSU_S702x:
+ spec->mixers[spec->num_mixers] = alc260_fujitsu_mixer;
+ spec->num_mixers++;
+ break;
default:
spec->mixers[spec->num_mixers] = alc260_base_mixer;
spec->num_mixers++;
break;
}
- spec->init_verbs[0] = alc260_init_verbs;
- spec->num_init_verbs = 1;
+ if (board_config != ALC260_FUJITSU_S702x) {
+ spec->init_verbs[0] = alc260_init_verbs;
+ spec->num_init_verbs = 1;
+ } else {
+ spec->init_verbs[0] = alc260_fujitsu_init_verbs;
+ spec->num_init_verbs = 1;
+ }
spec->channel_mode = alc260_modes;
spec->num_channel_mode = ARRAY_SIZE(alc260_modes);
@@ -2397,7 +2496,11 @@
spec->multiout.num_dacs = ARRAY_SIZE(alc260_dac_nids);
spec->multiout.dac_nids = alc260_dac_nids;
- spec->input_mux = &alc260_capture_source;
+ if (board_config != ALC260_FUJITSU_S702x) {
+ spec->input_mux = &alc260_capture_source;
+ } else {
+ spec->input_mux = &alc260_fujitsu_capture_source;
+ }
switch (board_config) {
case ALC260_HP:
spec->num_adc_nids = ARRAY_SIZE(alc260_hp_adc_nids);
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-12 0:10 ` Jonathan Woithe
@ 2005-09-12 10:24 ` Takashi Iwai
2005-09-13 0:16 ` Jonathan Woithe
2005-09-15 0:15 ` Jonathan Woithe
0 siblings, 2 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-12 10:24 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Mon, 12 Sep 2005 09:40:05 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > I'll do a patch up along these lines in the next day or so unless you advise
> > > that there is a better way.
> > Agreed. You need just to put your ssid there. Go ahead!
>
> Find attached a patch which adds support for the ALC260 as it is connected
> in a Fujitsu S7020 laptop (and probably the S7021 too). A new
> initialisation verb list is defined which sets up the somewhat unexpected
> use of the ALC260 pins:
> Headphone pin -> Internal speaker
> mic 1 pin -> mic/LineIn jack
> line 1 pin -> LineOut jack
> CD pin -> Internal CD drive audio
Thanks for a patch!
> As far as I can tell these are the only pins connected and in use. Thus
> the others are effectively turned off.
>
> The number of mixer controls have been reduced to include only the pins
> which actually do something. The control names reflect the above usage
> rather than the ALC260 pins they control. These control names appear to do
> the right thing for the ALSA and OSS apps I've tested (audacity, aplay,
> wavplay plus some OSS things I've written).
Well, I feel some mixer names are unconventional, namely, "LineOut
Playback Volume", "Mic/LineIn Playback Volume", "BeepGen Playback
Volume", "IntSpeaker Playback Volume". They can't work with OSS
emulation (unless you adjust manually a proc file) -- although you
claim that it works.
- "LineOut" isn't "Headphone"? In most cases, the icon shown around
such an output jack indicates a headphone indeed.
- "Mic/LineIn" can be either "Mic" or "Line". I think the former is
better. If you stick with both, "Mic/Line".
- "IntSpeaker" is "Internal Speaker".
- "BeepGen" is either "PC Speaker" or "Beep".
> Capture is enabled for the mic 1 and CD pins.
>
> The patch is against alsa-kernel/pci/hda/patch_realtek.c from 1.0.10rc1 but
> I expect it will apply trivially to CVS. If there's a problem let me know.
>
> The new mixer/initialisation is only activated if the subsystem vendor
> and device IDs match those in the S7020, since there's no guarantee that
> other Fujitsu models will share this device layout. I figure things can
> always be relaxed later if it turns out this applies to other models.
Let's add a new model string so that people can test this model on
other devices, too.
> The only outstanding mixer-related issue is control of the headphone amp
> associated with the LineOut jack. In essence the ALC260 Line 1 pin has a
> headphone amp which can be enabled to drive headphones harder than can be
> done without it. However, the noise level increases if this is done, so if
> the output is being fed to other equipment it's better to leave the amp off.
> It would be nice to be able to turn this amp on and off dynamically but the
> mixer API doesn't appear to have the ability to do this (although I'm still
> looking). The alternative is to define a new module option which turns the
> amp on if the user requests it. I'm still working on this and will submit a
> patch addressing this if I can come up with something sensible.
The mixer API can. Simply add a control like "Headhpone Amplifer
Switch", or so. (I guess you mean to turn on/off HP pin control bit?)
Not worthy to add a module option at all. This is exactly a job of
mixer/control API.
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-12 10:24 ` Takashi Iwai
@ 2005-09-13 0:16 ` Jonathan Woithe
2005-09-13 11:04 ` Takashi Iwai
2005-09-15 0:15 ` Jonathan Woithe
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-13 0:16 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > As far as I can tell these are the only pins connected and in use. Thus
> > the others are effectively turned off.
> >
> > The number of mixer controls have been reduced to include only the pins
> > which actually do something. The control names reflect the above usage
> > rather than the ALC260 pins they control. These control names appear to do
> > the right thing for the ALSA and OSS apps I've tested (audacity, aplay,
> > wavplay plus some OSS things I've written).
>
> Well, I feel some mixer names are unconventional, namely, "LineOut
> Playback Volume", "Mic/LineIn Playback Volume", "BeepGen Playback
> Volume", "IntSpeaker Playback Volume". They can't work with OSS
> emulation (unless you adjust manually a proc file) -- although you
> claim that it works.
OSS emulation definitely seems to work fine for me - wavplay and audacity
certainly do the right thing. Admittedly I haven't attempted to use a full
OSS *mixer* application since I don't have one handy, so perhaps there might
be some gremlins in there.
> - "LineOut" isn't "Headphone"? In most cases, the icon shown around
> such an output jack indicates a headphone indeed.
On this laptop at leat the associated jack can be either a Line-Out or a
headphone output. The difference is whether the on-chip headphone amplifier
is enabled or not. Enabling this amplifier increases the noise level, so
having the amplifier permanently enabled is not a generic solution since it
degrades performance for those of us who will be using the jack as a
line-out connection. As the patch stands I do not enable the headphone amp
and so technically that jack really is behaving as a true "line-out" jack.
That is why I used "LineOut" as the mixer name.
I guess we could call this control "headphone", but my thought was that
given the dual nature of the jack this could get confusing.
For me I have no real use for the headphone amp but perhaps I'm in the
minority. What I might do is enable the amp by default but add a mixer
switch which, if unset, turns off the headphone amp and turns the jack into
a true lineout jack. Then the control could be called "headphone" with the
understanding that the "headphone" control was a true line-level output if
this kernel parameter is supplied. What do you think?
> - "Mic/LineIn" can be either "Mic" or "Line". I think the former is
> better. If you stick with both, "Mic/Line".
I like "Mic/Line" rather than just "Mic" - "mic" is misleading since the
jack is very definitely labelled as "Mic/Line" and does a good job of
accepting line-level input.
> - "IntSpeaker" is "Internal Speaker".
Ok, I wasn't aware that there was a formal name for this. I only used
"IntSpeaker" simply because it fitted into the space allocated for the name
in alsamixer. :)
>
> - "BeepGen" is either "PC Speaker" or "Beep".
I'd go with "beep" simply because "PC Speaker" could confuse users who might
think it was referring to the internal speaker output rather than the beep
input. Again, I wasn't aware that "Beep" existed as part of the convention.
> > The new mixer/initialisation is only activated if the subsystem vendor
> > and device IDs match those in the S7020, since there's no guarantee that
> > other Fujitsu models will share this device layout. I figure things can
> > always be relaxed later if it turns out this applies to other models.
>
> Let's add a new model string so that people can test this model on
> other devices, too.
No worries.
> > The only outstanding mixer-related issue is control of the headphone amp
> > associated with the LineOut jack. In essence the ALC260 Line 1 pin has a
> > headphone amp which can be enabled to drive headphones harder than can be
> > done without it. However, the noise level increases if this is done, so if
> > the output is being fed to other equipment it's better to leave the amp off.
> > It would be nice to be able to turn this amp on and off dynamically but the
> > mixer API doesn't appear to have the ability to do this (although I'm still
> > looking). The alternative is to define a new module option which turns the
> > amp on if the user requests it. I'm still working on this and will submit a
> > patch addressing this if I can come up with something sensible.
>
> The mixer API can. Simply add a control like "Headhpone Amplifer
> Switch", or so. (I guess you mean to turn on/off HP pin control bit?)
Yes, it's the HP pin control bit that's the issue here. I wasn't aware that
the mixer API could control that as well, which could be my fault for
jumping in to this without trying very hard to find documentation. :-)
Ok, I'll distil all this and rework the patch tonight.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-09 10:09 ` Takashi Iwai
2005-09-09 10:42 ` Takashi Iwai
@ 2005-09-13 0:37 ` Jonathan Woithe
2005-09-13 9:27 ` Takashi Iwai
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-13 0:37 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
Hi Takashi
> > > Anyway, I added the check of DMA position in the latest CVS code
> > > yesterday. Please give a shot with the latest CVS version.
> >
> > I did this overnight. The CVS snapshot was taken on 7 Sept 2005 at around
> > 1600 local time (UT+0930). I tried it both with and without the
> > position_fixed module parameter.
> >
> > Without the position_fixed module parameter, playback via aplay was crackly.
> > This is new - aplay playback under 1.0.10rc1 without the position_fixed
> > parameter was fine. Playback via wavplay (OSS interface) was however *much*
> > worse than it used to be. Whereas under 1.0.10rc1 it would simply be
> > crackly, under the CVS snapshot large chunks of audio were being skipped. I
> > didn't have a change to quantify it, but it seemed to me that perhaps every
> > second block of data was being skipped.
>
> Interesting. Then the DMA position is somewhat weird.
>
> > Next I retried with the position_fixed=1 parameter. Both aplay (native alsa)
> > and wavplay (oss emulation) produced clean signal in this case, so the
> > position_fixed=1 has not changed in the CVS snapshot compared to 1.0.10rc1.
>
> No, it's not changed. The only position_fix=0 (default value) is
> changed. On CVS, the DMA position is compared with the expected value
> and corrected only if necessary.
Ok, that explains why the non-default case behaved the same as it always has.
> Anyway, the below is another fix. Now the DMA position check is done
> with every position_fix value, but the corrected only with
> position_fix=0. Compile with debug option, so that you can see debug
> messages.
> :
> RCS file: /home/iwai/cvs/alsa/alsa-kernel/pci/hda/hda_intel.c,v
> retrieving revision 1.24
> :
This I did. This new patch (which I applied against my 7 Sept CVS snapshot)
seems to have removed the crackles from the aplay test case. However, the
OSS playback via wavplay was unchanged - large blocks of audio were skipped
on a regular basis.
> Also, try another value of position_fix. Currently,
>
> 0 = auto check the value and correct with fifo size if needed
> if the value is over a fifo size, turns to posbuf mode
> 1 = none use a register value as it is
> 2 = posbuf use a position-buffer
> 3 = fifo always correct with the fifo size (corresponds to 0 in
> the earlier version)
I also did this. Values of 1, 2 and 3 all appeared to result in clean audio
output from both aplay (native ALSA API) and wavplay (OSS emulation). Only
the default setting caused the skips when OSS emulation was in use.
I enabled ALSA's debugging options including verbose printk. However, no
hda-intel DMA messages (as contained in this revised patch) were written to
the log at all which was odd. I did see other printd()/printdd() messages
associated with hda-intel (prepare calls etc) so the debug code was
definitely compiled in.
Regards
jonathan
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-13 0:37 ` Jonathan Woithe
@ 2005-09-13 9:27 ` Takashi Iwai
2005-09-15 0:51 ` Jonathan Woithe
0 siblings, 1 reply; 29+ messages in thread
From: Takashi Iwai @ 2005-09-13 9:27 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Tue, 13 Sep 2005 10:07:59 +0930 (CST),
Jonathan Woithe wrote:
>
> > Also, try another value of position_fix. Currently,
> >
> > 0 = auto check the value and correct with fifo size if needed
> > if the value is over a fifo size, turns to posbuf mode
> > 1 = none use a register value as it is
> > 2 = posbuf use a position-buffer
> > 3 = fifo always correct with the fifo size (corresponds to 0 in
> > the earlier version)
>
> I also did this. Values of 1, 2 and 3 all appeared to result in clean audio
> output from both aplay (native ALSA API) and wavplay (OSS emulation). Only
> the default setting caused the skips when OSS emulation was in use.
>
> I enabled ALSA's debugging options including verbose printk. However, no
> hda-intel DMA messages (as contained in this revised patch) were written to
> the log at all which was odd. I did see other printd()/printdd() messages
> associated with hda-intel (prepare calls etc) so the debug code was
> definitely compiled in.
snd_printd() appears only when compiled with CONFIG_SND_DEBUG=yes.
snd_printdd() when CONFIG_SND_DEBUG_DETECT=yes.
They correspond to --with-debug=full and --with-debug=detect in the
case of alsa-driver's configure script option.
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-13 0:16 ` Jonathan Woithe
@ 2005-09-13 11:04 ` Takashi Iwai
0 siblings, 0 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-13 11:04 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Tue, 13 Sep 2005 09:46:51 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > As far as I can tell these are the only pins connected and in use. Thus
> > > the others are effectively turned off.
> > >
> > > The number of mixer controls have been reduced to include only the pins
> > > which actually do something. The control names reflect the above usage
> > > rather than the ALC260 pins they control. These control names appear to do
> > > the right thing for the ALSA and OSS apps I've tested (audacity, aplay,
> > > wavplay plus some OSS things I've written).
> >
> > Well, I feel some mixer names are unconventional, namely, "LineOut
> > Playback Volume", "Mic/LineIn Playback Volume", "BeepGen Playback
> > Volume", "IntSpeaker Playback Volume". They can't work with OSS
> > emulation (unless you adjust manually a proc file) -- although you
> > claim that it works.
>
> OSS emulation definitely seems to work fine for me - wavplay and audacity
> certainly do the right thing. Admittedly I haven't attempted to use a full
> OSS *mixer* application since I don't have one handy, so perhaps there might
> be some gremlins in there.
Of course, the control API influences only on OSS mixer API :)
I'm sure that it won't work properly.
> > - "LineOut" isn't "Headphone"? In most cases, the icon shown around
> > such an output jack indicates a headphone indeed.
>
> On this laptop at leat the associated jack can be either a Line-Out or a
> headphone output. The difference is whether the on-chip headphone amplifier
> is enabled or not. Enabling this amplifier increases the noise level, so
> having the amplifier permanently enabled is not a generic solution since it
> degrades performance for those of us who will be using the jack as a
> line-out connection. As the patch stands I do not enable the headphone amp
> and so technically that jack really is behaving as a true "line-out" jack.
> That is why I used "LineOut" as the mixer name.
>
> I guess we could call this control "headphone", but my thought was that
> given the dual nature of the jack this could get confusing.
>
> For me I have no real use for the headphone amp but perhaps I'm in the
> minority. What I might do is enable the amp by default but add a mixer
> switch which, if unset, turns off the headphone amp and turns the jack into
> a true lineout jack. Then the control could be called "headphone" with the
> understanding that the "headphone" control was a true line-level output if
> this kernel parameter is supplied. What do you think?
I don't like a kernel parameter for controlling these things.
An additional switch as I mentioned should suffice, no?
Again, if you think the dual label "Line/Headphone" is inevitable, you
can implement like that.
> > - "Mic/LineIn" can be either "Mic" or "Line". I think the former is
> > better. If you stick with both, "Mic/Line".
>
> I like "Mic/Line" rather than just "Mic" - "mic" is misleading since the
> jack is very definitely labelled as "Mic/Line" and does a good job of
> accepting line-level input.
>
> > - "IntSpeaker" is "Internal Speaker".
>
> Ok, I wasn't aware that there was a formal name for this. I only used
> "IntSpeaker" simply because it fitted into the space allocated for the name
> in alsamixer. :)
> >
> > - "BeepGen" is either "PC Speaker" or "Beep".
>
> I'd go with "beep" simply because "PC Speaker" could confuse users who might
> think it was referring to the internal speaker output rather than the beep
> input. Again, I wasn't aware that "Beep" existed as part of the convention.
>
> > > The new mixer/initialisation is only activated if the subsystem vendor
> > > and device IDs match those in the S7020, since there's no guarantee that
> > > other Fujitsu models will share this device layout. I figure things can
> > > always be relaxed later if it turns out this applies to other models.
> >
> > Let's add a new model string so that people can test this model on
> > other devices, too.
>
> No worries.
>
> > > The only outstanding mixer-related issue is control of the headphone amp
> > > associated with the LineOut jack. In essence the ALC260 Line 1 pin has a
> > > headphone amp which can be enabled to drive headphones harder than can be
> > > done without it. However, the noise level increases if this is done, so if
> > > the output is being fed to other equipment it's better to leave the amp off.
> > > It would be nice to be able to turn this amp on and off dynamically but the
> > > mixer API doesn't appear to have the ability to do this (although I'm still
> > > looking). The alternative is to define a new module option which turns the
> > > amp on if the user requests it. I'm still working on this and will submit a
> > > patch addressing this if I can come up with something sensible.
> >
> > The mixer API can. Simply add a control like "Headhpone Amplifer
> > Switch", or so. (I guess you mean to turn on/off HP pin control bit?)
>
> Yes, it's the HP pin control bit that's the issue here. I wasn't aware that
> the mixer API could control that as well, which could be my fault for
> jumping in to this without trying very hard to find documentation. :-)
>
> Ok, I'll distil all this and rework the patch tonight.
OK, thanks.
Takashi
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-12 10:24 ` Takashi Iwai
2005-09-13 0:16 ` Jonathan Woithe
@ 2005-09-15 0:15 ` Jonathan Woithe
2005-09-16 18:13 ` Takashi Iwai
1 sibling, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-15 0:15 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
[-- Attachment #1: Type: text/plain, Size: 2935 bytes --]
Hi Takashi
> > Find attached a patch which adds support for the ALC260 as it is connected
> > in a Fujitsu S7020 laptop (and probably the S7021 too). A new
> > initialisation verb list is defined which sets up the somewhat unexpected
> > use of the ALC260 pins:
> > Headphone pin -> Internal speaker
> > mic 1 pin -> mic/LineIn jack
> > line 1 pin -> LineOut jack
> > CD pin -> Internal CD drive audio
>
> Thanks for a patch!
:
> Well, I feel some mixer names are unconventional, namely, "LineOut
> Playback Volume", "Mic/LineIn Playback Volume", "BeepGen Playback
> Volume", "IntSpeaker Playback Volume". They can't work with OSS
> emulation (unless you adjust manually a proc file) -- although you
> claim that it works.
Find attached a revised patch which addresses this. I've relented and
renamed "LineOut" to "Headphone" in the interests of conformance.
"Mic/LineIn" I've renamed to "Mic/Line" as you suggested. If we have to
drop the dual name then I think we should call the input "Line" since that's
really what it is. "IntSpeaker" and "BeepGen" are now "Internal Speaker"
and "Beep" respectively, as per your suggestions.
Again, the patch is relative to 1.0.10rc1.
> > The new mixer/initialisation is only activated if the subsystem vendor
> > and device IDs match those in the S7020, since there's no guarantee that
> > other Fujitsu models will share this device layout. I figure things can
> > always be relaxed later if it turns out this applies to other models.
>
> Let's add a new model string so that people can test this model on
> other devices, too.
Done - it's "fujitsu".
> > The only outstanding mixer-related issue is control of the headphone amp
> > associated with the LineOut jack. In essence the ALC260 Line 1 pin has a
> > headphone amp which can be enabled to drive headphones harder than can be
> > done without it. However, the noise level increases if this is done, so if
> > the output is being fed to other equipment it's better to leave the amp off.
> > It would be nice to be able to turn this amp on and off dynamically but the
> > mixer API doesn't appear to have the ability to do this (although I'm still
> > looking). The alternative is to define a new module option which turns the
> > amp on if the user requests it. I'm still working on this and will submit a
> > patch addressing this if I can come up with something sensible.
>
> The mixer API can. Simply add a control like "Headhpone Amplifer
> Switch", or so. (I guess you mean to turn on/off HP pin control bit?)
I've now added such a switch (which also required some new get/put functions
to make it happen - I couldn't find any existing functions which drove the
Realtek pin widget controls after basic initialisation). I called the
control "Headphone Amp Switch" but feel free to expand this to "Headphone
Amplifier Switch" if you think it's better - I'm not fussed.
Regards
jonathan
[-- Attachment #2: ASCII C program text --]
[-- Type: text/plain, Size: 8377 bytes --]
--- patch_realtek.c-orig 2005-08-16 04:31:40.000000000 +0930
+++ patch_realtek.c 2005-09-15 01:04:45.000000000 +0930
@@ -57,6 +57,7 @@
enum {
ALC260_BASIC,
ALC260_HP,
+ ALC260_FUJITSU_S702x,
ALC260_MODEL_LAST /* last tag */
};
@@ -72,6 +73,7 @@
#define PIN_VREF50 0x21
#define PIN_OUT 0x40
#define PIN_HP 0xc0
+#define PIN_HP_AMP 0x80
struct alc_spec {
/* codec parameterization */
@@ -284,6 +286,54 @@
#define ALC_BIND_MUTE(xname,nid,indices,dir) ALC_BIND_MUTE_MONO(xname,nid,3,indices,dir)
+/*
+ * Control of pin widget settings via the mixer. Only boolean settings are
+ * supported, so VrefEn can't be controlled using these functions as they
+ * stand.
+ */
+static int alc_pinctl_switch_info(snd_kcontrol_t *kcontrol, snd_ctl_elem_info_t *uinfo)
+{
+ uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
+ uinfo->count = 1;
+ uinfo->value.integer.min = 0;
+ uinfo->value.integer.max = 1;
+ return 0;
+}
+
+static int alc_pinctl_switch_get(snd_kcontrol_t *kcontrol, snd_ctl_elem_value_t *ucontrol)
+{
+ struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+ hda_nid_t nid = kcontrol->private_value & 0xffff;
+ long mask = (kcontrol->private_value >> 16) & 0xff;
+ long *valp = ucontrol->value.integer.value;
+
+ *valp = 0;
+ if (snd_hda_codec_read(codec,nid,0,AC_VERB_GET_PIN_WIDGET_CONTROL,0x00) & mask)
+ *valp = 1;
+ return 0;
+}
+
+static int alc_pinctl_switch_put(snd_kcontrol_t *kcontrol, snd_ctl_elem_value_t *ucontrol)
+{
+ struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+ hda_nid_t nid = kcontrol->private_value & 0xffff;
+ long mask = (kcontrol->private_value >> 16) & 0xff;
+ long *valp = ucontrol->value.integer.value;
+ unsigned int pinctl = snd_hda_codec_read(codec,nid,0,AC_VERB_GET_PIN_WIDGET_CONTROL,0x00);
+ int change = ((pinctl & mask)!=0) != *valp;
+
+ if (change)
+ snd_hda_codec_write(codec,nid,0,AC_VERB_SET_PIN_WIDGET_CONTROL,
+ *valp?(pinctl|mask):(pinctl&~mask));
+ return change;
+}
+
+#define ALC_PINCTL_SWITCH(xname, nid, mask) \
+ { .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, .index = 0, \
+ .info = alc_pinctl_switch_info, \
+ .get = alc_pinctl_switch_get, \
+ .put = alc_pinctl_switch_put, \
+ .private_value = (nid) | (mask<<16) }
/*
* ALC880 3-stack model
@@ -2209,6 +2259,17 @@
},
};
+/* On Fujitsu S702x laptops capture only makes sense from Mic/LineIn jack
+ * and the internal CD lines.
+ */
+static struct hda_input_mux alc260_fujitsu_capture_source = {
+ .num_items = 2,
+ .items = {
+ { "Mic/Line", 0x0 },
+ { "CD", 0x4 },
+ },
+};
+
/*
* This is just place-holder, so there's something for alc_build_pcms to look
* at when it calculates the maximum number of channels. ALC260 has no mixer
@@ -2275,6 +2336,30 @@
{ } /* end */
};
+static snd_kcontrol_new_t alc260_fujitsu_mixer[] = {
+ HDA_CODEC_VOLUME("Headphone Playback Volume", 0x08, 0x0, HDA_OUTPUT),
+ ALC_BIND_MUTE("Headphone Playback Switch", 0x08, 2, HDA_INPUT),
+ ALC_PINCTL_SWITCH("Headphone Amp Switch", 0x14, PIN_HP_AMP),
+ HDA_CODEC_VOLUME("CD Playback Volume", 0x07, 0x04, HDA_INPUT),
+ HDA_CODEC_MUTE("CD Playback Switch", 0x07, 0x04, HDA_INPUT),
+ HDA_CODEC_VOLUME("Mic/Line Playback Volume", 0x07, 0x0, HDA_INPUT),
+ HDA_CODEC_MUTE("Mic/Line Playback Switch", 0x07, 0x0, HDA_INPUT),
+ HDA_CODEC_VOLUME("Beep Playback Volume", 0x07, 0x05, HDA_INPUT),
+ HDA_CODEC_MUTE("Beep Playback Switch", 0x07, 0x05, HDA_INPUT),
+ HDA_CODEC_VOLUME("Internal Speaker Playback Volume", 0x09, 0x0, HDA_OUTPUT),
+ ALC_BIND_MUTE("Internal Speaker Playback Switch", 0x09, 2, HDA_INPUT),
+ HDA_CODEC_VOLUME("Capture Volume", 0x04, 0x0, HDA_INPUT),
+ HDA_CODEC_MUTE("Capture Switch", 0x04, 0x0, HDA_INPUT),
+ {
+ .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+ .name = "Capture Source",
+ .info = alc_mux_enum_info,
+ .get = alc_mux_enum_get,
+ .put = alc_mux_enum_put,
+ },
+ { } /* end */
+};
+
static struct hda_verb alc260_init_verbs[] = {
/* Line In pin widget for input */
{0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
@@ -2336,6 +2421,60 @@
{ }
};
+/* Initialisation sequence for ALC260 as configured in Fujitsu S702x
+ * laptops.
+ */
+static struct hda_verb alc260_fujitsu_init_verbs[] = {
+ /* Disable all GPIOs */
+ {0x01, AC_VERB_SET_GPIO_MASK, 0},
+ /* Internal speaker is connected to headphone pin */
+ {0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP},
+ /* Headphone/Line-out jack connects to Line1 pin; make it an output */
+ {0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_OUT},
+ /* Mic/Line-in jack is connected to mic1 pin, so make it an input */
+ {0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
+ /* Ensure all other unused pins are disabled and muted.
+ * Note: trying to set widget 0x15 to anything blocks all audio
+ * output for some reason, so just leave that at the default.
+ */
+ {0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+ {0x0f, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ {0x11, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+ {0x11, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ {0x13, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+ {0x13, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ /* Disable digital (SPDIF) pins */
+ {0x03, AC_VERB_SET_DIGI_CONVERT_1, 0},
+ {0x06, AC_VERB_SET_DIGI_CONVERT_1, 0},
+
+ /* Start with mixer outputs muted */
+ {0x08, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
+ {0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
+ {0x0a, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE},
+
+ /* Unmute HP pin widget amp left and right (no equiv mixer ctrl) */
+ {0x10, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
+ /* Unmute Line1 pin widget amp left and right (no equiv mixer ctrl) */
+ {0x14, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
+ /* Unmute pin widget used for Line-in (no equiv mixer ctrl) */
+ {0x12, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
+
+ /* Mute capture amp left and right */
+ {0x04, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+ /* Set ADC connection select to line in (on mic1 pin) */
+ {0x04, AC_VERB_SET_CONNECT_SEL, 0x00},
+
+ /* Mute all inputs to mixer widget (even unconnected ones) */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, /* mic1 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)}, /* mic2 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(2)}, /* line1 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(3)}, /* line2 pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(4)}, /* CD pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(5)}, /* Beep-gen pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(6)}, /* Line-out pin */
+ {0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(7)}, /* HP-pin pin */
+};
+
static struct hda_pcm_stream alc260_pcm_analog_playback = {
.substreams = 1,
.channels_min = 2,
@@ -2351,6 +2490,8 @@
static struct hda_board_config alc260_cfg_tbl[] = {
{ .modelname = "hp", .config = ALC260_HP },
{ .pci_subvendor = 0x103c, .config = ALC260_HP },
+ { .modelname = "fujitsu", .config = ALC260_FUJITSU_S702x },
+ { .pci_subvendor = 0x10cf, .pci_subdevice = 0x1326, .config = ALC260_FUJITSU_S702x },
{}
};
@@ -2377,14 +2518,23 @@
spec->mixers[spec->num_mixers] = alc260_hp_mixer;
spec->num_mixers++;
break;
+ case ALC260_FUJITSU_S702x:
+ spec->mixers[spec->num_mixers] = alc260_fujitsu_mixer;
+ spec->num_mixers++;
+ break;
default:
spec->mixers[spec->num_mixers] = alc260_base_mixer;
spec->num_mixers++;
break;
}
- spec->init_verbs[0] = alc260_init_verbs;
- spec->num_init_verbs = 1;
+ if (board_config != ALC260_FUJITSU_S702x) {
+ spec->init_verbs[0] = alc260_init_verbs;
+ spec->num_init_verbs = 1;
+ } else {
+ spec->init_verbs[0] = alc260_fujitsu_init_verbs;
+ spec->num_init_verbs = 1;
+ }
spec->channel_mode = alc260_modes;
spec->num_channel_mode = ARRAY_SIZE(alc260_modes);
@@ -2397,7 +2547,11 @@
spec->multiout.num_dacs = ARRAY_SIZE(alc260_dac_nids);
spec->multiout.dac_nids = alc260_dac_nids;
- spec->input_mux = &alc260_capture_source;
+ if (board_config != ALC260_FUJITSU_S702x) {
+ spec->input_mux = &alc260_capture_source;
+ } else {
+ spec->input_mux = &alc260_fujitsu_capture_source;
+ }
switch (board_config) {
case ALC260_HP:
spec->num_adc_nids = ARRAY_SIZE(alc260_hp_adc_nids);
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-13 9:27 ` Takashi Iwai
@ 2005-09-15 0:51 ` Jonathan Woithe
2005-09-15 23:29 ` Jonathan Woithe
0 siblings, 1 reply; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-15 0:51 UTC (permalink / raw
To: Takashi Iwai; +Cc: Jonathan Woithe, alsa-devel
> > > Also, try another value of position_fix. Currently,
> > >
> > > 0 = auto check the value and correct with fifo size if needed
> > > if the value is over a fifo size, turns to posbuf mode
> > > 1 = none use a register value as it is
> > > 2 = posbuf use a position-buffer
> > > 3 = fifo always correct with the fifo size (corresponds to 0 in
> > > the earlier version)
> >
> > I also did this. Values of 1, 2 and 3 all appeared to result in clean audio
> > output from both aplay (native ALSA API) and wavplay (OSS emulation). Only
> > the default setting caused the skips when OSS emulation was in use.
> >
> > I enabled ALSA's debugging options including verbose printk. However, no
> > hda-intel DMA messages (as contained in this revised patch) were written to
> > the log at all which was odd. I did see other printd()/printdd() messages
> > associated with hda-intel (prepare calls etc) so the debug code was
> > definitely compiled in.
>
> snd_printd() appears only when compiled with CONFIG_SND_DEBUG=yes.
> snd_printdd() when CONFIG_SND_DEBUG_DETECT=yes.
> They correspond to --with-debug=full and --with-debug=detect in the
> case of alsa-driver's configure script option.
Yep, noted. When I was testing the above both CONFIG_SND_DEBUG and
CONFIG_SND_DEBUG_DETECT were set to "yes" in config.h.
I'll doublecheck this again tonight since I think it a bit odd that
1, 2 and 3 all seemed to work while 0 didn't.
Regards
jonathan
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Re: hda-intel/ALC260: crackly playback and DC offset on recording
2005-09-15 0:51 ` Jonathan Woithe
@ 2005-09-15 23:29 ` Jonathan Woithe
0 siblings, 0 replies; 29+ messages in thread
From: Jonathan Woithe @ 2005-09-15 23:29 UTC (permalink / raw
Cc: Takashi Iwai, Jonathan Woithe, alsa-devel
Further to my email yesterday:
> > > > Also, try another value of position_fix. Currently,
> > > >
> > > > 0 = auto check the value and correct with fifo size if needed
> > > > if the value is over a fifo size, turns to posbuf mode
> > > > 1 = none use a register value as it is
> > > > 2 = posbuf use a position-buffer
> > > > 3 = fifo always correct with the fifo size (corresponds to 0 in
> > > > the earlier version)
> > >
> > > I also did this. Values of 1, 2 and 3 all appeared to result in clean audio
> > > output from both aplay (native ALSA API) and wavplay (OSS emulation). Only
> > > the default setting caused the skips when OSS emulation was in use.
> > >
> > > I enabled ALSA's debugging options including verbose printk. However, no
> > > hda-intel DMA messages (as contained in this revised patch) were written to
> > > the log at all which was odd. I did see other printd()/printdd() messages
> > > associated with hda-intel (prepare calls etc) so the debug code was
> > > definitely compiled in.
> :
> I'll doublecheck this again tonight since I think it a bit odd that
> 1, 2 and 3 all seemed to work while 0 didn't.
FYI I retested this last night with the same results as noted above.
Regards
jonathan
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: hda-intel/ALC260: mixer control issues
2005-09-15 0:15 ` Jonathan Woithe
@ 2005-09-16 18:13 ` Takashi Iwai
0 siblings, 0 replies; 29+ messages in thread
From: Takashi Iwai @ 2005-09-16 18:13 UTC (permalink / raw
To: Jonathan Woithe; +Cc: alsa-devel
At Thu, 15 Sep 2005 09:45:01 +0930 (CST),
Jonathan Woithe wrote:
>
> Hi Takashi
>
> > > Find attached a patch which adds support for the ALC260 as it is connected
> > > in a Fujitsu S7020 laptop (and probably the S7021 too). A new
> > > initialisation verb list is defined which sets up the somewhat unexpected
> > > use of the ALC260 pins:
> > > Headphone pin -> Internal speaker
> > > mic 1 pin -> mic/LineIn jack
> > > line 1 pin -> LineOut jack
> > > CD pin -> Internal CD drive audio
> >
> > Thanks for a patch!
> :
> > Well, I feel some mixer names are unconventional, namely, "LineOut
> > Playback Volume", "Mic/LineIn Playback Volume", "BeepGen Playback
> > Volume", "IntSpeaker Playback Volume". They can't work with OSS
> > emulation (unless you adjust manually a proc file) -- although you
> > claim that it works.
>
> Find attached a revised patch which addresses this. I've relented and
> renamed "LineOut" to "Headphone" in the interests of conformance.
> "Mic/LineIn" I've renamed to "Mic/Line" as you suggested. If we have to
> drop the dual name then I think we should call the input "Line" since that's
> really what it is. "IntSpeaker" and "BeepGen" are now "Internal Speaker"
> and "Beep" respectively, as per your suggestions.
>
> Again, the patch is relative to 1.0.10rc1.
>
> > > The new mixer/initialisation is only activated if the subsystem vendor
> > > and device IDs match those in the S7020, since there's no guarantee that
> > > other Fujitsu models will share this device layout. I figure things can
> > > always be relaxed later if it turns out this applies to other models.
> >
> > Let's add a new model string so that people can test this model on
> > other devices, too.
>
> Done - it's "fujitsu".
>
> > > The only outstanding mixer-related issue is control of the headphone amp
> > > associated with the LineOut jack. In essence the ALC260 Line 1 pin has a
> > > headphone amp which can be enabled to drive headphones harder than can be
> > > done without it. However, the noise level increases if this is done, so if
> > > the output is being fed to other equipment it's better to leave the amp off.
> > > It would be nice to be able to turn this amp on and off dynamically but the
> > > mixer API doesn't appear to have the ability to do this (although I'm still
> > > looking). The alternative is to define a new module option which turns the
> > > amp on if the user requests it. I'm still working on this and will submit a
> > > patch addressing this if I can come up with something sensible.
> >
> > The mixer API can. Simply add a control like "Headhpone Amplifer
> > Switch", or so. (I guess you mean to turn on/off HP pin control bit?)
>
> I've now added such a switch (which also required some new get/put functions
> to make it happen - I couldn't find any existing functions which drove the
> Realtek pin widget controls after basic initialisation). I called the
> control "Headphone Amp Switch" but feel free to expand this to "Headphone
> Amplifier Switch" if you think it's better - I'm not fussed.
OK, I applied it to ALSA tree now.
Thanks!
Takashi
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server.
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2005-09-16 18:13 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-01 23:35 hda-intel/ALC260: mixer control issues Jonathan Woithe
2005-09-02 10:00 ` Takashi Iwai
2005-09-05 0:18 ` Jonathan Woithe
2005-09-05 10:35 ` Takashi Iwai
2005-09-06 0:24 ` Jonathan Woithe
2005-09-06 9:38 ` Takashi Iwai
2005-09-07 0:02 ` Jonathan Woithe
2005-09-07 8:44 ` Takashi Iwai
2005-09-08 0:57 ` Jonathan Woithe
2005-09-08 9:14 ` Takashi Iwai
2005-09-08 23:43 ` Jonathan Woithe
2005-09-12 0:10 ` Jonathan Woithe
2005-09-12 10:24 ` Takashi Iwai
2005-09-13 0:16 ` Jonathan Woithe
2005-09-13 11:04 ` Takashi Iwai
2005-09-15 0:15 ` Jonathan Woithe
2005-09-16 18:13 ` Takashi Iwai
2005-09-05 0:29 ` hda-intel/ALC260: crackly playback and DC offset on recording Jonathan Woithe
2005-09-05 10:38 ` Takashi Iwai
2005-09-06 0:07 ` Jonathan Woithe
2005-09-06 9:44 ` Takashi Iwai
2005-09-06 23:58 ` Jonathan Woithe
2005-09-09 0:08 ` Jonathan Woithe
2005-09-09 10:09 ` Takashi Iwai
2005-09-09 10:42 ` Takashi Iwai
2005-09-13 0:37 ` Jonathan Woithe
2005-09-13 9:27 ` Takashi Iwai
2005-09-15 0:51 ` Jonathan Woithe
2005-09-15 23:29 ` Jonathan Woithe
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.