[PATCH] Add support for Acer TravelMate and similar laptops

[PATCH] Add support for Acer TravelMate and similar laptops

[Rimas Kudelis]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

Hi all,

Attached here is a patch that adds an Acer model to the HDA codec 
driver. It assumes that Jonathan's patch (posted here on 23 Feb 2006 
11:18:26 +1030 (CST)) has already been applied, so it applies on top 
of it.

I have tested the patch with my mom's Acer (erased 
/var/lib/alsa/asound.state, then cold-rebooted the computer), 
everything seems to be working fine.

The patch itself is much cleaner than the one attached to bug 1618. It 
doesn't clutter the mixer with useless controls, and starts up with 
settings more appropriate for an Acer.

Also, please note the "(?)"'s next to CD and Beep controls. These 
controls don't actually influence anything now, but I suspect they 
would work after a few more GPIO commands are issued, so I've left 
them there for now (read below).

Btw, this patch also fixes a few comment typos in patch_realtek.c and 
changes one setting in test model (it seems like inicially copy-pasted 
from Fujitsu model). Also, it adds lines muting NID 0x15 for Fujitsu 
model on startup (Jonathan, you said it turned out not to be 
problematic at all).

Takashi, would you please commit this to upstream (along with 
Jonathan's patch)?

Jonathan, how about your idea to add GPIO controls to the test model? 
I think it would help testing. Hopefully, after these are added, I 
could modify the Acer model in a way that CD and Beep controls would 
become useful. Or, if playing with GPIO would seem useless, I could 
simply remove those controls out of the mixer at all.

Now a few notes/questions:
* is there any reason in defining ADC NIDs for every model separately? 
They seem to be the same anyways, and not to get in anyones way. Or do 
they?
* There seems to be a mixup between tab-indented and space-indented 
lines. It was like that at least in Fujitsu init verbs definition, and 
now i've partially copied it to Acer...
* If the jack is called "Line In", should I leave it as "Line" in 
mixer, or should I name it "Line In"?
* What's your opinion about adding a model configuration line that 
would only check the subvendor (and ignore the subdevice setting)? 
There would be more chances to autodetect an Acer laptop then, but 
OTOH, if one day there'll be an ALC-260 based Acer with a different 
config, you'd risk to misdetect, or to regress in automatic Acer 
detectlion by removing that line...

bye,

Rimas

[-- Attachment #2: patch_realtek.after-jwoithe.diff --]
[-- Type: text/plain, Size: 9591 bytes --]

--- alsa-kernel/pci/hda/patch_realtek.c.orig	2006-02-26 23:50:48.000000000 +0200
+++ alsa-kernel/pci/hda/patch_realtek.c	2006-02-26 23:27:13.000000000 +0200
@@ -64,6 +64,7 @@
 	ALC260_HP,
 	ALC260_HP_3013,
 	ALC260_FUJITSU_S702X,
+	ALC260_ACER,
 #ifdef CONFIG_SND_DEBUG
 	ALC260_TEST,
 #endif
@@ -2424,6 +2425,11 @@
 	0x04, 0x05
 };
 
+static hda_nid_t alc260_acer_adc_nids[2] = {
+	/* ADC0, ADC1 */
+	0x04, 0x05
+};
+
 #define ALC260_DIGOUT_NID	0x03
 #define ALC260_DIGIN_NID	0x06
 
@@ -2449,6 +2455,19 @@
 	},
 };
 
+/* Acer TravelMate(/Extensa/Aspire) notebooks have similar configutation to
+ * the Fujitsu S702x, but jacks are marked differently. We won't allow
+ * retasking the Headphone jack, so it won't be available here.
+ */
+static struct hda_input_mux alc260_acer_capture_source = {
+	.num_items = 3,
+	.items = {
+		{ "Mic", 0x0 },
+		{ "Line", 0x2 },
+		{ "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
@@ -2466,6 +2485,7 @@
  * HP: base_output + input + capture_alt
  * HP_3013: hp_3013 + input + capture
  * fujitsu: fujitsu + capture
+ * acer: acer + capture
  */
 
 static struct snd_kcontrol_new alc260_base_output_mixer[] = {
@@ -2524,6 +2544,22 @@
 	{ } /* end */
 };
 
+static struct snd_kcontrol_new alc260_acer_mixer[] = {
+	HDA_CODEC_VOLUME("Master Playback Volume", 0x08, 0x0, HDA_OUTPUT),
+	HDA_BIND_MUTE("Master 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 Playback Volume", 0x07, 0x0, HDA_INPUT),
+	HDA_CODEC_MUTE("Mic Playback Switch", 0x07, 0x0, HDA_INPUT),
+	ALC_PIN_MODE("Mic Jack Mode", 0x12, ALC_PIN_DIR_IN),
+	HDA_CODEC_VOLUME("Line Playback Volume", 0x07, 0x02, HDA_INPUT),
+	HDA_CODEC_MUTE("Line Playback Switch", 0x07, 0x02, HDA_INPUT),
+	ALC_PIN_MODE("Line Jack Mode", 0x14, ALC_PIN_DIR_INOUT),
+	HDA_CODEC_VOLUME("Beep (?) Playback Volume", 0x07, 0x05, HDA_INPUT),
+	HDA_CODEC_MUTE("Beep (?) Playback Switch", 0x07, 0x05, HDA_INPUT),
+	{ } /* end */
+};
+
 /* capture mixer elements */
 static struct snd_kcontrol_new alc260_capture_mixer[] = {
 	HDA_CODEC_VOLUME("Capture Volume", 0x04, 0x0, HDA_INPUT),
@@ -2735,16 +2771,15 @@
 	{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.
-	 */
+        /* Ensure all other unused pins are disabled and muted. */
         {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)},
+	{0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+        {0x15, 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},
@@ -2805,6 +2840,88 @@
 	{ }
 };
 
+/* Initialisation sequence for ALC260 as configured in Acer TravelMate and
+ * similar laptops (adapted from Fujitsu init verbs).
+ */
+static struct hda_verb alc260_acer_init_verbs[] = {
+	/* Without this, the internal speaker and HP jacks are silent */
+	{0x01, AC_VERB_SET_GPIO_MASK, 0x01},
+	{0x01, AC_VERB_SET_GPIO_DIRECTION, 0x01},
+	{0x01, AC_VERB_SET_GPIO_DATA, 0x01},
+	/* Internal speaker/Headphone jack is connected to Line-out pin */
+	{0x0f, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_HP},
+	/* Internal microphone/Mic jack is connected to Mic1 pin */
+	{0x12, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_VREF50},
+	/* Line In jack is connected to Line1 pin */
+	{0x14, AC_VERB_SET_PIN_WIDGET_CONTROL, PIN_IN},
+	/* Ensure all other unused pins are disabled and muted. */
+	{0x10, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+	{0x10, 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)},
+	{0x15, AC_VERB_SET_PIN_WIDGET_CONTROL, 0},
+	{0x15, 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},
+
+	/* Ensure Mic1 and Line1 pin widgets take input from the OUT1 sum 
+	 * bus when acting as outputs.
+	 */
+	{0x0b, AC_VERB_SET_CONNECT_SEL, 0},
+	{0x0d, AC_VERB_SET_CONNECT_SEL, 0},
+
+	/* Start with output sum widgets muted and their output gains at min */
+	{0x08, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+	{0x08, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
+	{0x08, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO},
+	{0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+	{0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
+	{0x09, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO},
+	{0x0a, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+	{0x0a, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(1)},
+	{0x0a, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_ZERO},
+
+        /* Unmute Line-out pin widget amp left and right (no equiv mixer ctrl) */
+        {0x0f, AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_UNMUTE},
+        /* Unmute Mic1 and Line1 pin widget input buffers since they start as
+         * inputs. If the pin mode is changed by the user the pin mode control
+         * will take care of enabling the pin's input/output buffers as needed.
+         * Therefore there's no need to enable the input buffer at this
+         * stage.
+	 */
+        {0x12, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(0)},
+        {0x14, 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 match default mixer setting - mic
+         * (on mic1 pin)
+         */
+        {0x04, AC_VERB_SET_CONNECT_SEL, 0x00},
+
+        /* Do similar with the second ADC: mute capture input amp and
+         * set ADC connection to line (on line1 pin)
+         */
+        {0x05, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
+        {0x05, AC_VERB_SET_CONNECT_SEL, 0x02},
+
+        /* 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 */
+
+	{ }
+};
+
 /* Test configuration for debugging, modelled after the ALC880 test
  * configuration.
  */
@@ -2878,7 +2995,7 @@
 	{0x03, AC_VERB_SET_DIGI_CONVERT_1, 0},
 	{0x06, AC_VERB_SET_DIGI_CONVERT_1, 0},
 
-	/* Ensure mic1, mic2, line1 and line2 pin widget take input from the 
+	/* Ensure mic1, mic2, line1 and line2 pin widgets take input from the 
 	 * OUT1 sum bus when acting as an output.
 	 */
 	{0x0b, AC_VERB_SET_CONNECT_SEL, 0},
@@ -2913,16 +3030,16 @@
 
 	/* Mute capture amp left and right */
 	{0x04, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
-	/* Set ADC connection select to match default mixer setting - line 
-	 * in (on mic1 pin)
+	/* Set ADC connection select to match default mixer setting -
+	 * mic1 pin
 	 */
 	{0x04, AC_VERB_SET_CONNECT_SEL, 0x00},
 
-	/* Do the same for the second ADC: mute capture input amp and
-	 * set ADC connection to line in
+	/* Do similar with the second ADC: mute capture input amp and
+	 * set ADC connection to line1 pin
 	 */
 	{0x05, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)},
-	{0x05, AC_VERB_SET_CONNECT_SEL, 0x00},
+	{0x05, AC_VERB_SET_CONNECT_SEL, 0x02},
 
 	/* Mute all inputs to mixer widget (even unconnected ones) */
 	{0x07, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_MUTE(0)}, /* mic1 pin */
@@ -3221,6 +3338,8 @@
 	{ .pci_subvendor = 0x103c, .pci_subdevice = 0x3016, .config = ALC260_HP },
 	{ .modelname = "fujitsu", .config = ALC260_FUJITSU_S702X },
 	{ .pci_subvendor = 0x10cf, .pci_subdevice = 0x1326, .config = ALC260_FUJITSU_S702X },
+	{ .modelname = "acer", .config = ALC260_ACER },
+	{ .pci_subvendor = 0x1025, .pci_subdevice = 0x008f, .config = ALC260_ACER },
 #ifdef CONFIG_SND_DEBUG
 	{ .modelname = "test", .config = ALC260_TEST },
 #endif
@@ -3281,6 +3400,18 @@
 		.channel_mode = alc260_modes,
 		.input_mux = &alc260_fujitsu_capture_source,
 	},
+	[ALC260_ACER] = {
+		.mixers = { alc260_acer_mixer,
+			    alc260_capture_mixer },
+		.init_verbs = { alc260_acer_init_verbs },
+		.num_dacs = ARRAY_SIZE(alc260_dac_nids),
+		.dac_nids = alc260_dac_nids,
+		.num_adc_nids = ARRAY_SIZE(alc260_acer_adc_nids),
+		.adc_nids = alc260_acer_adc_nids,
+		.num_channel_mode = ARRAY_SIZE(alc260_modes),
+		.channel_mode = alc260_modes,
+		.input_mux = &alc260_acer_capture_source,
+	},
 #ifdef CONFIG_SND_DEBUG
 	[ALC260_TEST] = {
 		.mixers = { alc260_test_mixer,

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Jonathan Woithe]

Hi Rimas

> Also, please note the "(?)"'s next to CD and Beep controls. These 
> controls don't actually influence anything now, but I suspect they 
> would work after a few more GPIO commands are issued, so I've left 
> them there for now (read below).

Stylistically I think the "?" can be omitted, but others might have different
opinions.

> Btw, this patch also fixes a few comment typos in patch_realtek.c and 
> changes one setting in test model (it seems like inicially copy-pasted 
> from Fujitsu model). Also, it adds lines muting NID 0x15 for Fujitsu 
> model on startup (Jonathan, you said it turned out not to be 
> problematic at all).

Please, I would very much like to test this Fujitsu change before it goes
in.  It *appeared* that perhaps with the most recent CVS the omission of
NID 0x15 was not necessary but I have not verified this in the context
of the model-specific initialisation verbs yet.

> Jonathan, how about your idea to add GPIO controls to the test model? 

Hopefully coming early this week. 

> Now a few notes/questions:
> * is there any reason in defining ADC NIDs for every model separately? 
> They seem to be the same anyways, and not to get in anyones way. Or do 
> they?

Up to this point the reason for the differing definitions has been
due to the different ways things needed to use the ADC NIDs.  As part of
a consolidation patch I'm preparing for Takashi I hope to clean this
stuff up a bit.

> * If the jack is called "Line In", should I leave it as "Line" in 
> mixer, or should I name it "Line In"?

What do you think is less confusing?

> * What's your opinion about adding a model configuration line that 
> would only check the subvendor (and ignore the subdevice setting)? 
> There would be more chances to autodetect an Acer laptop then, but 
> OTOH, if one day there'll be an ALC-260 based Acer with a different 
> config, you'd risk to misdetect, or to regress in automatic Acer 
> detectlion by removing that line...

I believe the generally accepted way is to include both.  If the machine
config did change in future there's really no guarantee that the existing
models will just magically work.  It's better to effectively force the new
models to be explicitly tested, and only when they're verified do they get
added to the "known model" list.

In the next day or so I'll be sending a list of pending patches to Takashi
(as requested) so everything can be synced correctly and nothing gets
missed.  Some of these will result in minor changes to the Acer config.  Do
you mind if we hold your patch over until then, and I'll submit it with the
rest?  It will make Takashi's (and my) life easier if we do it this way.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Rimas Kudelis]

Hello Jonathan,

>> Also, please note the "(?)"'s next to CD and Beep controls. These 
>> controls don't actually influence anything now, but I suspect they 
>> would work after a few more GPIO commands are issued, so I've left 
>> them there for now (read below).
> 
> Stylistically I think the "?" can be omitted, but others might have different
> opinions.

I left those as a reminder that these widgets are untested/not working 
yet. If after fiddling with GPIO commands we don't make them work, 
they're useless and IMHO should be removed. If we do make them work, 
they should be renamed.

>> Btw, this patch also fixes a few comment typos in patch_realtek.c and 
>> changes one setting in test model (it seems like inicially copy-pasted 
>> from Fujitsu model). Also, it adds lines muting NID 0x15 for Fujitsu 
>> model on startup (Jonathan, you said it turned out not to be 
>> problematic at all).
> 
> Please, I would very much like to test this Fujitsu change before it goes
> in.  It *appeared* that perhaps with the most recent CVS the omission of
> NID 0x15 was not necessary but I have not verified this in the context
> of the model-specific initialisation verbs yet.

Sure. I was hoping you would test my changes before Takashi commits 
them. :) I should've stated it clearly though...

>> Jonathan, how about your idea to add GPIO controls to the test model? 
> 
> Hopefully coming early this week.
> 
>> Now a few notes/questions:
>> * is there any reason in defining ADC NIDs for every model separately? 
>> They seem to be the same anyways, and not to get in anyones way. Or do 
>> they?
> 
> Up to this point the reason for the differing definitions has been
> due to the different ways things needed to use the ADC NIDs.  As part of
> a consolidation patch I'm preparing for Takashi I hope to clean this
> stuff up a bit.

Very good. I'm eagerly waiting for that. I hope, ALSA 1.0.11 won't 
come out until we're done with ALC260.

>> * If the jack is called "Line In", should I leave it as "Line" in 
>> mixer, or should I name it "Line In"?
> 
> What do you think is less confusing?

I don't actually know. It doesn't make significant difference for me, 
so it's hard to tell. I'm just asking about the policy - is "Line" a 
conventional name in ALSA, or is it a convention to name controls like 
jacks?..

>> * What's your opinion about adding a model configuration line that 
>> would only check the subvendor (and ignore the subdevice setting)? 
>> There would be more chances to autodetect an Acer laptop then, but 
>> OTOH, if one day there'll be an ALC-260 based Acer with a different 
>> config, you'd risk to misdetect, or to regress in automatic Acer 
>> detectlion by removing that line...
> 
> I believe the generally accepted way is to include both.  If the machine
> config did change in future there's really no guarantee that the existing
> models will just magically work.  It's better to effectively force the new
> models to be explicitly tested, and only when they're verified do they get
> added to the "known model" list.

That's what I thought... However, it may as always result in people 
simply using a "model=acer" parameter and not bothering to inform the 
developers about the success. But I think you're right.

> In the next day or so I'll be sending a list of pending patches to Takashi
> (as requested) so everything can be synced correctly and nothing gets
> missed.  Some of these will result in minor changes to the Acer config.  Do
> you mind if we hold your patch over until then, and I'll submit it with the
> rest?  It will make Takashi's (and my) life easier if we do it this way.

Of course I don't mind. You may consider my patch being a sketch which 
you can transform into whatever seems best for you. Of course, I'll 
want to test the results too. :)

Regards,

Rimas


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Takashi Iwai]

At Mon, 27 Feb 2006 00:35:33 +0200,
Rimas Kudelis wrote:
> 
> Hi all,
> 
> Attached here is a patch that adds an Acer model to the HDA codec 
> driver. It assumes that Jonathan's patch (posted here on 23 Feb 2006 
> 11:18:26 +1030 (CST)) has already been applied, so it applies on top 
> of it.
> 
> I have tested the patch with my mom's Acer (erased 
> /var/lib/alsa/asound.state, then cold-rebooted the computer), 
> everything seems to be working fine.
> 
> The patch itself is much cleaner than the one attached to bug 1618. It 
> doesn't clutter the mixer with useless controls, and starts up with 
> settings more appropriate for an Acer.
> 
> Also, please note the "(?)"'s next to CD and Beep controls. These 
> controls don't actually influence anything now, but I suspect they 
> would work after a few more GPIO commands are issued, so I've left 
> them there for now (read below).

I prefer removing '(?)'.  In case you are not sure whether these
controls really work, you can add a comment in the source code or
create a document.

> Btw, this patch also fixes a few comment typos in patch_realtek.c and 
> changes one setting in test model (it seems like inicially copy-pasted 
> from Fujitsu model). Also, it adds lines muting NID 0x15 for Fujitsu 
> model on startup (Jonathan, you said it turned out not to be 
> problematic at all).
> 
> Takashi, would you please commit this to upstream (along with 
> Jonathan's patch)?

Sure, once I got patches for Jonathan, I'll apply yours.


> Jonathan, how about your idea to add GPIO controls to the test model? 
> I think it would help testing. Hopefully, after these are added, I 
> could modify the Acer model in a way that CD and Beep controls would 
> become useful. Or, if playing with GPIO would seem useless, I could 
> simply remove those controls out of the mixer at all.
> 
> Now a few notes/questions:
> * is there any reason in defining ADC NIDs for every model separately? 
> They seem to be the same anyways, and not to get in anyones way. Or do 
> they?
> * There seems to be a mixup between tab-indented and space-indented 

Basically tabs are better.  They are mixed up just as a result of
merge of many different patches.  If you can fix to use tabs, please
do it.

> lines. It was like that at least in Fujitsu init verbs definition, and 
> now i've partially copied it to Acer...
> * If the jack is called "Line In", should I leave it as "Line" in 
> mixer, or should I name it "Line In"?

"Line" would be better since the OSS-emulation code uses this word to
construct the mixer layer.

> * What's your opinion about adding a model configuration line that 
> would only check the subvendor (and ignore the subdevice setting)? 
> There would be more chances to autodetect an Acer laptop then, but 
> OTOH, if one day there'll be an ALC-260 based Acer with a different 
> config, you'd risk to misdetect, or to regress in automatic Acer 
> detectlion by removing that line...

You can set zero to subdevice to compare only subvendor.


Thanks for your work!

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Rimas Kudelis]

Hello,

> I prefer removing '(?)'. In case you are not sure whether these
> controls really work, you can add a comment in the source code or
> create a document.
>   
OK, but I think I'll leave these tasks to Jonathan.

> Sure, once I got patches for Jonathan, I'll apply yours.
>   
There will be no need for that as he said he'll include my patch into
his. After his patch is applied, there will probably be another patch
from me (it should define the final CD and Beep status in mixer). But
that's in future.

> "Line" would be better since the OSS-emulation code uses this word to
> construct the mixer layer.
>   
Then we'll leave it with "Line", as it is now.

> You can set zero to subdevice to compare only subvendor.
I'll keep that in mind. But I'm not sure if that's a good practice at
all (even though I believe it should work).

Rimas



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Takashi Iwai]

At Mon, 27 Feb 2006 15:43:38 +0200,
Rimas Kudelis wrote:
> 
> > You can set zero to subdevice to compare only subvendor.
> I'll keep that in mind. But I'm not sure if that's a good practice at
> all (even though I believe it should work).

Yes, it's indeed a good question.

If a model, say acer, would likey work on the future boards, it's good
to set acer to default with a given subvendor.  For ALC260 it's maybe
fine to set it so since the configuration difference is restricted in
comparison with other codecs like ALC880, and h/w vendors tend to keep
the similar configuration.


Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Jonathan Woithe]

Hi Rimas

As you might have noticed, the consolidation patch eluded to yesterday has
now been posted to alsa-devel.  One of these adds the "acer" model.  Look
for messages with a subject of the form 

  [PATCH] HDA/ALC260: x/7 - ...

where x=1-7.

> >> Jonathan, how about your idea to add GPIO controls to the test model? 
> > Hopefully coming early this week.

This is part of the 7-patch series, along with SPDIF enable switches.

> >> * is there any reason in defining ADC NIDs for every model separately? 
> >> They seem to be the same anyways, and not to get in anyones way. Or do 
> >> they?
> > 
> > Up to this point the reason for the differing definitions has been
> > due to the different ways things needed to use the ADC NIDs.  As part of
> > a consolidation patch I'm preparing for Takashi I hope to clean this
> > stuff up a bit.
> 
> Very good. I'm eagerly waiting for that. I hope, ALSA 1.0.11 won't 
> come out until we're done with ALC260.

There is now a single ADC NID list which can be used by any model which
utilises the "dual ADC" functionality.  The fujitsu model was the only
model using this up to this point; now the newly added acer model does
as well.

> >> * If the jack is called "Line In", should I leave it as "Line" in 
> >> mixer, or should I name it "Line In"?
> > What do you think is less confusing?
> I don't actually know. It doesn't make significant difference for me, 
> so it's hard to tell. I'm just asking about the policy - is "Line" a 
> conventional name in ALSA, or is it a convention to name controls like 
> jacks?..

I've left it as "Line" since in this context it's more consistent with the
rest of ALSA.

> Of course I don't mind. You may consider my patch being a sketch which 
> you can transform into whatever seems best for you. Of course, I'll 
> want to test the results too. :)

Feel free to grab the 7 patches and give them a whirl.  Note that they
are against a recent CVS version of alsa.  Hopefully though it won't be
too long before they show up in CVS.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar

[Jonathan Woithe]

Hi

> > I prefer removing '(?)'. In case you are not sure whether these
> > controls really work, you can add a comment in the source code or
> > create a document.
> OK, but I think I'll leave these tasks to Jonathan.

The "?" is removed in the patchset I sent earlier today.  The issue of
the CD controls can be worked on later once we've consolidated developments
to date.

> > Sure, once I got patches for Jonathan, I'll apply yours.
> >   
> There will be no need for that as he said he'll include my patch into
> his. After his patch is applied, there will probably be another patch
> from me (it should define the final CD and Beep status in mixer). But
> that's in future.

Takashi: just to confirm, the "acer" model *is* included in the 7-patch set
I submitted earlier today (it's patch 5 of 7).

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Rimas Kudelis]

Hello,

The patches are in anonymous CVS already. That's great! :)
> There is now a single ADC NID list which can be used by any model which
> utilises the "dual ADC" functionality.  The fujitsu model was the only
> model using this up to this point; now the newly added acer model does
> as well.
>   
Now another question - is there a reason to list ADC's in reversed order
for HP model? If there's none, I think HP model could simply use the
same list that Fujitsu and Acer now use.


>>>> * If the jack is called "Line In", should I leave it as "Line" in 
>>>> mixer, or should I name it "Line In"?
>>>>         
>>> What do you think is less confusing?
>>>       
>> I don't actually know. It doesn't make significant difference for me, 
>> so it's hard to tell. I'm just asking about the policy - is "Line" a 
>> conventional name in ALSA, or is it a convention to name controls like 
>> jacks?..
>>     
> I've left it as "Line" since in this context it's more consistent with the
> rest of ALSA.
>   
That's great. Takashi has provided us with a good reason to leave it as is.

> Feel free to grab the 7 patches and give them a whirl. Note that they
> are against a recent CVS version of alsa.  Hopefully though it won't be
> too long before they show up in CVS.
As I said, I can already see the changes in
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-kernel/pci/hda/. I think
I'll try them out today. Hopefully, I'll find out whether the CD and
Beep controls actually do anything on Acers at all.

Best regards,
Rimas



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Takashi Iwai]

At Tue, 28 Feb 2006 15:55:05 +0200,
Rimas Kudelis wrote:
> 
> Hello,
> 
> The patches are in anonymous CVS already. That's great! :)
> > There is now a single ADC NID list which can be used by any model which
> > utilises the "dual ADC" functionality.  The fujitsu model was the only
> > model using this up to this point; now the newly added acer model does
> > as well.
> >   
> Now another question - is there a reason to list ADC's in reversed order
> for HP model? If there's none, I think HP model could simply use the
> same list that Fujitsu and Acer now use.

It's just a historical reason.  The original realtek driver did it so,
and I didn't want a possible breakage.  Once after we confirm that it
works regardless of the order, we can reuse the same list. 

Can anyone test it?


thanks,

Takashi


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Rimas Kudelis]

Hello,

>>> There is now a single ADC NID list which can be used by any model which
>>> utilises the "dual ADC" functionality.  The fujitsu model was the only
>>> model using this up to this point; now the newly added acer model does
>>> as well.
>>>       
>> Now another question - is there a reason to list ADC's in reversed order
>> for HP model? If there's none, I think HP model could simply use the
>> same list that Fujitsu and Acer now use.
>>     
> It's just a historical reason.  The original realtek driver did it so,
> and I didn't want a possible breakage.  Once after we confirm that it
> works regardless of the order, we can reuse the same list. 
>
> Can anyone test it?

Would it be enough to test things vice-versa (e.g. swapping them for
acer or test model on an Acer)? ;)

Rimas



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Rimas Kudelis]

Hi Jonathan,

I'm testing the CVS driver now. The Acer model works well. That's cool.
:) A few notes:

1) the CD and Beep controls seem like not doing anything, even after
playing with GPIO pins. If a few more Acer owners confirm this (Paolo?),
I guess these should be removed (or even better, commented out in the
code - in order for someone motivated to fix them). Also, the CD can be
removed from the input sources list if nobody reports CD capture as
working. Pity. That's becoming a pooooooor mixer.. ;)
OTOH, I'm not sure about how my CD player app (XfreeCD) works (while it
works on my Ubuntu desktop where i *know* the CD cable is connected to
the soundcard). I'm not trully sure about how Audio CD playing should
work in general. Do I understand it correctly by assuming that the CPU
doesn't need to be involved in Audio CD playing? My assumption was that
the CD drive simply redirects the bits on the disk to the soundcard, but
i was apearantly oversimplifying things. Maybe the CD drive itself needs
some more "weight" to support this (i.e., some sort of an internal
decoder), and maybe the drive that is present in Acer (Slimtype DVDRW
SOSW-833S) simply doesn't support audio CD hardware decoding, and
expects software to handle this task? That would probably be reasonable
for a slim notebook CD/DVD drive.
I think it would be probably be useful to test Audio CD handling in
Windows with some old-fashioned CD-player... Maybe even on win98 that
could temporarily be installed onto Linux swap partition (I was such a
fool not to try that last weekend)... Does anyone have any other ideas?

2) Capture. It actually works. The noise I referred to previously seems
to be because of a looping sound or something else, I'm not sure. The
thing is that the capturing from Capture channel works even when its
volume is set to zero (or it's simply "muted" in Gnome mixer). All it
needs is to be selected for capture. So when I set its volume to low
enough, the noise disappears, and I can actually record my tapping. The
recording quality is terrible though. but I'm not sure if it's because I
tapped the notebook instead of speaking, or if something is wrong with
the model. Also, I don't quite understand why I can record sound with
zero volume. Jonathan, does recording work smoothly for you?

3) I couldn't find any settings dialog in Gnome Sound Recorder, it only
allows me to run the Gnome mixer in which I can enable the capture
sources. May I suppose it can record from both ADC's simultaneously, if
these are enabled?
Also, after I enable Capture 1 solely, I only record silence.
Furthermore, setting second input source to Line on module load (that's
what I tried to do with the acer model) doesn't work for some reason:
initially, both input sources are still being set to "Mic". Plus, the
last line in the informational box of AlsaMixer v1.0.9a:
> Card: HDA Intel
> Chip: Realtek ALC260
> View:  Playback  Capture [All]
> Item: Input Source 1 1
makes me worry. Concluding all this, I think if noone (Paolo?) reports
Capture 1 as working, It may probably just as well be removed (I guess
this means using alc260_adc_nids instead of alc260_dual_adc_nids on Acers).

4) After toggling SPDIF playback/capture in test model a few times, I
got the following error in dmesg:
> [4300161.577000] ALSA
> /usr/src/alsa-cvs/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:515:
> hda_intel: azx_get_response timeout, switching to single_cmd mode...
Furthermore, the SPDIF controls aren't available in Gnome mixer. I
suppose these controls will need debugging from someone with a real
SPDIF channel handy.

I guess that's all for now. Maybe even too much already. Any thoughts?

Rimas



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Lee Revell]

On Tue, 2006-02-28 at 21:06 +0200, Rimas Kudelis wrote:
> Hi Jonathan,
> 
> I'm testing the CVS driver now. The Acer model works well. That's
> cool.
> :) A few notes:
> 
> 1) the CD and Beep controls seem like not doing anything, even after
> playing with GPIO pins. 

Can you file new bug reports for each remaining issue?  #1618 is getting
too big and the original problem is now resolved.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Jonathan Woithe]

> > > There is now a single ADC NID list which can be used by any model which
> > > utilises the "dual ADC" functionality.  The fujitsu model was the only
> > > model using this up to this point; now the newly added acer model does
> > > as well.
> > >   
> > Now another question - is there a reason to list ADC's in reversed order
> > for HP model? If there's none, I think HP model could simply use the
> > same list that Fujitsu and Acer now use.
> 
> It's just a historical reason.  The original realtek driver did it so,
> and I didn't want a possible breakage.  Once after we confirm that it
> works regardless of the order, we can reuse the same list. 

One thing worth noting is that the different ADCs do have slightly different
input selector maps.  Given the inputs which do differ I doubt the order
makes a great deal of difference, but this would be one thing worth checking
before making a change to the HP model.

The reason why the "dual_adc" NID list is ordered with 0x4 first is because
the capture mixer seems to treat 0x4 as the first ADC, so I figured I'd 
keep things consistent.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Jonathan Woithe]

Hi Rimas

> I'm testing the CVS driver now. The Acer model works well. That's cool.

Excellent news.  Thanks for confirming.

> 1) the CD and Beep controls seem like not doing anything, even after
> playing with GPIO pins. If a few more Acer owners confirm this (Paolo?),
> I guess these should be removed (or even better, commented out in the
> code - in order for someone motivated to fix them).

The beep is unlikely to do anything until someone implements a beep
generator driver somewhere.  I've left the control in there because it does
no harm and might provide the incentive for someone to do so.  The "beep"
control refers to the volume delivered by an on-board beep generator on the
ALC260.  Currently that generator isn't used by ALSA or any other driver and
so that mixer control won't do anything.

I'm not actually sure how one might make use of the beep generator.  If the
system wants to "beep" that's usually initiated from way outside ALSA. 
Precisely how to make that part of the kernel talk to ALSA will need to be
worked out, if it's deemed important enough by someone.

> Also, the CD can be removed from the input sources list if nobody reports
> CD capture as working.

That is true, but it's probaby wise to wait to see what reports come in
first.

> I'm not trully sure about how Audio CD playing should work in general. Do
> I understand it correctly by assuming that the CPU doesn't need to be
> involved in Audio CD playing?

Ordinarily that is correct, yes.

> My assumption was that the CD drive simply redirects the bits on the disk
> to the soundcard, but i was apearantly oversimplifying things.

Normally the CD drive would deliver an analog audio signal to the sound
card, not a digital bitstream.

> Maybe the CD drive itself needs some more "weight" to support this (i.e.,
> some sort of an internal decoder), and maybe the drive that is present in
> Acer (Slimtype DVDRW SOSW-833S) simply doesn't support audio CD hardware
> decoding, and expects software to handle this task? That would probably be
> reasonable for a slim notebook CD/DVD drive.

The "CD" input on the ALC260 is an analog input.  It expects the CD drive to
do all the audio decoding and present an ordinary stereo signal to this pin. 
If when playing a CD and enabling the "CD" control you get no audio that
strongly suggests that there is no audio signal running to that pin.
However, if there is no analog connection to the ALC260 one does wonder
precisely how these systems are expected to play CDs.  The only option 
left would be for software to read the raw CD bitstream (which isn't a straight
audio bitstream), decode it and then send the resulting audio bitstream to
the DAC.  Given that CD drives are more than capable of doing all this it would
surprise me if this were the case.

One thing worth checking though - have you tested *all* ALC260 inputs with
the CD playing?  Maybe Acer connect the CD audio to some other ALC260 pin.

> 2) Capture. It actually works. The noise I referred to previously seems to
> be because of a looping sound or something else, I'm not sure. The thing
> is that the capturing from Capture channel works even when its volume is
> set to zero (or it's simply "muted" in Gnome mixer). All it needs is to be
> selected for capture. So when I set its volume to low enough, the noise
> disappears, and I can actually record my tapping.

The capture gain, when set to minimum, seems to be about unity.  So long as
your signal is of reasonable strength you will not need to increase the
capture control much at all.  As you increase it, especially as it gets
close to the maximum, you will get an increase in noise due to the high
gains being done by the input amplifiers and the relatively noisy electrical
environment they are in.

> The recording quality is terrible though. but I'm not sure if it's because
> I tapped the notebook instead of speaking, or if something is wrong with
> the model.

If this is the internal microphone then I'd say it's because it's an
internal microphone.  Those things in my experience are of very low quality
- even compared to the ADCs in the ALC260. :)

> Also, I don't quite understand why I can record sound with
> zero volume. Jonathan, does recording work smoothly for you?

Absolutely.  I've done several 4 track recordings now and everything works
well.  See above for why recording works with the control set at minimum. 
The point to note is that the control's minimum is not actually "zero
volume" (ie: a gain of minus infinity); rather it represents a gain of maybe
-10 dB or -20 dB, at least on my laptop.  It's also likely that Acer has put
their own amplifier chip between the mic and the ALC260, in which case the
ALC260's control minimum might well represent a higher gain than in my
laptop (and your comments do tend to suggest that this is the case).

> 3) I couldn't find any settings dialog in Gnome Sound Recorder, it only
> allows me to run the Gnome mixer in which I can enable the capture
> sources. May I suppose it can record from both ADC's simultaneously, if
> these are enabled?

Based on my understanding of Gnome Sound Recorder (having never used it) I
don't think so.  Without any settings dialogs I would assume it will record
from the first PCM interface on the first ALSA card it finds (conceptually
"pcm0" if you like).  Even if both capture sources are unmuted (which is all
the alsamixer mute/"enable" control does), software must explicitly open the
second PCM device if it wishes to record from it.  The default would clearly
be not to do this since soundcards can't be assumed to have two PCM capture
devices.

If you wanted to record both ADCs into the same 2 channel sound file, the
recording software itself would have to open both PCMs and do the averaging
itself.  Similarly, to record the second ADC the software must open the
second ADC.

The only other way to record more than one source at once is to use the
"mixer" as the recording source (available only to the ADC with NID 0x5). 
Currently this is not one of the capture sources available in the Fujitsu
model because it adds extra noise to the recordings and I have no use for
recording a mix of different sources in this way.  If I want to record a mix
of signals I'll use an external mixer since it's more flexible and has lower
noise.

Adding the mixer as an input source will require the implementation of
support for different capture lists for different ADCs.  If there is
interest in having this support I'll look into adding this over the next
week or so - let me know.

> Also, after I enable Capture 1 solely, I only record silence.

Yep, because "capture" ("capture 0" if you like) is effectively muted in
this condition and that is all your recorder is probably recording - see
above.  The alsamixer "enable" control for the capture channels is
effectively only a "mute".  It doesn't set up routing to pcm0 and pcm1 as
seen by applications.

If you want to experiment with the second capture source, grab a small
recording applet which allows you to specify the recording device.  Offhand
I can't give any recommendations beyond "batchrec" which I wrote (and use)
myself.  This is an OSS program, so the device to open if you want the
second ADC is /dev/adsp (assuming ALSA's OSS emulation modules are loaded).
You can pick the program up from

  http://www.physics.adelaide.edu.au/~jwoithe/batchrec-1.2.0.tgz

if you're interested.  It's text-mode only.

> Furthermore, setting second input source to Line on module load (that's
> what I tried to do with the acer model) doesn't work for some reason:
> initially, both input sources are still being set to "Mic".

I'm not quite sure I understand what you mean.  Do you mean that you set the
input source to "Line", unload the module and then reload it?  If so then
the behaviour you see is probably correct.  On reload controls are generally
reset to some default.  If you want to restore settings, take a look at
alsactl.  If this isn't the issue please let me know more details.

> Plus, the last line in the informational box of AlsaMixer v1.0.9a:
> > Card: HDA Intel
> > Chip: Realtek ALC260
> > View:  Playback  Capture [All]
> > Item: Input Source 1 1
> makes me worry.

This is interesting; I can't reproduce this on my laptop.  However, I'll
have another go with CVS now that everything's been merged though and let
you know.  What are the corresponding lines for the "Capture" channel?

> Concluding all this, I think if noone (Paolo?) reports Capture 1 as
> working, It may probably just as well be removed (I guess this means using
> alc260_adc_nids instead of alc260_dual_adc_nids on Acers).

I think you'll find that "Capture 1" is working - it's just that none of
your recording software is capable of using it.

> 4) After toggling SPDIF playback/capture in test model a few times, I
> got the following error in dmesg:
> > [4300161.577000] ALSA
> > /usr/src/alsa-cvs/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:515:
> > hda_intel: azx_get_response timeout, switching to single_cmd mode...

Interesting.  You're not running a kernel with Ingo's realtime preemption
patches, are you?

> Furthermore, the SPDIF controls aren't available in Gnome mixer.

I can't really comment - I don't use Gnome mixer.  I'm surprised though;
if they show in alsamixer I would have expected other mixer apps to see them
(unless of course those mixer apps are incomplete).

> I suppose these controls will need debugging from someone with a real
> SPDIF channel handy.

Yep, indeed.  They still shouldn't give that error though since the SPDIF
interface is still present on the ALC260 even if it doesn't have an outside
connection.  I'll look into this too.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and similar laptops

[Lee Revell]

On Wed, 2006-03-01 at 09:52 +1030, Jonathan Woithe wrote:
> The "CD" input on the ALC260 is an analog input.  It expects the CD drive to
> do all the audio decoding and present an ordinary stereo signal to this pin. 
> If when playing a CD and enabling the "CD" control you get no audio that
> strongly suggests that there is no audio signal running to that pin.
> However, if there is no analog connection to the ALC260 one does wonder
> precisely how these systems are expected to play CDs.  The only option 
> left would be for software to read the raw CD bitstream (which isn't a straight
> audio bitstream), decode it and then send the resulting audio bitstream to
> the DAC.  Given that CD drives are more than capable of doing all this it would
> surprise me if this were the case.
> 
> One thing worth checking though - have you tested *all* ALC260 inputs with
> the CD playing?  Maybe Acer connect the CD audio to some other ALC260 pin. 

I would not be surprised if some vendors were leaving out the DAC from
their CD drives, and expect you to play audio CDs in digital mode.  I
believe this is how Windows Media Player works by default (it also
allows it to generate visual effects from the CD audio).  You might just
have to use a player that implements CD playback this way.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Jonathan Woithe]

> On Wed, 2006-03-01 at 09:52 +1030, Jonathan Woithe wrote:
> > The "CD" input on the ALC260 is an analog input.  It expects the CD drive to
> > do all the audio decoding and present an ordinary stereo signal to this pin. 
> > If when playing a CD and enabling the "CD" control you get no audio that
> > strongly suggests that there is no audio signal running to that pin.
> > However, if there is no analog connection to the ALC260 one does wonder
> > precisely how these systems are expected to play CDs.  The only option 
> > left would be for software to read the raw CD bitstream (which isn't a straight
> > audio bitstream), decode it and then send the resulting audio bitstream to
> > the DAC.  Given that CD drives are more than capable of doing all this it would
> > surprise me if this were the case.
> > 
> > One thing worth checking though - have you tested *all* ALC260 inputs with
> > the CD playing?  Maybe Acer connect the CD audio to some other ALC260 pin. 
> 
> I would not be surprised if some vendors were leaving out the DAC from
> their CD drives, and expect you to play audio CDs in digital mode.  I
> believe this is how Windows Media Player works by default (it also
> allows it to generate visual effects from the CD audio).

Ah, right.  I wasn't aware of that.  If that's its default behaviour then
perhaps the Acers do expect the OS to use digital mode for playing CDs. If
this proves to be the case then we'll revise the "acer" model to omit the CD
controls.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Lee Revell]

On Wed, 2006-03-01 at 10:15 +1030, Jonathan Woithe wrote:
> Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> this proves to be the case then we'll revise the "acer" model to omit the CD
> controls.
> 

Can someone verify this by testing both modes under Windows?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Lee Revell]

On Wed, 2006-03-01 at 10:15 +1030, Jonathan Woithe wrote:
> > On Wed, 2006-03-01 at 09:52 +1030, Jonathan Woithe wrote:
> > > The "CD" input on the ALC260 is an analog input.  It expects the CD drive to
> > > do all the audio decoding and present an ordinary stereo signal to this pin. 
> > > If when playing a CD and enabling the "CD" control you get no audio that
> > > strongly suggests that there is no audio signal running to that pin.
> > > However, if there is no analog connection to the ALC260 one does wonder
> > > precisely how these systems are expected to play CDs.  The only option 
> > > left would be for software to read the raw CD bitstream (which isn't a straight
> > > audio bitstream), decode it and then send the resulting audio bitstream to
> > > the DAC.  Given that CD drives are more than capable of doing all this it would
> > > surprise me if this were the case.
> > > 
> > > One thing worth checking though - have you tested *all* ALC260 inputs with
> > > the CD playing?  Maybe Acer connect the CD audio to some other ALC260 pin. 
> > 
> > I would not be surprised if some vendors were leaving out the DAC from
> > their CD drives, and expect you to play audio CDs in digital mode.  I
> > believe this is how Windows Media Player works by default (it also
> > allows it to generate visual effects from the CD audio).
> 
> Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> this proves to be the case then we'll revise the "acer" model to omit the CD
> controls.

Are #1843 and #1847 related to this problem?  Those both involve Acer
systems but with Sigmatel codecs rather than Realtek.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Jonathan Woithe]

Hi Lee

> > > > The "CD" input on the ALC260 is an analog input.  It expects the CD drive to
> > > > do all the audio decoding and present an ordinary stereo signal to this pin. 
> > > > If when playing a CD and enabling the "CD" control you get no audio that
> > > > strongly suggests that there is no audio signal running to that pin.
> > > > However, if there is no analog connection to the ALC260 one does wonder
> > > > precisely how these systems are expected to play CDs.  The only option 
> > > > left would be for software to read the raw CD bitstream (which isn't a straight
> > > > audio bitstream), decode it and then send the resulting audio bitstream to
> > > > the DAC.  Given that CD drives are more than capable of doing all this it would
> > > > surprise me if this were the case.
> > > > 
> > > > One thing worth checking though - have you tested *all* ALC260 inputs with
> > > > the CD playing?  Maybe Acer connect the CD audio to some other ALC260 pin. 
> > > 
> > > I would not be surprised if some vendors were leaving out the DAC from
> > > their CD drives, and expect you to play audio CDs in digital mode.  I
> > > believe this is how Windows Media Player works by default (it also
> > > allows it to generate visual effects from the CD audio).
> > 
> > Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> > perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> > this proves to be the case then we'll revise the "acer" model to omit the CD
> > controls.
> 
> Are #1843 and #1847 related to this problem?  Those both involve Acer
> systems but with Sigmatel codecs rather than Realtek.

Not sure, since we don't yet know for sure that this is the problem with
the 1641 etc.  It *might* still be due to a gremlin lurking in the ALC260
code.  To prove this we probably need someone with the laptops affected by
#1843 and #1847 to test both modes of WMP and report their findings.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Lee Revell]

On Wed, 2006-03-01 at 10:52 +1030, Jonathan Woithe wrote:
> Not sure, since we don't yet know for sure that this is the problem
> with
> the 1641 etc.  It *might* still be due to a gremlin lurking in the
> ALC260
> code.  To prove this we probably need someone with the laptops
> affected by
> #1843 and #1847 to test both modes of WMP and report their findings.
> 

Actually I was wondering if these are related to the original bug from
#1618 not the CD issue.

Do your patches have any effect on Acer machines with HDA intel codecs
other than the ALC260?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Jonathan Woithe]

Hi Lee

> On Wed, 2006-03-01 at 10:52 +1030, Jonathan Woithe wrote:
> > Not sure, since we don't yet know for sure that this is the problem with
> > the 1641 etc.  It *might* still be due to a gremlin lurking in the
> > ALC260 code.  To prove this we probably need someone with the laptops
> > affected by #1843 and #1847 to test both modes of WMP and report their
> > findings.
> 
> Actually I was wondering if these are related to the original bug from
> #1618 not the CD issue.

Ah, oops, sorry.

> Do your patches have any effect on Acer machines with HDA intel codecs
> other than the ALC260?

No.  They only apply to Acer machines with a Realtek ALC260 codec.  Even
if they have a Realtek codec, if it's not an ALC260 then the latest patches
don't apply to the machine.

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Rimas Kudelis]

Jonathan Woithe wrote:
>>> The "CD" input on the ALC260 is an analog input.  It expects the CD drive to
>>> do all the audio decoding and present an ordinary stereo signal to this pin. 
>>> If when playing a CD and enabling the "CD" control you get no audio that
>>> strongly suggests that there is no audio signal running to that pin.
>>> However, if there is no analog connection to the ALC260 one does wonder
>>> precisely how these systems are expected to play CDs.  The only option 
>>> left would be for software to read the raw CD bitstream (which isn't a straight
>>> audio bitstream), decode it and then send the resulting audio bitstream to
>>> the DAC.  Given that CD drives are more than capable of doing all this it would
>>> surprise me if this were the case.
>>>
>>> One thing worth checking though - have you tested *all* ALC260 inputs with
>>> the CD playing?  Maybe Acer connect the CD audio to some other ALC260 pin. 
>>>       
To be honest, I haven't. I thought the CD pin is a bit different from
the others, so I didn't bother to test everything.

>> I would not be surprised if some vendors were leaving out the DAC from
>> their CD drives, and expect you to play audio CDs in digital mode.  I
>> believe this is how Windows Media Player works by default (it also
>> allows it to generate visual effects from the CD audio).
>>     
> Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> this proves to be the case then we'll revise the "acer" model to omit the CD
> controls.
I believe the Gnome CD player and Sound Juicer applications do that too.
I think they, just like all other Gnome apps, use the Gstreamer
framework. And I can even see a reason for that - most soundcards only
have one set of pins for a CD (i.e. only one cd channel) meanwhile many
new desktops come with two CD drives. Add to this what Lee has
mentioned, and you get quite a set of reasons to use software to extract
audio.

Rimas



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Jonathan Woithe]

> >> I would not be surprised if some vendors were leaving out the DAC from
> >> their CD drives, and expect you to play audio CDs in digital mode.  I
> >> believe this is how Windows Media Player works by default (it also
> >> allows it to generate visual effects from the CD audio).
> >>     
> > Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> > perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> > this proves to be the case then we'll revise the "acer" model to omit the CD
> > controls.
> I believe the Gnome CD player and Sound Juicer applications do that too.
> I think they, just like all other Gnome apps, use the Gstreamer
> framework. And I can even see a reason for that - most soundcards only
> have one set of pins for a CD (i.e. only one cd channel) meanwhile many
> new desktops come with two CD drives. Add to this what Lee has
> mentioned, and you get quite a set of reasons to use software to extract
> audio.

Except it sucks CPU cycles away from more useful tasks and is less capable
of correcting errors in realtime (at least in my experience).

Regards
  jonathan


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Lee Revell]

On Thu, 2006-03-02 at 09:19 +1030, Jonathan Woithe wrote:
> > >> I would not be surprised if some vendors were leaving out the DAC from
> > >> their CD drives, and expect you to play audio CDs in digital mode.  I
> > >> believe this is how Windows Media Player works by default (it also
> > >> allows it to generate visual effects from the CD audio).
> > >>     
> > > Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> > > perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> > > this proves to be the case then we'll revise the "acer" model to omit the CD
> > > controls.
> > I believe the Gnome CD player and Sound Juicer applications do that too.
> > I think they, just like all other Gnome apps, use the Gstreamer
> > framework. And I can even see a reason for that - most soundcards only
> > have one set of pins for a CD (i.e. only one cd channel) meanwhile many
> > new desktops come with two CD drives. Add to this what Lee has
> > mentioned, and you get quite a set of reasons to use software to extract
> > audio.
> 
> Except it sucks CPU cycles away from more useful tasks and is less capable
> of correcting errors in realtime (at least in my experience).

Well, those arguments apply to everything vendors do to make their gear
cheaper by offloading work to the CPU - Winmodems, non-mixing
soundcards, etc...  it's just how the industry works these days.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: Re: [PATCH] Add support for Acer TravelMate and

[Lee Revell]

On Thu, 2006-03-02 at 09:19 +1030, Jonathan Woithe wrote:
> > >> I would not be surprised if some vendors were leaving out the DAC from
> > >> their CD drives, and expect you to play audio CDs in digital mode.  I
> > >> believe this is how Windows Media Player works by default (it also
> > >> allows it to generate visual effects from the CD audio).
> > >>     
> > > Ah, right.  I wasn't aware of that.  If that's its default behaviour then
> > > perhaps the Acers do expect the OS to use digital mode for playing CDs. If
> > > this proves to be the case then we'll revise the "acer" model to omit the CD
> > > controls.
> > I believe the Gnome CD player and Sound Juicer applications do that too.
> > I think they, just like all other Gnome apps, use the Gstreamer
> > framework. And I can even see a reason for that - most soundcards only
> > have one set of pins for a CD (i.e. only one cd channel) meanwhile many
> > new desktops come with two CD drives. Add to this what Lee has
> > mentioned, and you get quite a set of reasons to use software to extract
> > audio.
> 
> Except it sucks CPU cycles away from more useful tasks and is less capable
> of correcting errors in realtime (at least in my experience).

I think the "killer app" for this setup is players like iTunes that let
you pop in a CD and play and rip it simultaneously.  It also seems like
it would be easier on the battery to rip the CD at full speed then play
it back from RAM than to keep the drive spinning at 1x for the duration.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642