Discussion:
Bugs on aspire one A150
(too old to reply)
Alan Jenkins
2008-11-08 11:57:11 UTC
Permalink
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
That sounds like a known issue. It has been resolved by "ACPI: EC: revert msleep patch". Happily Len submitted it for mainline this week. You will also find it if you try the acpi-test git tree. We're all hoping 2.6.28 will be much improved in terms of reliable operation of different ECs :).
** 2 - wireless: not to mention the fact that ath5k wasn't installed by default in ubuntu...
wireless more or less works, but kernel log is full of backtraces.
Well, that doesn't tell us much. Did they still happen after upgrading to 2.6.28-rc3? Can we see them?
Was able to connect to my WPA2 access point.
Sometimes wireless fails completely, especially after suspend to ram.
Advanced features like monitor/injection work, but when I changed the card's
mac address it stopped working.
I also noticed that if I then start airodump, then wireless works with new mac.
** 3 - internal mic doesn't work.
tried model=acer, model=auto.
Overall it seems that alsa misprograms O/B realteck
codec.
I talk about this later.
Have same issue on my acer 5720
** 4 - wireless led doesn't work.
ath5k devs, can you fix this?
** 5 - coretemp doesn't show cpu temperature,
I have seen somewhere that atom support same thermal diode as core2
and only patch to detect it is needed.
Please include such path in 2.6.28 if exists.
** 6 - both card readers are missing from lspci, is this normal?
A similar bug has been reported as a regression:

<http://bugzilla.kernel.org/show_bug.cgi?id=11828>

so one assumes that it worked on the machines with linux pre-installed. Hopefully without requiring any hacks.

It seems that for now a workaround may be to pass the option debug_quirks=1 to the sdhci module...

<http://marc.info/?l=linux-kernel&m=122509648027303&w=2>

...or that it may help if you insert an SD card before booting.

Apparently the reporter also investigated pcie hotplug. Probably the BIOS doesn't provide the normal support. You can try "modprobe pciehp pciehp_force=1", maybe it helps the kernel discover the devices. It worked for something else on my EeePC. But then it will reportedly disappear the ethernet controller.

However, at the moment pciehp can cause delays of 10s of seconds during resume.
** 7 - opengl is broken, I tried running neverball in fullscreen, but it shows wrong/corrupted
textures (compiz is running, and working well thought)
Now I installed 2.6.28-rc3 (actually latest -git)
Sadly nothing improved.
* Wireless now drops connection from my WPA2 access point after few minutes.
I changed temporarily its wireless protection to WEP and open mode, and both work
fine, maybe this is related to periodic key exchange WPA does?
* System doesn't reboot/shutdown, just hangs.
Could be this:

<http://bugzilla.kernel.org/show_bug.cgi?id=11942>

As a fix, 8fd145917fb62368a9b80db59562c20576238f5a was reverted from the acpi tree. This has also been submitted to mainline.

Thanks for your work! If you continue with this, I suggest CC'ing <kernel-testers-***@public.gmane.org>. That will help Rafael the regression hunter pick it up.

Alan
Maxim Levitsky
2008-11-09 00:52:05 UTC
Permalink
Post by Alan Jenkins
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
That sounds like a known issue. It has been resolved by "ACPI: EC: revert msleep patch". Happily Len submitted it for mainline this week. You will also find it if you try the acpi-test git tree. We're all hoping 2.6.28 will be much improved in terms of reliable operation of different ECs :).
Yes, this almost fixes all issues with that.
Almost because, it looks like the EC changes screen brightness on his own when battery is plugged/unplugged,
but so does the gnome-power-manager, and thus it still hangs as before on battery removal (but doesn't hang otherwise)
I disabled that behaver in gnome-power-manager and now no more hangs.

I see that this fix fixes the polled mode. Any chance to make irq mode work?
Post by Alan Jenkins
** 2 - wireless: not to mention the fact that ath5k wasn't installed by default in ubuntu...
wireless more or less works, but kernel log is full of backtraces.
Well, that doesn't tell us much. Did they still happen after upgrading to 2.6.28-rc3? Can we see them?
Fixed completely, looking through the git log I have seen a commit that fixes exactly same backtrace I had.
No more errors in kernel log.
Post by Alan Jenkins
Was able to connect to my WPA2 access point.
Sometimes wireless fails completely, especially after suspend to ram.
Advanced features like monitor/injection work, but when I changed the card's
mac address it stopped working.
I also noticed that if I then start airodump, then wireless works with new mac.
This still not fixed, I ask about this again in separate mail.
Post by Alan Jenkins
** 3 - internal mic doesn't work.
tried model=acer, model=auto.
Overall it seems that alsa misprograms O/B realteck
codec.
I talk about this later.
Surprisingly, this is almost fixed.
I can record from both internal mic and external mic
(Quality is not so good, but is the same as in windows)

Almost, is that to increase capture level, I have to set "one" channel of it.
Eg: if I set 100% left and 100% right then capture level is very low.
But when I set 100% left and 0% right or vice versa it works fine.

Also the "mic boost" doesn't change capture volume for internal mic.
also the "mic boost" if set to high value works like analog loopback
(I hear what I say in mic in headphones, same happens on my main notebook acer 5720)
Post by Alan Jenkins
Have same issue on my acer 5720
** 4 - wireless led doesn't work.
ath5k devs, can you fix this?
** 5 - coretemp doesn't show cpu temperature,
I have seen somewhere that atom support same thermal diode as core2
and only patch to detect it is needed.
Please include such path in 2.6.28 if exists.
** 6 - both card readers are missing from lspci, is this normal?
<http://bugzilla.kernel.org/show_bug.cgi?id=11828>
so one assumes that it worked on the machines with linux pre-installed. Hopefully without requiring any hacks.
It seems that for now a workaround may be to pass the option debug_quirks=1 to the sdhci module...
<http://marc.info/?l=linux-kernel&m=122509648027303&w=2>
...or that it may help if you insert an SD card before booting.
Apparently the reporter also investigated pcie hotplug. Probably the BIOS doesn't provide the normal support. You can try "modprobe pciehp pciehp_force=1", maybe it helps the kernel discover the devices. It worked for something else on my EeePC. But then it will reportedly disappear the ethernet controller.
However, at the moment pciehp can cause delays of 10s of seconds during resume.
I am aware of this, but don't yet have a SD card to test.
Post by Alan Jenkins
** 7 - opengl is broken, I tried running neverball in fullscreen, but it shows wrong/corrupted
textures (compiz is running, and working well thought)
Without compiz neveball works fine (slow, but this is very slow hardware)
Post by Alan Jenkins
Now I installed 2.6.28-rc3 (actually latest -git)
Sadly nothing improved.
* Wireless now drops connection from my WPA2 access point after few minutes.
I changed temporarily its wireless protection to WEP and open mode, and both work
fine, maybe this is related to periodic key exchange WPA does?
Now fixed, big thanks.
Post by Alan Jenkins
* System doesn't reboot/shutdown, just hangs.
<http://bugzilla.kernel.org/show_bug.cgi?id=11942>
As a fix, 8fd145917fb62368a9b80db59562c20576238f5a was reverted from the acpi tree. This has also been submitted to mainline.
Also fixed big thanks.




Also noticed another bug:


If I suspend/resume with compiz running, on resume I see wallpaper and mouse cursor, everything hangs for
minute or two, and sometimes forever.

2.6.27 worked fine.




Also hibernate doesn't work on my main notebook, but it is probably fixed, I update kernel to really latest -git
and tell you.


Big thanks for bugfixes, you saved me a lot of work and bisecting.

Biggest solvable problem now is sound support now I think, datasheets are there, and
I take a look at them.


Best regards,
Maxim Levitsky
Takashi Iwai
2008-11-09 08:54:38 UTC
Permalink
[Only about sound stuff, stripped irrelevant addresses from cc]

At Sun, 09 Nov 2008 02:52:05 +0200,
Post by Maxim Levitsky
** 3 - internal mic doesn't work.
tried model=acer, model=auto.
Overall it seems that alsa misprograms O/B realteck
codec.
I talk about this later.
Surprisingly, this is almost fixed.
I can record from both internal mic and external mic
(Quality is not so good, but is the same as in windows)
Almost, is that to increase capture level, I have to set "one" channel of it.
Eg: if I set 100% left and 100% right then capture level is very low.
But when I set 100% left and 0% right or vice versa it works fine.
Also the "mic boost" doesn't change capture volume for internal mic.
also the "mic boost" if set to high value works like analog loopback
(I hear what I say in mic in headphones, same happens on my main notebook acer 5720)
Interesting. Is it with or without model option? There is a model
option specific for aspire one (acer-aspire). Doesn't it work better?

For comparing the hardware setting, please you run alsa-info.sh with
--no-upload option, and attach the generated file at each state. This
shows the real codec register values.

Also, please run the same procedure for acer 5720, too.


thanks,

Takashi
Andreas Mohr
2008-11-09 13:31:12 UTC
Permalink
Hi,
Post by Takashi Iwai
Interesting. Is it with or without model option? There is a model
option specific for aspire one (acer-aspire). Doesn't it work better?
I had already tried 2.6.28-rc3 on A110L (also plus hand-patched digital-mic patch of
patch_realtek.c) and it still didn't work for me.
I didn't use the acer one model parameter, though.

Well, now I just did use it, and it didn't work either AFAICT, with lots
of mixer fumbling again.

And I'm not sure whether the model name should be "acer-aspire" instead
of "acer-aspireone" since Aspire is the name of an entire series
which might possibly have incompatible requirements.
Also, I'm not really happy with the fact that snd_hda_intel doesn't even
log the model name chosen/selected on module initialisation.

Frankly I've had so much snd_hda_intel codec-specific trouble on pretty much all of the
few notebooks/machines that I touched in the last year (that's not an
understatement!) that I think it would be a very nice idea to write a _very_ visible
HOWTO (search words: intel-hda alsa HOWTO codec etc.) detailling how to improve
codec-specific support for snd_hda_intel (this should best be done by explaining
how one arrived at a particular patch for a certain codec, e.g. take the
recent ALC268 work, i.e. check /proc/asound/Intel/codec#0 and look at which part
is not supported by the snd_hda_intel patch file yet and then explain how to add stuff
to it, in very verbose and generic words to let layman people know how to do
this).

As already said, I've (and certainly not only me!) been bitten
again and again and AGAIN by incomplete codec support in snd_hda_intel, thus
we need to make damn sure people can help themselves as well as remotely
possible, to ensure sufficiently fast and sufficiently complete support
for new HDA codecs (which seem to appear each new month or week even,
unfortunately!).
If people don't even know how to tackle this easily, then patch submissions for new
codecs aren't too likely...

And the A110L has been on the shelves for 4 or 5 months already (with 5 to 6
million units sold, they say!!), a time where full support would have been in order.
But it's certainly a major fault of Acer to not have provided full ALSA
support for this (note that I'm not sure about Mic support in its
pre-installed Linpus installation), the ALSA people certainly don't have
any responsibility for this.

Thanks,

Andreas Mohr
Andreas Mohr
2008-11-09 15:13:23 UTC
Permalink
Hi,
Post by Takashi Iwai
Interesting. Is it with or without model option? There is a model
option specific for aspire one (acer-aspire). Doesn't it work better?
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
--> I have to admit that usability sucks^Hcould be a lot better.
It's perfectly fine for ALSA to not have support for newish codecs or newish
machines with weird setups, but basic usability and or documentation
should thus be as good as can be to make sure that weaknesses can get detected
and fixed in no time, even by "interested parties".

i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
Post by Takashi Iwai
For comparing the hardware setting, please you run alsa-info.sh with
--no-upload option, and attach the generated file at each state. This
shows the real codec register values.
OK, here it is (-rc3 with model=acer-aspire):


name=root&type=33&description=/tmp/alsa-info.txt&expiry=&s=Submit+Post&content=
!!################################
!!ALSA Information Script v 0.4.48
!!################################

!!Script ran on: Sun Nov 9 16:00:38 CET 2008


!!Linux Distribution
!!------------------

Ubuntu 8.10 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 8.10"


!!Kernel Information
!!------------------

Kernel release: 2.6.28-rc3
Operating System: GNU/Linux
Architecture: i686
Processor: unknown
SMP Enabled: Yes


!!ALSA Version
!!------------

Driver version: 1.0.18rc3
Library version:
Utilities version: 1.0.17


!!Loaded ALSA modules
!!-------------------

snd_hda_intel


!!Soundcards recognised by ALSA
!!-----------------------------

0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0x38540000 irq 16


!!PCI Soundcards installed in the system
!!--------------------------------------

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)


!!Advanced information - PCI Vendor/Device/Susbsystem ID's
!!--------------------------------------------------------

00:1b.0 0403: 8086:27d8 (rev 02)
Subsystem: 1025:015b


!!Modprobe options (Sound related)
!!--------------------------------

snd-hda-intel: model=acer-aspire
snd-atiixp-modem: index=-2
snd-intel8x0m: index=-2
snd-via82xx-modem: index=-2
snd-usb-audio: index=-2
snd-usb-usx2y: index=-2
snd-usb-caiaq: index=-2
snd-cmipci: mpu_port=0x330 fm_port=0x388
snd-pcsp: index=-2


!!Loaded sound module options
!!--------------------------

!!Module: snd_hda_intel
bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable_msi : 0
id : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>
index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
model : acer-aspire,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>
position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
power_save : 10
power_save_controller : Y
probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
single_cmd : N


!!HDA-Intel Codec information
!!---------------------------
--startcollapse--

Codec: Realtek ALC268
Address: 0
Vendor Id: 0x10ec0268
Subsystem Id: 0x1025015b
Revision Id: 0x100101
No Modem Function Group found
Default PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=4, o=0, i=0, unsolicited=1, wake=0
IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0
Node 0x02 [Audio Output] wcaps 0x1d: Stereo Amp-Out
Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x3a 0x3a]
Converter: stream=0, channel=0
PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Node 0x03 [Audio Output] wcaps 0x1d: Stereo Amp-Out
Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x3a 0x3a]
Converter: stream=0, channel=0
PCM:
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Node 0x04 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0x1e]: 16 20 24 32
formats [0x1]: PCM
Node 0x07 [Audio Input] wcaps 0x100111: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Connection: 1
0x24
Node 0x08 [Audio Input] wcaps 0x100111: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Connection: 1
0x23
Node 0x09 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0c [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0d [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0e [Audio Mixer] wcaps 0x20010a: Mono Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00]
Connection: 1
0x02
Node 0x0f [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Connection: 2
0x02 0x1d
Node 0x10 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80]
Connection: 3
0x03 0x1d 0x02
Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x99a30920: [Fixed] Mic at Int ATAPI
Conn = ATAPI, Color = Unknown
DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Node 0x13 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001003c: IN OUT HP EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
Conn = ATAPI, Color = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 1
0x0f
Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001003c: IN OUT HP EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x0321401f: [Jack] HP Out at Ext Left
Conn = 1/8, Color = Green
DefAssociation = 0x1, Sequence = 0xf
Pin-ctls: 0xc0: OUT HP
Unsolicited: tag=04, enabled=1
Connection: 1
0x10
Node 0x16 [Pin Complex] wcaps 0x40010c: Mono Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80]
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Connection: 1
0x0e
Node 0x17 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x03a19830: [Jack] Mic at Ext Left
Conn = 1/8, Color = Pink
DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=08, enabled=1
Connection: 1
0x02
Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00003724: IN Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=00, enabled=0
Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 1
0x02
Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x1c [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Node 0x1d [Pin Complex] wcaps 0x400000: Mono
Pincap 0x00000020: IN
Pin Default 0x4015812d: [N/A] Speaker at Ext N/A
Conn = Optical, Color = Purple
DefAssociation = 0x2, Sequence = 0xd
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Node 0x1e [Pin Complex] wcaps 0x400380: Mono Digital
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 1
0x06
Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
Processing caps: benign=0, ncoeff=10
Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x22 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x23 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x0a, nsteps=0x1f, stepsize=0x05, mute=1
Amp-Out vals: [0x1f 0x1f]
Connection: 7
0x18 0x19 0x1a 0x1c 0x14 0x15 0x12*
Node 0x24 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x0a, nsteps=0x1f, stepsize=0x05, mute=1
Amp-Out vals: [0x00 0x00]
Connection: 7
0x18* 0x19 0x1a 0x1c 0x14 0x15 0x13
--endcollapse--


!!ALSA Device nodes
!!-----------------

crw-rw----+ 1 root audio 116, 6 2008-11-09 15:59 /dev/snd/controlC0
crw-rw----+ 1 root audio 116, 5 2008-11-09 15:59 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116, 4 2008-11-09 15:59 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio 116, 3 2008-11-09 15:58 /dev/snd/seq
crw-rw----+ 1 root audio 116, 2 2008-11-09 15:58 /dev/snd/timer


!!Aplay/Arecord output
!!------------

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0

!!Amixer output
!!-------------

!!-------Mixer controls for card 0 [Intel]

Simple mixer control 'Master',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 64
Mono:
Front Left: Playback 58 [91%] [-6.00dB] [on]
Front Right: Playback 58 [91%] [-6.00dB] [on]
Simple mixer control 'PCM',0
Capabilities: pvolume
Playback channels: Front Left - Front Right
Limits: Playback 0 - 255
Mono:
Front Left: Playback 255 [100%] [0.00dB]
Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Mic Boost',0
Capabilities: cvolume
Capture channels: Front Left - Front Right
Limits: Capture 0 - 2
Front Left: Capture 0 [0%] [0.00dB]
Front Right: Capture 0 [0%] [0.00dB]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right
Limits: Capture 0 - 31
Front Left: Capture 31 [100%] [31.50dB] [on]
Front Right: Capture 31 [100%] [31.50dB] [on]
Simple mixer control 'Digital',0
Capabilities: cvolume
Capture channels: Front Left - Front Right
Limits: Capture 0 - 120
Front Left: Capture 120 [100%] [30.00dB]
Front Right: Capture 120 [100%] [30.00dB]
Simple mixer control 'Input Source',0
Capabilities: cenum
Items: 'i-Mic' 'E-Mic'
Item0: 'i-Mic'


!!Alsactl output
!!-------------

--startcollapse--
state.Intel {
control.1 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -6400
comment.dbmax 0
iface MIXER
name 'Master Playback Volume'
value.0 58
value.1 58
}
control.2 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Master Playback Switch'
value.0 true
value.1 true
}
control.3 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 2'
comment.dbmin 0
comment.dbmax 4000
iface MIXER
name 'Mic Boost Capture Volume'
value.0 0
value.1 0
}
control.4 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 31'
comment.dbmin -1500
comment.dbmax 3150
iface MIXER
name 'Capture Volume'
value.0 31
value.1 31
}
control.5 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
value.0 true
value.1 true
}
control.6 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 i-Mic
comment.item.1 E-Mic
iface MIXER
name 'Input Source'
value i-Mic
}
control.7 {
comment.access 'read write user'
comment.type INTEGER
comment.count 2
comment.range '0 - 255'
comment.tlv '0000000100000008ffffec1400000014'
comment.dbmin -5100
comment.dbmax 0
iface MIXER
name 'PCM Playback Volume'
value.0 255
value.1 255
}
control.8 {
comment.access 'read write user'
comment.type INTEGER
comment.count 2
comment.range '0 - 120'
comment.tlv '0000000100000008fffff44800000032'
comment.dbmin -3000
comment.dbmax 3000
iface MIXER
name 'Digital Capture Volume'
value.0 120
value.1 120
}
}
--endcollapse--


!!All Loaded Modules
!!------------------

Module
af_packet
i915
drm
binfmt_misc
sco
bridge
stp
llc
rfcomm
bnep
l2cap
bluetooth
ppdev
acpi_cpufreq
cpufreq_stats
pci_slot
cpufreq_ondemand
freq_table
container
cpufreq_userspace
cpufreq_conservative
sbs
sbshc
cpufreq_powersave
microcode
iptable_filter
ip_tables
x_tables
parport_pc
lp
parport
loop
joydev
ipv6
mmc_block
snd_hda_intel
snd_pcm_oss
snd_mixer_oss
acer_wmi
rfkill
snd_pcm
evdev
uvcvideo
compat_ioctl32
videodev
v4l1_compat
snd_seq_dummy
psmouse
serio_raw
arc4
ecb
video
output
sdhci_pci
sdhci
wmi
snd_seq_oss
snd_seq_midi
snd_rawmidi
ath5k
snd_seq_midi_event
mac80211
mmc_core
led_class
cfg80211
snd_seq
battery
ac
button
snd_timer
snd_seq_device
pcspkr
snd
iTCO_wdt
iTCO_vendor_support
soundcore
snd_page_alloc
intel_agp
agpgart
shpchp
pci_hotplug
ext3
jbd
mbcache
sd_mod
crc_t10dif
sg
pata_acpi
ata_generic
ata_piix
libata
ehci_hcd
uhci_hcd
scsi_mod
usbcore
r8169
mii
thermal
processor
fan
fuse





Thanks,

Andreas Mohr
Takashi Iwai
2008-11-09 18:58:17 UTC
Permalink
At Sun, 9 Nov 2008 16:13:23 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
Interesting. Is it with or without model option? There is a model
option specific for aspire one (acer-aspire). Doesn't it work better?
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
Build with the debug option (why turned off even if you *are*
debugging?). Then the driver will show you details.
Post by Andreas Mohr
--> I have to admit that usability sucks^Hcould be a lot better.
One would call it rather debuggability than usability.
These are completely different things.
Post by Andreas Mohr
It's perfectly fine for ALSA to not have support for newish codecs or newish
machines with weird setups, but basic usability and or documentation
should thus be as good as can be to make sure that weaknesses can get detected
and fixed in no time, even by "interested parties".
i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
OK, then something is missing. But you should test by arecord first
than any complicated applications as a primary test.

Anyway, the acer-aspire support code was written by Realtek guys, so
it'd be best to ask them...


thanks,

Takashi
Post by Andreas Mohr
Post by Takashi Iwai
For comparing the hardware setting, please you run alsa-info.sh with
--no-upload option, and attach the generated file at each state. This
shows the real codec register values.
name=root&type=33&description=/tmp/alsa-info.txt&expiry=&s=Submit+Post&content=
!!################################
!!ALSA Information Script v 0.4.48
!!################################
!!Script ran on: Sun Nov 9 16:00:38 CET 2008
!!Linux Distribution
!!------------------
Ubuntu 8.10 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 8.10"
!!Kernel Information
!!------------------
Kernel release: 2.6.28-rc3
Operating System: GNU/Linux
Architecture: i686
Processor: unknown
SMP Enabled: Yes
!!ALSA Version
!!------------
Driver version: 1.0.18rc3
Utilities version: 1.0.17
!!Loaded ALSA modules
!!-------------------
snd_hda_intel
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0x38540000 irq 16
!!PCI Soundcards installed in the system
!!--------------------------------------
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
!!Advanced information - PCI Vendor/Device/Susbsystem ID's
!!--------------------------------------------------------
00:1b.0 0403: 8086:27d8 (rev 02)
Subsystem: 1025:015b
!!Modprobe options (Sound related)
!!--------------------------------
snd-hda-intel: model=acer-aspire
snd-atiixp-modem: index=-2
snd-intel8x0m: index=-2
snd-via82xx-modem: index=-2
snd-usb-audio: index=-2
snd-usb-usx2y: index=-2
snd-usb-caiaq: index=-2
snd-cmipci: mpu_port=0x330 fm_port=0x388
snd-pcsp: index=-2
!!Loaded sound module options
!!--------------------------
!!Module: snd_hda_intel
bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y
enable_msi : 0
id : <NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>
index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
model : acer-aspire,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>,<NULL>
position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
power_save : 10
power_save_controller : Y
probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1
single_cmd : N
!!HDA-Intel Codec information
!!---------------------------
--startcollapse--
Codec: Realtek ALC268
Address: 0
Vendor Id: 0x10ec0268
Subsystem Id: 0x1025015b
Revision Id: 0x100101
No Modem Function Group found
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=4, o=0, i=0, unsolicited=1, wake=0
IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0
IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0
IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0
IO[3]: enable=0, dir=0, wake=0, sticky=0, data=0
Node 0x02 [Audio Output] wcaps 0x1d: Stereo Amp-Out
Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x3a 0x3a]
Converter: stream=0, channel=0
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Node 0x03 [Audio Output] wcaps 0x1d: Stereo Amp-Out
Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0
Amp-Out vals: [0x3a 0x3a]
Converter: stream=0, channel=0
rates [0x560]: 44100 48000 96000 192000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Node 0x04 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x06 [Audio Output] wcaps 0x211: Stereo Digital
Converter: stream=0, channel=0
Digital category: 0x0
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0x1e]: 16 20 24 32
formats [0x1]: PCM
Node 0x07 [Audio Input] wcaps 0x100111: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Connection: 1
0x24
Node 0x08 [Audio Input] wcaps 0x100111: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x1]: PCM
Connection: 1
0x23
Node 0x09 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0c [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0d [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x0e [Audio Mixer] wcaps 0x20010a: Mono Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00]
Connection: 1
0x02
Node 0x0f [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x00 0x00]
Connection: 2
0x02 0x1d
Node 0x10 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-In vals: [0x00 0x00] [0x80 0x80] [0x80 0x80]
Connection: 3
0x03 0x1d 0x02
Node 0x11 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x99a30920: [Fixed] Mic at Int ATAPI
Conn = ATAPI, Color = Unknown
DefAssociation = 0x2, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Node 0x13 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Node 0x14 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001003c: IN OUT HP EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI
Conn = ATAPI, Color = Unknown
DefAssociation = 0x1, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 1
0x0f
Node 0x15 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x00 0x00]
Pincap 0x0001003c: IN OUT HP EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x0321401f: [Jack] HP Out at Ext Left
Conn = 1/8, Color = Green
DefAssociation = 0x1, Sequence = 0xf
Pin-ctls: 0xc0: OUT HP
Unsolicited: tag=04, enabled=1
Connection: 1
0x10
Node 0x16 [Pin Complex] wcaps 0x40010c: Mono Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80]
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Connection: 1
0x0e
Node 0x17 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x03a19830: [Jack] Mic at Ext Left
Conn = 1/8, Color = Pink
DefAssociation = 0x3, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=08, enabled=1
Connection: 1
0x02
Node 0x19 [Pin Complex] wcaps 0x40008b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00003724: IN Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=00, enabled=0
Node 0x1a [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
Amp-In caps: ofs=0x00, nsteps=0x02, stepsize=0x4f, mute=0
Amp-In vals: [0x00 0x00]
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
Amp-Out vals: [0x80 0x80]
Pincap 0x00003734: IN OUT Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN VREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 1
0x02
Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x1c [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x00000020: IN
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Node 0x1d [Pin Complex] wcaps 0x400000: Mono
Pincap 0x00000020: IN
Pin Default 0x4015812d: [N/A] Speaker at Ext N/A
Conn = Optical, Color = Purple
DefAssociation = 0x2, Sequence = 0xd
Misc = NO_PRESENCE
Pin-ctls: 0x20: IN
Node 0x1e [Pin Complex] wcaps 0x400380: Mono Digital
Pincap 0x00000010: OUT
Pin Default 0x411111f0: [N/A] Speaker at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 1
0x06
Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono
Processing caps: benign=0, ncoeff=10
Node 0x21 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x22 [Vendor Defined Widget] wcaps 0xf00000: Mono
Node 0x23 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x0a, nsteps=0x1f, stepsize=0x05, mute=1
Amp-Out vals: [0x1f 0x1f]
Connection: 7
0x18 0x19 0x1a 0x1c 0x14 0x15 0x12*
Node 0x24 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x0a, nsteps=0x1f, stepsize=0x05, mute=1
Amp-Out vals: [0x00 0x00]
Connection: 7
0x18* 0x19 0x1a 0x1c 0x14 0x15 0x13
--endcollapse--
!!ALSA Device nodes
!!-----------------
crw-rw----+ 1 root audio 116, 6 2008-11-09 15:59 /dev/snd/controlC0
crw-rw----+ 1 root audio 116, 5 2008-11-09 15:59 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116, 4 2008-11-09 15:59 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio 116, 3 2008-11-09 15:58 /dev/snd/seq
crw-rw----+ 1 root audio 116, 2 2008-11-09 15:58 /dev/snd/timer
!!Aplay/Arecord output
!!------------
APLAY
**** List of PLAYBACK Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
ARECORD
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC268 Analog [ALC268 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
!!Amixer output
!!-------------
!!-------Mixer controls for card 0 [Intel]
Simple mixer control 'Master',0
Capabilities: pvolume pswitch
Playback channels: Front Left - Front Right
Limits: Playback 0 - 64
Front Left: Playback 58 [91%] [-6.00dB] [on]
Front Right: Playback 58 [91%] [-6.00dB] [on]
Simple mixer control 'PCM',0
Capabilities: pvolume
Playback channels: Front Left - Front Right
Limits: Playback 0 - 255
Front Left: Playback 255 [100%] [0.00dB]
Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Mic Boost',0
Capabilities: cvolume
Capture channels: Front Left - Front Right
Limits: Capture 0 - 2
Front Left: Capture 0 [0%] [0.00dB]
Front Right: Capture 0 [0%] [0.00dB]
Simple mixer control 'Capture',0
Capabilities: cvolume cswitch
Capture channels: Front Left - Front Right
Limits: Capture 0 - 31
Front Left: Capture 31 [100%] [31.50dB] [on]
Front Right: Capture 31 [100%] [31.50dB] [on]
Simple mixer control 'Digital',0
Capabilities: cvolume
Capture channels: Front Left - Front Right
Limits: Capture 0 - 120
Front Left: Capture 120 [100%] [30.00dB]
Front Right: Capture 120 [100%] [30.00dB]
Simple mixer control 'Input Source',0
Capabilities: cenum
Items: 'i-Mic' 'E-Mic'
Item0: 'i-Mic'
!!Alsactl output
!!-------------
--startcollapse--
state.Intel {
control.1 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 64'
comment.dbmin -6400
comment.dbmax 0
iface MIXER
name 'Master Playback Volume'
value.0 58
value.1 58
}
control.2 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Master Playback Switch'
value.0 true
value.1 true
}
control.3 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 2'
comment.dbmin 0
comment.dbmax 4000
iface MIXER
name 'Mic Boost Capture Volume'
value.0 0
value.1 0
}
control.4 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 31'
comment.dbmin -1500
comment.dbmax 3150
iface MIXER
name 'Capture Volume'
value.0 31
value.1 31
}
control.5 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Capture Switch'
value.0 true
value.1 true
}
control.6 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 i-Mic
comment.item.1 E-Mic
iface MIXER
name 'Input Source'
value i-Mic
}
control.7 {
comment.access 'read write user'
comment.type INTEGER
comment.count 2
comment.range '0 - 255'
comment.tlv '0000000100000008ffffec1400000014'
comment.dbmin -5100
comment.dbmax 0
iface MIXER
name 'PCM Playback Volume'
value.0 255
value.1 255
}
control.8 {
comment.access 'read write user'
comment.type INTEGER
comment.count 2
comment.range '0 - 120'
comment.tlv '0000000100000008fffff44800000032'
comment.dbmin -3000
comment.dbmax 3000
iface MIXER
name 'Digital Capture Volume'
value.0 120
value.1 120
}
}
--endcollapse--
!!All Loaded Modules
!!------------------
Module
af_packet
i915
drm
binfmt_misc
sco
bridge
stp
llc
rfcomm
bnep
l2cap
bluetooth
ppdev
acpi_cpufreq
cpufreq_stats
pci_slot
cpufreq_ondemand
freq_table
container
cpufreq_userspace
cpufreq_conservative
sbs
sbshc
cpufreq_powersave
microcode
iptable_filter
ip_tables
x_tables
parport_pc
lp
parport
loop
joydev
ipv6
mmc_block
snd_hda_intel
snd_pcm_oss
snd_mixer_oss
acer_wmi
rfkill
snd_pcm
evdev
uvcvideo
compat_ioctl32
videodev
v4l1_compat
snd_seq_dummy
psmouse
serio_raw
arc4
ecb
video
output
sdhci_pci
sdhci
wmi
snd_seq_oss
snd_seq_midi
snd_rawmidi
ath5k
snd_seq_midi_event
mac80211
mmc_core
led_class
cfg80211
snd_seq
battery
ac
button
snd_timer
snd_seq_device
pcspkr
snd
iTCO_wdt
iTCO_vendor_support
soundcore
snd_page_alloc
intel_agp
agpgart
shpchp
pci_hotplug
ext3
jbd
mbcache
sd_mod
crc_t10dif
sg
pata_acpi
ata_generic
ata_piix
libata
ehci_hcd
uhci_hcd
scsi_mod
usbcore
r8169
mii
thermal
processor
fan
fuse
Thanks,
Andreas Mohr
Andreas Mohr
2008-11-09 20:09:29 UTC
Permalink
Post by Takashi Iwai
At Sun, 9 Nov 2008 16:13:23 +0100,
Post by Andreas Mohr
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
Build with the debug option (why turned off even if you *are*
debugging?). Then the driver will show you details.
Hmm, right, that would have been an (very useful) option, but not for the
majority of users OTOH.
Especially since this is a user-visible module parameter which should thus
be confirmed in mainstream user code, via logging.
Admittedly not many modules log their settings during startup,
but for snd_hda_intel with its two myriads of codec/machine variants
and a resulting quarter myriad of issues that would be very useful.
Post by Takashi Iwai
Post by Andreas Mohr
--> I have to admit that usability sucks^Hcould be a lot better.
One would call it rather debuggability than usability.
These are completely different things.
See above ;)
Post by Takashi Iwai
Post by Andreas Mohr
i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
OK, then something is missing. But you should test by arecord first
than any complicated applications as a primary test.
Good point, will do.

Oh, and is there a way to manually alter codec registers?
Post by Takashi Iwai
Anyway, the acer-aspire support code was written by Realtek guys, so
it'd be best to ask them...
Indeed, and far too late (they have submitted it in September I think)
for guaranteeing non-problematic hardware behaviour...
(I'd guesstimate the Realtek submission to be based on Acer activity)
Anyway, still very nice to see that companies do submit patches after all.

Thanks,

Andreas
Takashi Iwai
2008-11-12 11:08:28 UTC
Permalink
At Sun, 9 Nov 2008 21:09:29 +0100,
Post by Andreas Mohr
Post by Takashi Iwai
At Sun, 9 Nov 2008 16:13:23 +0100,
Post by Andreas Mohr
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
Build with the debug option (why turned off even if you *are*
debugging?). Then the driver will show you details.
Hmm, right, that would have been an (very useful) option, but not for the
majority of users OTOH.
I thought many ditros set this option...
Post by Andreas Mohr
Especially since this is a user-visible module parameter which should thus
be confirmed in mainstream user code, via logging.
You can check via /sys/modules/snd_hda_intel/parameters/model whether
you passed correctly or not, at least :)
Post by Andreas Mohr
Admittedly not many modules log their settings during startup,
but for snd_hda_intel with its two myriads of codec/machine variants
and a resulting quarter myriad of issues that would be very useful.
Passing the model option is already a kind of debugging work, IMO.
You shouldn't do it unless you need it, indeed.
Post by Andreas Mohr
Post by Takashi Iwai
Post by Andreas Mohr
--> I have to admit that usability sucks^Hcould be a lot better.
One would call it rather debuggability than usability.
These are completely different things.
See above ;)
Post by Takashi Iwai
Post by Andreas Mohr
i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
OK, then something is missing. But you should test by arecord first
than any complicated applications as a primary test.
Good point, will do.
Oh, and is there a way to manually alter codec registers?
Try hda-verb program. Build your kernel with CONFIG_SND_HDA_HWDEP=y
and access via the hwdep device.
ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2


Takashi
Maxim Levitsky
2008-11-12 17:07:04 UTC
Permalink
Post by Takashi Iwai
At Sun, 9 Nov 2008 21:09:29 +0100,
Post by Andreas Mohr
Post by Takashi Iwai
At Sun, 9 Nov 2008 16:13:23 +0100,
Post by Andreas Mohr
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
Build with the debug option (why turned off even if you *are*
debugging?). Then the driver will show you details.
Hmm, right, that would have been an (very useful) option, but not for the
majority of users OTOH.
I thought many ditros set this option...
Post by Andreas Mohr
Especially since this is a user-visible module parameter which should thus
be confirmed in mainstream user code, via logging.
You can check via /sys/modules/snd_hda_intel/parameters/model whether
you passed correctly or not, at least :)
Post by Andreas Mohr
Admittedly not many modules log their settings during startup,
but for snd_hda_intel with its two myriads of codec/machine variants
and a resulting quarter myriad of issues that would be very useful.
Passing the model option is already a kind of debugging work, IMO.
You shouldn't do it unless you need it, indeed.
Post by Andreas Mohr
Post by Takashi Iwai
Post by Andreas Mohr
--> I have to admit that usability sucks^Hcould be a lot better.
One would call it rather debuggability than usability.
These are completely different things.
See above ;)
Post by Takashi Iwai
Post by Andreas Mohr
i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
OK, then something is missing. But you should test by arecord first
than any complicated applications as a primary test.
Good point, will do.
Oh, and is there a way to manually alter codec registers?
Try hda-verb program. Build your kernel with CONFIG_SND_HDA_HWDEP=y
and access via the hwdep device.
ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2
Takashi
Hi,

I pretty much studied the datasheet and driver, and this is what I found:
btw, my acer 5720 and aspire one share same ALC268.
Some stuff is trivially fixable, some seems to be unfixable at all:

model=acer is used on my regular laptop.
model-acer-aspire is used on aspire one laptop, and it needs to be renamed, as both are aspire.


1) internal beep volume/mute isn't preserved on resume on acer (I call the big laptop this way).
2) aspire one, has same beep routing, but it isn't supported by this model, it should be added I think.

3) on acer internal mic is mapped wrongly, it assumes that it is a digital mic, while in fact this is
analog mic, and pin configs are set correctly, but they are ignored. fix is trivial, but might break other laptops.
Maybe add this as a new input, like analog mic, at least it can be added for aspire 5720.


4) There is really no internal mic boost on aspire, it is digital, not a bug.

5) Codec supports two ADCs, and so does the driver, but for some models second ADC is ignored.
alc268_capture_alt_mixer is used instead of alc268_capture_mixer.

Here on acer both ADCs are present, and it might be worth to use them both (record from line in and mic)
on aspire one there is only external and internal mic, probably doesn't worth it.

6) Codec supports two DACs too, so it is in theory possible to play different streams on speakers and headphones.
2nd DAC is connected only to headphones, while 1st DAC is connected to all. But here on acer they reversed the connections
and connected speakers to headphones output and headphones to speakers, so probably useless, and besides this doesn't worth the trouble probably.

7) SPDIF is supported on my notebook, but no by the driver, don't yet have a device to test it againt thought, but adding support should be easy.
it is shared with headphones output.
How we can detect that digital headphones are connected, don't know, probably impossible in hardware.


8) The issue of capture volume on aspire one:
when I try to increase internal mic's volume I have to increase ether left
or right channel but not both.

Well, first of all, aspire one mic is really digital.
then, digital mic inputs are supposed to be connected by two mics each resulting in total
of 4 mics.

ADC multiplexers hide difference between analog and digital pins, but of course digital pins
aren't really processed by ADC in analog sense, their input is probably sampled, and digitaly amplified.
Maybe we really need to use only left or right channel there.
I'll test this more carefully.



And now for unfixable problems:

1) There is strong DC offset on all inputs.
it is even different on left/right and depends on capture volume.
I tried to change the VREF only param that could help, but it doesn't.
I feel that this is hardware flaw.
(It is possible that voltage on inputs is created by circuit made by acer, and then ALC268 amplifies it.)



2) That 'analog loopback' when setting any 'boost' setting to high.
The is no mention of that in datasheets, and thus I strongly suspect that this should be called crosstalk.
I understand the block diagram of the chip and there is no loopback, so this isn't alsa bug.


Lastly I noticed that datasheet mentions so called 'coefficients':
the codecs exposes lots of internal and undocumented registers using set address/ get/set value scheme.
maybe some of above bugs are fixable there, but ether realtek has to provide data for that or reverse engineering of
windows driver is required.

(I will test whenever the above happens in windows, at least the #2)

And I hope those registers are for debuging only.

Best regards,
Maxim Levitsky
Andreas Mohr
2008-11-12 18:05:19 UTC
Permalink
Hi,
Post by Maxim Levitsky
btw, my acer 5720 and aspire one share same ALC268.
Wow, what an extremely in-depth analysis!
I just intended to dive into getting mic routing corrected myself,
thus you saved me a lot of time!
Post by Maxim Levitsky
model=acer is used on my regular laptop.
model-acer-aspire is used on aspire one laptop, and it needs to be renamed, as both are aspire.
+1 (your analysis of both being rather different - as already pondered -
confirms this necessity)
Post by Maxim Levitsky
1) There is strong DC offset on all inputs.
it is even different on left/right and depends on capture volume.
I tried to change the VREF only param that could help, but it doesn't.
I feel that this is hardware flaw.
(It is possible that voltage on inputs is created by circuit made by acer, and then ALC268 amplifies it.)
Sounds like really bad circuit design then.
One would think that the Intel HDA architecture might have builtin
measures to compensate for this if needed? DC offset issues on
soundcards aren't exactly a new phenomenon after all...
Post by Maxim Levitsky
the codecs exposes lots of internal and undocumented registers using set address/ get/set value scheme.
maybe some of above bugs are fixable there, but ether realtek has to provide data for that or reverse engineering of
windows driver is required.
I've actually had a peek at the .inf files since I thought that it would
already contain register values in those registry keys that it creates on
install, but yeah, that's all in-driver it seems.
Probably time to ask Acer about specifics, especially since I didn't spot
any hda-intel changes in their linux-2.6.23.9lw source.

Thank you very much,

Andreas Mohr
Maxim Levitsky
2008-11-14 18:05:30 UTC
Permalink
Post by Andreas Mohr
Hi,
Post by Maxim Levitsky
btw, my acer 5720 and aspire one share same ALC268.
Wow, what an extremely in-depth analysis!
I just intended to dive into getting mic routing corrected myself,
thus you saved me a lot of time!
Post by Maxim Levitsky
model=acer is used on my regular laptop.
model-acer-aspire is used on aspire one laptop, and it needs to be renamed, as both are aspire.
+1 (your analysis of both being rather different - as already pondered -
confirms this necessity)
Post by Maxim Levitsky
1) There is strong DC offset on all inputs.
it is even different on left/right and depends on capture volume.
I tried to change the VREF only param that could help, but it doesn't.
I feel that this is hardware flaw.
(It is possible that voltage on inputs is created by circuit made by acer, and then ALC268 amplifies it.)
Sounds like really bad circuit design then.
One would think that the Intel HDA architecture might have builtin
measures to compensate for this if needed? DC offset issues on
soundcards aren't exactly a new phenomenon after all...
Post by Maxim Levitsky
the codecs exposes lots of internal and undocumented registers using set address/ get/set value scheme.
maybe some of above bugs are fixable there, but ether realtek has to provide data for that or reverse engineering of
windows driver is required.
I've actually had a peek at the .inf files since I thought that it would
already contain register values in those registry keys that it creates on
install, but yeah, that's all in-driver it seems.
Probably time to ask Acer about specifics, especially since I didn't spot
any hda-intel changes in their linux-2.6.23.9lw source.
Thank you very much,
Andreas Mohr
Small update:

1) The dc offset isn't present on aspire one, really is a circuit design bug I guess
2) Internal mic works perfectly on aspire one, can reproduce the strange behaver at all,
Probably this was mixer bug.

So aspire one support is almost, only need to add support to restore beep volume
after resume.


Best regards,
Maxim Levitsky
Maxim Levitsky
2008-11-22 19:00:18 UTC
Permalink
Post by Maxim Levitsky
Post by Andreas Mohr
Hi,
Post by Maxim Levitsky
btw, my acer 5720 and aspire one share same ALC268.
Wow, what an extremely in-depth analysis!
I just intended to dive into getting mic routing corrected myself,
thus you saved me a lot of time!
Post by Maxim Levitsky
model=acer is used on my regular laptop.
model-acer-aspire is used on aspire one laptop, and it needs to be
renamed, as both are aspire.
+1 (your analysis of both being rather different - as already pondered -
confirms this necessity)
Post by Maxim Levitsky
1) There is strong DC offset on all inputs.
it is even different on left/right and depends on capture volume.
I tried to change the VREF only param that could help, but it doesn't.
I feel that this is hardware flaw.
(It is possible that voltage on inputs is created by circuit made by
acer, and then ALC268 amplifies it.)
Sounds like really bad circuit design then.
One would think that the Intel HDA architecture might have builtin
measures to compensate for this if needed? DC offset issues on
soundcards aren't exactly a new phenomenon after all...
Post by Maxim Levitsky
the codecs exposes lots of internal and undocumented registers using
set address/ get/set value scheme.
maybe some of above bugs are fixable there, but ether realtek has to
provide data for that or reverse engineering of
windows driver is required.
I've actually had a peek at the .inf files since I thought that it would
already contain register values in those registry keys that it creates on
install, but yeah, that's all in-driver it seems.
Probably time to ask Acer about specifics, especially since I didn't spot
any hda-intel changes in their linux-2.6.23.9lw source.
Thank you very much,
Andreas Mohr
1) The dc offset isn't present on aspire one, really is a circuit design
bug I guess 2) Internal mic works perfectly on aspire one, can reproduce
the strange behaver at all,
Probably this was mixer bug.
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.

So, this happens always, and _only_ when recording _mono_ sound from internal
mic.

Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .

Best regards,
Maxim Levitsky
Post by Maxim Levitsky
So aspire one support is almost, only need to add support to restore beep volume
after resume.
Best regards,
Maxim Levitsky
Andreas Mohr
2008-11-22 19:43:59 UTC
Permalink
Hi,
Post by Maxim Levitsky
Post by Maxim Levitsky
1) The dc offset isn't present on aspire one, really is a circuit
design bug I guess 2) Internal mic works perfectly on aspire one, can
reproduce the strange behaver at all,
Probably this was mixer bug.
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
Wow, nice analysis!
I had already intended to report that you're #2 who told me that Mic does work
(and I was starting to feel weird since I'm the only one who cannot
get it to work!)
Given your analysis, things start to make a lot more sense now.

That probably means that Ekiga Wizard uses mono input (since it does not work
for me), whereas many other apps use stereo input as (natively!) supported
by this hardware setup?

--> alsa lib bug sounds like a good guess.

Thanks,

Andreas Mohr
Takashi Iwai
2008-11-24 14:35:10 UTC
Permalink
At Sat, 22 Nov 2008 21:00:18 +0200,
Post by Maxim Levitsky
Post by Maxim Levitsky
Post by Andreas Mohr
Hi,
Post by Maxim Levitsky
btw, my acer 5720 and aspire one share same ALC268.
Wow, what an extremely in-depth analysis!
I just intended to dive into getting mic routing corrected myself,
thus you saved me a lot of time!
Post by Maxim Levitsky
model=acer is used on my regular laptop.
model-acer-aspire is used on aspire one laptop, and it needs to be
renamed, as both are aspire.
+1 (your analysis of both being rather different - as already pondered -
confirms this necessity)
Post by Maxim Levitsky
1) There is strong DC offset on all inputs.
it is even different on left/right and depends on capture volume.
I tried to change the VREF only param that could help, but it doesn't.
I feel that this is hardware flaw.
(It is possible that voltage on inputs is created by circuit made by
acer, and then ALC268 amplifies it.)
Sounds like really bad circuit design then.
One would think that the Intel HDA architecture might have builtin
measures to compensate for this if needed? DC offset issues on
soundcards aren't exactly a new phenomenon after all...
Post by Maxim Levitsky
the codecs exposes lots of internal and undocumented registers using
set address/ get/set value scheme.
maybe some of above bugs are fixable there, but ether realtek has to
provide data for that or reverse engineering of
windows driver is required.
I've actually had a peek at the .inf files since I thought that it would
already contain register values in those registry keys that it creates on
install, but yeah, that's all in-driver it seems.
Probably time to ask Acer about specifics, especially since I didn't spot
any hda-intel changes in their linux-2.6.23.9lw source.
Thank you very much,
Andreas Mohr
1) The dc offset isn't present on aspire one, really is a circuit design
bug I guess 2) Internal mic works perfectly on aspire one, can reproduce
the strange behaver at all,
Probably this was mixer bug.
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
What does show with -v option?


Takashi
Andreas Mohr
2009-03-15 09:21:17 UTC
Permalink
Hi,
Post by Takashi Iwai
At Sat, 22 Nov 2008 21:00:18 +0200,
Post by Maxim Levitsky
Post by Maxim Levitsky
Post by Andreas Mohr
Hi,
Post by Maxim Levitsky
btw, my acer 5720 and aspire one share same ALC268.
Wow, what an extremely in-depth analysis!
I just intended to dive into getting mic routing corrected myself,
thus you saved me a lot of time!
Post by Maxim Levitsky
model=acer is used on my regular laptop.
model-acer-aspire is used on aspire one laptop, and it needs to be
renamed, as both are aspire.
+1 (your analysis of both being rather different - as already pondered -
confirms this necessity)
Post by Maxim Levitsky
1) There is strong DC offset on all inputs.
it is even different on left/right and depends on capture volume.
I tried to change the VREF only param that could help, but it doesn't.
I feel that this is hardware flaw.
(It is possible that voltage on inputs is created by circuit made by
acer, and then ALC268 amplifies it.)
Sounds like really bad circuit design then.
One would think that the Intel HDA architecture might have builtin
measures to compensate for this if needed? DC offset issues on
soundcards aren't exactly a new phenomenon after all...
Post by Maxim Levitsky
the codecs exposes lots of internal and undocumented registers using
set address/ get/set value scheme.
maybe some of above bugs are fixable there, but ether realtek has to
provide data for that or reverse engineering of
windows driver is required.
I've actually had a peek at the .inf files since I thought that it would
already contain register values in those registry keys that it creates on
install, but yeah, that's all in-driver it seems.
Probably time to ask Acer about specifics, especially since I didn't spot
any hda-intel changes in their linux-2.6.23.9lw source.
Thank you very much,
Andreas Mohr
1) The dc offset isn't present on aspire one, really is a circuit design
bug I guess 2) Internal mic works perfectly on aspire one, can reproduce
the strange behaver at all,
Probably this was mixer bug.
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
What does show with -v option?
OK, I could fully reproduce this now (sorry for the delay!).

Currently 2.6.28, u8.10, model acer-aspire, libasound2 1.0.17a-0ubuntu4,
libasound2-plugins 1.0.17-0ubuntu5.

Recording from i-Mic does work (minus some pretty annoying background noise)
if in gamix I open either left _or_ right channel of the "Capture" control,
but the more both channel sliders progress towards an (almost) equal level,
the more the recording gets reduced to bit changes distantly resembling
the time curve of the recorded signal (but this is not a linear effect,
only the last 5% difference of the slider are dramatic).
IOW you get a "bit buzzing" which clearly distantly resembles the speech
you recorded, something like
"Hello, Test!" --> "crch........crch......crch..."
"(H).ee.(l)..oooo..(T).eee.(st)."
I'm wondering whether these are MSB bit, not LSB, remains of the original
signal here... (since they are clearly audible which LSB wouldn't be)

Anyway, we clearly have some differential logic of the two channels
here, which certainly shouldn't be the case, IOW most likely a bug.


Working test (Capture sliders NOT equal, recorded signal audible):

***@andinet:~$ arecord -v -D plughw:0 -c1 test.wav
Recording WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
Plug PCM: Rate conversion PCM (48000, sformat=U8)
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : U8
subformat : STD
channels : 1
rate : 8000
exact rate : 8000 (8000/1)
msbits : 8
buffer_size : 2730
period_size : 682
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 682
period_event : 0
start_threshold : 1
stop_threshold : 2730
silence_threshold: 0
silence_size : 0
boundary : 178913280
Slave: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0*0.5 + 1*0.5
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : U8
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 8
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 6
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 6
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
^CAborted by signal Interrupt...
***@andinet:~$ aplay test.wav
Playing WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
***@andinet:~$



Non-working test (Capture sliders are equal):

***@andinet:~$ arecord -v -D plughw:0 -c1 test.wav
Recording WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
Plug PCM: Rate conversion PCM (48000, sformat=U8)
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : U8
subformat : STD
channels : 1
rate : 8000
exact rate : 8000 (8000/1)
msbits : 8
buffer_size : 2730
period_size : 682
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 682
period_event : 0
start_threshold : 1
stop_threshold : 2730
silence_threshold: 0
silence_size : 0
boundary : 178913280
Slave: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0*0.5 + 1*0.5
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : U8
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 8
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 6
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
Slave: Hardware PCM card 0 'HDA Intel' device 0 subdevice 0
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 16384
period_size : 4096
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 4096
period_event : 0
start_threshold : 6
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
^CAborted by signal Interrupt...
***@andinet:~$ aplay test.wav
Playing WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
***@andinet:~$


I did a diff of the two test logs above, and they were identical.


Ekiga recording test does work with the sliders being opposite,
but audio quality in general is very poor and buggy (only the first
seconds were played back audibly, and in general the speakers have some
background noise which is being switched on/off from time to time at will,
and somehow the whole codec / setup doesn't seem solid).

Any ideas?

Will now try to upgrade to newer ALSA userspace at least.

Thanks,

Andreas Mohr
Andreas Mohr
2009-03-16 12:03:12 UTC
Permalink
Hi,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Sat, 22 Nov 2008 21:00:18 +0200,
Post by Maxim Levitsky
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
What does show with -v option?
OK, I could fully reproduce this now (sorry for the delay!).
Currently 2.6.28, u8.10, model acer-aspire, libasound2 1.0.17a-0ubuntu4,
libasound2-plugins 1.0.17-0ubuntu5.
Same microphone behaviour on 2.6.29-rc8 (additionally remembered to enable
CONFIG_SND_HDA_HWDEP for further testing!), u9.04, model acer-aspire,
libasound2 1.0.18-1ubuntu7, libasound2-plugins 1.0.18-1ubuntu4
(yes, I've just done some monster upgrade).

Will try to eventually analyze things using your _HWDEP-related tools.


2.6.29-rc8, in contrast to several other kernel upgrade occasions,
seems pretty solid so far, BTW.

Andreas Mohr
Takashi Iwai
2009-03-16 12:09:50 UTC
Permalink
At Mon, 16 Mar 2009 13:03:12 +0100,
Post by Andreas Mohr
Hi,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Sat, 22 Nov 2008 21:00:18 +0200,
Post by Maxim Levitsky
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
What does show with -v option?
OK, I could fully reproduce this now (sorry for the delay!).
Currently 2.6.28, u8.10, model acer-aspire, libasound2 1.0.17a-0ubuntu4,
libasound2-plugins 1.0.17-0ubuntu5.
Same microphone behaviour on 2.6.29-rc8 (additionally remembered to enable
CONFIG_SND_HDA_HWDEP for further testing!), u9.04, model acer-aspire,
libasound2 1.0.18-1ubuntu7, libasound2-plugins 1.0.18-1ubuntu4
(yes, I've just done some monster upgrade).
Will try to eventually analyze things using your _HWDEP-related tools.
The question in the top priority is whether it's a kernel driver
issue or alsa-lib converter issue. Could you check whether the sounds
recorded with -Dhw (and with matching rate, format, etc) have the same
noise problem at first?

And, if it's about the alsa-lib conversion problem, we can reproduce
without the hardware, e.g. via file plugin...


thanks,

Takashi
Andreas Mohr
2009-03-16 13:30:01 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 13:03:12 +0100,
Post by Andreas Mohr
Hi,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Sat, 22 Nov 2008 21:00:18 +0200,
Post by Maxim Levitsky
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
What does show with -v option?
OK, I could fully reproduce this now (sorry for the delay!).
Currently 2.6.28, u8.10, model acer-aspire, libasound2 1.0.17a-0ubuntu4,
libasound2-plugins 1.0.17-0ubuntu5.
Same microphone behaviour on 2.6.29-rc8 (additionally remembered to enable
CONFIG_SND_HDA_HWDEP for further testing!), u9.04, model acer-aspire,
libasound2 1.0.18-1ubuntu7, libasound2-plugins 1.0.18-1ubuntu4
(yes, I've just done some monster upgrade).
Will try to eventually analyze things using your _HWDEP-related tools.
The question in the top priority is whether it's a kernel driver
issue or alsa-lib converter issue. Could you check whether the sounds
recorded with -Dhw (and with matching rate, format, etc) have the same
noise problem at first?
OK, tried arecord -v -D hw:0 -c1 test.wav, which ended with
arecord: set_params:961: Sample format non available
.

arecord -v -D hw:0 -c1 -f S16_LE test.wav then ended with
arecord: set_params:966: Channels count non available
thus completing it into a
arecord -v -D hw:0 -c2 -f S16_LE test.wav
worked.

Trying this line with plughw then worked (of course, since two channels
never has any problems).

Interestingly when using plughw there seems to be some LPF effect, since
with hw I get lots of white noise whereas with plughw the recorded sound
is dark (no higher-frequency components at all).

And audio is always being recorded properly no matter which Capture
sliders position.


To state it more clearly, both hw and plughw have no issues whatsoever
with -c2 -f S16_LE, any sliders position.
If I then switch to plughw:0 -c2 -f U8 (IOW change to U8 format),
no problems either. Trouble starts if I then change to -c1 and have
both channel sliders about equal (if they're not equal then I'm getting
audio returned properly).
Post by Takashi Iwai
And, if it's about the alsa-lib conversion problem, we can reproduce
without the hardware, e.g. via file plugin...
So, what to do?
Post by Takashi Iwai
thanks,
Takashi
Thank You,

Andreas
Takashi Iwai
2009-03-16 14:18:20 UTC
Permalink
At Mon, 16 Mar 2009 14:30:01 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 13:03:12 +0100,
Post by Andreas Mohr
Hi,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Sat, 22 Nov 2008 21:00:18 +0200,
Post by Maxim Levitsky
Finally, I found how to reproduce that bug,
I mean to get normal volume on internal mic, I have to increase volume
only on left or right channel.
So, this happens always, and _only_ when recording _mono_ sound from internal
mic.
Since hardware doesn't support hardware mono input, tested with -D hw:0
I suspect this to be alsa-lib bug, any ideas?
Happens with arecord -D plughw:0 -c1 .
What does show with -v option?
OK, I could fully reproduce this now (sorry for the delay!).
Currently 2.6.28, u8.10, model acer-aspire, libasound2 1.0.17a-0ubuntu4,
libasound2-plugins 1.0.17-0ubuntu5.
Same microphone behaviour on 2.6.29-rc8 (additionally remembered to enable
CONFIG_SND_HDA_HWDEP for further testing!), u9.04, model acer-aspire,
libasound2 1.0.18-1ubuntu7, libasound2-plugins 1.0.18-1ubuntu4
(yes, I've just done some monster upgrade).
Will try to eventually analyze things using your _HWDEP-related tools.
The question in the top priority is whether it's a kernel driver
issue or alsa-lib converter issue. Could you check whether the sounds
recorded with -Dhw (and with matching rate, format, etc) have the same
noise problem at first?
OK, tried arecord -v -D hw:0 -c1 test.wav, which ended with
arecord: set_params:961: Sample format non available
.
arecord -v -D hw:0 -c1 -f S16_LE test.wav then ended with
arecord: set_params:966: Channels count non available
thus completing it into a
arecord -v -D hw:0 -c2 -f S16_LE test.wav
worked.
Trying this line with plughw then worked (of course, since two channels
never has any problems).
Interestingly when using plughw there seems to be some LPF effect, since
with hw I get lots of white noise whereas with plughw the recorded sound
is dark (no higher-frequency components at all).
And audio is always being recorded properly no matter which Capture
sliders position.
To state it more clearly, both hw and plughw have no issues whatsoever
with -c2 -f S16_LE, any sliders position.
If I then switch to plughw:0 -c2 -f U8 (IOW change to U8 format),
no problems either. Trouble starts if I then change to -c1 and have
both channel sliders about equal (if they're not equal then I'm getting
audio returned properly).
So, the following is also problematic

% arecord -fdat -c1 -Dplughw ng.wav

while the below works?

% arecord -fdat -Dhw good.wav
Post by Andreas Mohr
Post by Takashi Iwai
And, if it's about the alsa-lib conversion problem, we can reproduce
without the hardware, e.g. via file plugin...
So, what to do?
Does the conversion by sox from good.wav to a mono-channel file work?


Takashi
Andreas Mohr
2009-03-16 14:31:58 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 14:30:01 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
The question in the top priority is whether it's a kernel driver
issue or alsa-lib converter issue. Could you check whether the sounds
recorded with -Dhw (and with matching rate, format, etc) have the same
noise problem at first?
OK, tried arecord -v -D hw:0 -c1 test.wav, which ended with
arecord: set_params:961: Sample format non available
.
arecord -v -D hw:0 -c1 -f S16_LE test.wav then ended with
arecord: set_params:966: Channels count non available
thus completing it into a
arecord -v -D hw:0 -c2 -f S16_LE test.wav
worked.
Trying this line with plughw then worked (of course, since two channels
never has any problems).
Interestingly when using plughw there seems to be some LPF effect, since
with hw I get lots of white noise whereas with plughw the recorded sound
is dark (no higher-frequency components at all).
And audio is always being recorded properly no matter which Capture
sliders position.
To state it more clearly, both hw and plughw have no issues whatsoever
with -c2 -f S16_LE, any sliders position.
If I then switch to plughw:0 -c2 -f U8 (IOW change to U8 format),
no problems either. Trouble starts if I then change to -c1 and have
both channel sliders about equal (if they're not equal then I'm getting
audio returned properly).
So, the following is also problematic
% arecord -fdat -c1 -Dplughw ng.wav
while the below works?
% arecord -fdat -Dhw good.wav
Indeed, the above has problems with problematic slider positions whereas
the below never has.
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
And, if it's about the alsa-lib conversion problem, we can reproduce
without the hardware, e.g. via file plugin...
So, what to do?
Does the conversion by sox from good.wav to a mono-channel file work?
I assume I should be using
sox good.wav -c1 good1.wav
?

If so, yes, this works, audio is there.


Side note: I've got HDA power management activated (with some bad
effects - no sound at all on entire first playback after idle),
but this shouldn't matter here.

Andreas
Takashi Iwai
2009-03-16 14:42:54 UTC
Permalink
At Mon, 16 Mar 2009 15:31:58 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 14:30:01 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
The question in the top priority is whether it's a kernel driver
issue or alsa-lib converter issue. Could you check whether the sounds
recorded with -Dhw (and with matching rate, format, etc) have the same
noise problem at first?
OK, tried arecord -v -D hw:0 -c1 test.wav, which ended with
arecord: set_params:961: Sample format non available
.
arecord -v -D hw:0 -c1 -f S16_LE test.wav then ended with
arecord: set_params:966: Channels count non available
thus completing it into a
arecord -v -D hw:0 -c2 -f S16_LE test.wav
worked.
Trying this line with plughw then worked (of course, since two channels
never has any problems).
Interestingly when using plughw there seems to be some LPF effect, since
with hw I get lots of white noise whereas with plughw the recorded sound
is dark (no higher-frequency components at all).
And audio is always being recorded properly no matter which Capture
sliders position.
To state it more clearly, both hw and plughw have no issues whatsoever
with -c2 -f S16_LE, any sliders position.
If I then switch to plughw:0 -c2 -f U8 (IOW change to U8 format),
no problems either. Trouble starts if I then change to -c1 and have
both channel sliders about equal (if they're not equal then I'm getting
audio returned properly).
So, the following is also problematic
% arecord -fdat -c1 -Dplughw ng.wav
while the below works?
% arecord -fdat -Dhw good.wav
Indeed, the above has problems with problematic slider positions whereas
the below never has.
Err, could you be more specific about "slider positions"?
Post by Andreas Mohr
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
And, if it's about the alsa-lib conversion problem, we can reproduce
without the hardware, e.g. via file plugin...
So, what to do?
Does the conversion by sox from good.wav to a mono-channel file work?
I assume I should be using
sox good.wav -c1 good1.wav
?
If so, yes, this works, audio is there.
Just to be sure - what about below?
sox good.wav -c1 good1.wav mixer 0.5,0.5


Takashi
Andreas Mohr
2009-03-16 14:50:36 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 15:31:58 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
So, the following is also problematic
% arecord -fdat -c1 -Dplughw ng.wav
while the below works?
% arecord -fdat -Dhw good.wav
Indeed, the above has problems with problematic slider positions whereas
the below never has.
Err, could you be more specific about "slider positions"?
Hmm, I thought I was... (elsewhere)

In the problematic case (using plughw),
whenever left channel / right channel sliders are equal, no sound gets recorded.
IOW, there has to be a huge difference (in either direction)
between left and right channel slider to hear anything. And that is Not
A Good Feature to have ;)
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
Does the conversion by sox from good.wav to a mono-channel file work?
I assume I should be using
sox good.wav -c1 good1.wav
?
If so, yes, this works, audio is there.
Just to be sure - what about below?
sox good.wav -c1 good1.wav mixer 0.5,0.5
Yep, still works.

Thanks,

Andreas
Takashi Iwai
2009-03-16 15:34:05 UTC
Permalink
At Mon, 16 Mar 2009 15:50:36 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 15:31:58 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
So, the following is also problematic
% arecord -fdat -c1 -Dplughw ng.wav
while the below works?
% arecord -fdat -Dhw good.wav
Indeed, the above has problems with problematic slider positions whereas
the below never has.
Err, could you be more specific about "slider positions"?
Hmm, I thought I was... (elsewhere)
In the problematic case (using plughw),
whenever left channel / right channel sliders are equal, no sound gets recorded.
What are "sliders"?


Takashi
Andreas Mohr
2009-03-16 16:02:08 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 15:50:36 +0100,
Post by Andreas Mohr
In the problematic case (using plughw),
whenever left channel / right channel sliders are equal, no sound gets recorded.
What are "sliders"?
Umm, volume level controls.

Andreas
Takashi Iwai
2009-03-16 16:06:35 UTC
Permalink
At Mon, 16 Mar 2009 17:02:08 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 15:50:36 +0100,
Post by Andreas Mohr
In the problematic case (using plughw),
whenever left channel / right channel sliders are equal, no sound gets recorded.
What are "sliders"?
Umm, volume level controls.
Yes but there are many of such :)

More exactly, from the driver perspective, there are no volume
controls but only there are control elements with integer values.
Do you mean "Capture Volume" control or which one?

And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?


Takashi
Takashi Iwai
2009-03-16 16:19:38 UTC
Permalink
At Mon, 16 Mar 2009 17:06:35 +0100,
Post by Takashi Iwai
At Mon, 16 Mar 2009 17:02:08 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 15:50:36 +0100,
Post by Andreas Mohr
In the problematic case (using plughw),
whenever left channel / right channel sliders are equal, no sound gets recorded.
What are "sliders"?
Umm, volume level controls.
Yes but there are many of such :)
More exactly, from the driver perspective, there are no volume
controls but only there are control elements with integer values.
Do you mean "Capture Volume" control or which one?
And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc

pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}

and record like

% aplay -Dimix -c1 foo.wav


Takashi
Andreas Mohr
2009-03-16 17:00:15 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 17:06:35 +0100,
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
What are "sliders"?
Umm, volume level controls.
Yes but there are many of such :)
More exactly, from the driver perspective, there are no volume
controls but only there are control elements with integer values.
Do you mean "Capture Volume" control or which one?
Hmm, ok, this needs to be more precise:
In gamix (codec "HDA Intel : Realtek ALC268"), the Capture Volume control.
Post by Takashi Iwai
Post by Takashi Iwai
And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
and record like
% aplay -Dimix -c1 foo.wav
Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders
are acting normally, i.e. slider low == no sound), despite being a
"plug" type definition (this is what you wanted to discern, right? ;).

Thanks!

Andreas
Takashi Iwai
2009-03-16 17:15:39 UTC
Permalink
At Mon, 16 Mar 2009 18:00:15 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 17:06:35 +0100,
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
What are "sliders"?
Umm, volume level controls.
Yes but there are many of such :)
More exactly, from the driver perspective, there are no volume
controls but only there are control elements with integer values.
Do you mean "Capture Volume" control or which one?
In gamix (codec "HDA Intel : Realtek ALC268"), the Capture Volume control.
Yeah, that's more understandable :)

BTW, does "Capture Volume" influence on the recording level even for
the built-in mic, right? I'm asking this because the digital mic on
STAC/IDT codecs isn't controlled via "Capture Volume" control that is
bound to an ADC widget. (That's why "Digital Capture Volume" control
exists. It's a value used by alsa-lib softvol plugin for "default"
PCM.)
Post by Andreas Mohr
Post by Takashi Iwai
Post by Takashi Iwai
And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
and record like
% aplay -Dimix -c1 foo.wav
Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders
are acting normally, i.e. slider low == no sound), despite being a
"plug" type definition (this is what you wanted to discern, right? ;).
Interesting. This implies that one channel is inverted indeed.
As default the alsa-lib plugin downmixes a stereo stream to a mono
stream simply by left/2 + right/2. The above changes the routing
policy as left/2 - right/2.

So we need to pass some information to change this kind of thing...

But a question still remains; why conversion with sox worked.
Maybe it didn't mix? Or, the code alsa-lib could be buggy...

A simple test would be to just sum all 16bit samples in a stereo
stream file externally. That is, first record a RAW file via

% arecord -Dhw -traw -fdat foo.dat

Then create a mono stream just do 16bit left/2 + right/2 calculation
by any way (a good homework for kids :). Is it also problematic?


thanks,

Takashi
Andreas Mohr
2009-03-16 17:30:00 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 18:00:15 +0100,
=20
Hi,
=20
Post by Takashi Iwai
At Mon, 16 Mar 2009 17:06:35 +0100,
Post by Takashi Iwai
=20
Post by Andreas Mohr
Post by Takashi Iwai
What are "sliders"?
=20
Umm, volume level controls.
=20
Yes but there are many of such :)
=20
More exactly, from the driver perspective, there are no volume
controls but only there are control elements with integer value=
s.
Post by Takashi Iwai
Post by Takashi Iwai
Post by Takashi Iwai
Do you mean "Capture Volume" control or which one?
=20
In gamix (codec "HDA Intel : Realtek ALC268"), the Capture Volume c=
ontrol.
Post by Takashi Iwai
=20
Yeah, that's more understandable :)
=20
BTW, does "Capture Volume" influence on the recording level even for
the built-in mic, right? I'm asking this because the digital mic on
STAC/IDT codecs isn't controlled via "Capture Volume" control that is
bound to an ADC widget. (That's why "Digital Capture Volume" control
exists. It's a value used by alsa-lib softvol plugin for "default"
PCM.)
Yes, Capture Volume does influence i-Mic level.
The Digital Capture control, however, doesn't influence level.
As doesn't the Mic Boost Capture control (probably about e-Mic only?).
Post by Takashi Iwai
Post by Takashi Iwai
Post by Takashi Iwai
And, is the behavior consistent regardless of the value high, i=
=2Ee.
Post by Takashi Iwai
Post by Takashi Iwai
Post by Takashi Iwai
the key is only whether the values for both channels are identi=
cal?
Post by Takashi Iwai
Post by Takashi Iwai
=20
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
=20
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
=20
and record like
=20
% aplay -Dimix -c1 foo.wav
=20
Does NOT exhibit the "equal sliders =3D=3D no sound" bug (apart fro=
m this sliders
Post by Takashi Iwai
are acting normally, i.e. slider low =3D=3D no sound), despite bein=
g a
Post by Takashi Iwai
"plug" type definition (this is what you wanted to discern, right? =
;).
Post by Takashi Iwai
=20
Interesting. This implies that one channel is inverted indeed.
Oh, you mean "inverted" as in "_hardware_ channel which provides opposi=
te
sample values as compared to the other channel"?
Post by Takashi Iwai
As default the alsa-lib plugin downmixes a stereo stream to a mono
stream simply by left/2 + right/2. The above changes the routing
policy as left/2 - right/2.
That exactly matches my current stream of thought (while reading
"one channel is inverted" above).
Post by Takashi Iwai
So we need to pass some information to change this kind of thing...
That's something specific to ALC268 codec setup, right?
("ALC268 digital mic =3D=3D left plus right channel, but inverted setup=
"?)
Post by Takashi Iwai
But a question still remains; why conversion with sox worked.
Maybe it didn't mix? Or, the code alsa-lib could be buggy...
=20
A simple test would be to just sum all 16bit samples in a stereo
stream file externally. That is, first record a RAW file via
=20
% arecord -Dhw -traw -fdat foo.dat
=20
Then create a mono stream just do 16bit left/2 + right/2 calculation
by any way (a good homework for kids :). Is it also problematic?
OK, I know what you're up to, I'll do this external proof ASAP,
will take a couple more minutes.

Andreas
Takashi Iwai
2009-03-16 17:34:35 UTC
Permalink
At Mon, 16 Mar 2009 18:30:00 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 18:00:15 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 17:06:35 +0100,
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
What are "sliders"?
Umm, volume level controls.
Yes but there are many of such :)
More exactly, from the driver perspective, there are no volume
controls but only there are control elements with integer values.
Do you mean "Capture Volume" control or which one?
In gamix (codec "HDA Intel : Realtek ALC268"), the Capture Volume control.
Yeah, that's more understandable :)
BTW, does "Capture Volume" influence on the recording level even for
the built-in mic, right? I'm asking this because the digital mic on
STAC/IDT codecs isn't controlled via "Capture Volume" control that is
bound to an ADC widget. (That's why "Digital Capture Volume" control
exists. It's a value used by alsa-lib softvol plugin for "default"
PCM.)
Yes, Capture Volume does influence i-Mic level.
The Digital Capture control, however, doesn't influence level.
As doesn't the Mic Boost Capture control (probably about e-Mic only?).
The "Digital Capture Volume" has effect only when "default" PCM is used.
If you record via "hw" or "plughw", it's unused.
Post by Andreas Mohr
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
Post by Takashi Iwai
And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
and record like
% aplay -Dimix -c1 foo.wav
Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders
are acting normally, i.e. slider low == no sound), despite being a
"plug" type definition (this is what you wanted to discern, right? ;).
Interesting. This implies that one channel is inverted indeed.
Oh, you mean "inverted" as in "_hardware_ channel which provides opposite
sample values as compared to the other channel"?
Right. My guess is that the hardware provides left (or right) channel
is multiplied by -1 (yep "inverted" is no correct word choice).
Post by Andreas Mohr
Post by Takashi Iwai
As default the alsa-lib plugin downmixes a stereo stream to a mono
stream simply by left/2 + right/2. The above changes the routing
policy as left/2 - right/2.
That exactly matches my current stream of thought (while reading
"one channel is inverted" above).
Post by Takashi Iwai
So we need to pass some information to change this kind of thing...
That's something specific to ALC268 codec setup, right?
("ALC268 digital mic == left plus right channel, but inverted setup"?)
No. It's specific to the digital-mic side.


Takashi
Andreas Mohr
2009-03-16 18:06:38 UTC
Permalink
Post by Takashi Iwai
At Mon, 16 Mar 2009 18:30:00 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 18:00:15 +0100,
Post by Andreas Mohr
Post by Takashi Iwai
Post by Takashi Iwai
And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
and record like
% aplay -Dimix -c1 foo.wav
Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders
are acting normally, i.e. slider low == no sound), despite being a
"plug" type definition (this is what you wanted to discern, right? ;).
Interesting. This implies that one channel is inverted indeed.
Oh, you mean "inverted" as in "_hardware_ channel which provides opposite
sample values as compared to the other channel"?
Right. My guess is that the hardware provides left (or right) channel
is multiplied by -1 (yep "inverted" is no correct word choice).
Post by Andreas Mohr
Post by Takashi Iwai
As default the alsa-lib plugin downmixes a stereo stream to a mono
stream simply by left/2 + right/2. The above changes the routing
policy as left/2 - right/2.
That exactly matches my current stream of thought (while reading
"one channel is inverted" above).
Post by Takashi Iwai
So we need to pass some information to change this kind of thing...
That's something specific to ALC268 codec setup, right?
("ALC268 digital mic == left plus right channel, but inverted setup"?)
No. It's specific to the digital-mic side.
I just tried connecting a headset and switching to E-Mic.
What I can say is:
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)


BTW, the output (of arecord -Dplughw:0 -c2 -traw -fdat foo.wav) _does_ have
inverted channels:

00000130 2A 02 D2 FD 65 02 A5 FD 10 00 E7 FF 99 FF 72 00 *...e.........r.
00000140 53 FE A7 01 ED FF 12 00 4F FF A6 00 86 00 81 FF S.......O.......
... and so on in the entire file ...


One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...

Andreas
Takashi Iwai
2009-03-16 20:28:39 UTC
Permalink
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
Post by Takashi Iwai
At Mon, 16 Mar 2009 18:30:00 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 18:00:15 +0100,
Post by Andreas Mohr
Post by Takashi Iwai
Post by Takashi Iwai
And, is the behavior consistent regardless of the value high, i.e.
the key is only whether the values for both channels are identical?
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
and record like
% aplay -Dimix -c1 foo.wav
Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders
are acting normally, i.e. slider low == no sound), despite being a
"plug" type definition (this is what you wanted to discern, right? ;).
Interesting. This implies that one channel is inverted indeed.
Oh, you mean "inverted" as in "_hardware_ channel which provides opposite
sample values as compared to the other channel"?
Right. My guess is that the hardware provides left (or right) channel
is multiplied by -1 (yep "inverted" is no correct word choice).
Post by Andreas Mohr
Post by Takashi Iwai
As default the alsa-lib plugin downmixes a stereo stream to a mono
stream simply by left/2 + right/2. The above changes the routing
policy as left/2 - right/2.
That exactly matches my current stream of thought (while reading
"one channel is inverted" above).
Post by Takashi Iwai
So we need to pass some information to change this kind of thing...
That's something specific to ALC268 codec setup, right?
("ALC268 digital mic == left plus right channel, but inverted setup"?)
No. It's specific to the digital-mic side.
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Post by Andreas Mohr
BTW, the output (of arecord -Dplughw:0 -c2 -traw -fdat foo.wav) _does_ have
00000130 2A 02 D2 FD 65 02 A5 FD 10 00 E7 FF 99 FF 72 00 *...e.........r.
00000140 53 FE A7 01 ED FF 12 00 4F FF A6 00 86 00 81 FF S.......O.......
... and so on in the entire file ...
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.

The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.


Takashi
Andreas Mohr
2009-03-16 21:22:27 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Thought so.
Post by Takashi Iwai
Post by Andreas Mohr
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.
Not sure what this means.
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?

Thanks,

Andreas
Maxim Levitsky
2009-03-17 00:52:19 UTC
Permalink
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Thought so.
Post by Takashi Iwai
Post by Andreas Mohr
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.
Not sure what this means.
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace?
It is mono after all?

Best regards,
Maxim Levitsky
Takashi Iwai
2009-03-17 07:57:52 UTC
Permalink
At Tue, 17 Mar 2009 02:52:19 +0200,
Post by Maxim Levitsky
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Thought so.
Post by Takashi Iwai
Post by Andreas Mohr
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.
Not sure what this means.
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace?
It is mono after all?
No, it's a mic-array. And HD-audio cannot handle a mono stream.


Takashi
Maxim Levitsky
2009-03-17 11:30:12 UTC
Permalink
Post by Takashi Iwai
At Tue, 17 Mar 2009 02:52:19 +0200,
Post by Maxim Levitsky
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Thought so.
Post by Takashi Iwai
Post by Andreas Mohr
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.
Not sure what this means.
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace?
It is mono after all?
No, it's a mic-array. And HD-audio cannot handle a mono stream.
No problem.
Lets just lie to usespace that it is mono, in kernel driver can pick one
of channels?

Maybe this is an array, but this doesn't explain the 'quality' of it.
It is so low (in windows too).

Best regards,
Maxim Levitsky
Takashi Iwai
2009-03-17 12:52:07 UTC
Permalink
At Tue, 17 Mar 2009 13:30:12 +0200,
Post by Maxim Levitsky
Post by Takashi Iwai
At Tue, 17 Mar 2009 02:52:19 +0200,
Post by Maxim Levitsky
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Thought so.
Post by Takashi Iwai
Post by Andreas Mohr
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.
Not sure what this means.
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?
Thanks,
Andreas
What about exposing the i-mic as a mono only device to userspace?
It is mono after all?
No, it's a mic-array. And HD-audio cannot handle a mono stream.
No problem.
Lets just lie to usespace that it is mono, in kernel driver can pick one
of channels?
No, the hardware provides only the stereo streams, so the driver,
too.

The downmixing is the job of the user-space. For example, try the
patch to alsa-lib I sent in my previous post.
Post by Maxim Levitsky
Maybe this is an array, but this doesn't explain the 'quality' of it.
It is so low (in windows too).
Properly using the mic-array would reduce the noise fairly well.
XP has no mic-array support, IIRC.

Of course, it's possible that Aspire* have badly equipped mic
arrays that don't help much noise suppression...


Takashi
Takashi Iwai
2009-03-17 07:57:06 UTC
Permalink
At Mon, 16 Mar 2009 22:22:27 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 19:06:38 +0100,
Post by Andreas Mohr
I just tried connecting a headset and switching to E-Mic.
- opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?)
- leaving E-Mic unplugged will actually record from i-Mic (due to properly
working EAPD mechanism, right?)
The record from mic-jack is via analog path. The phase-inversion
appears only for digital-mic, AFAIK.
Thought so.
Post by Takashi Iwai
Post by Andreas Mohr
One question still: is this a hardware defect (i.e. could this possibly
be swapped cables of the microphone connector in this model or so?
Not plausible but...), or is this an existing property
of the HDA's dig-mic base? You indicated it's the latter I think...
My guess is that it's a hardware implementation.
Maybe for the noise suppression via mic array.
Not sure what this means.
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?
The mic array on a laptop is used for beam forming and noise
suppressions. These require the software manipulation, of course.
The question is what kind of data is read from the hardware. Thus,
providing the raw streams for both mic inputs makes sense.

Obviously the stream read from the codec chip is a PCM while usually
the digital mic gives the output as PDM. So PDM -> PCM isn't needed
here. But, still a question is why a phase inversion in the second
channel. Whether it's intentional (e.g. to make the further
conversion easier) or not.

Would be interesting if you can figure out which digital-mic component
is used on your laptop (and if we can have any chip information by
luck).


Takashi
Andreas Mohr
2009-03-17 10:05:00 UTC
Permalink
Hi,
Post by Takashi Iwai
At Mon, 16 Mar 2009 22:22:27 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
The question is whether the left / right channels recorded from
digital mic are really raw data, or they are for modified data
(for differential, etc)... It's hard to guess without the actual
data.
I don't quite follow you here. Is there anything I could do about this?
The mic array on a laptop is used for beam forming and noise
suppressions. These require the software manipulation, of course.
The question is what kind of data is read from the hardware. Thus,
providing the raw streams for both mic inputs makes sense.
Makes sense indeed.
Post by Takashi Iwai
Obviously the stream read from the codec chip is a PCM while usually
the digital mic gives the output as PDM. So PDM -> PCM isn't needed
here. But, still a question is why a phase inversion in the second
channel. Whether it's intentional (e.g. to make the further
conversion easier) or not.
Would be interesting if you can figure out which digital-mic component
is used on your laptop (and if we can have any chip information by
luck).
Well, as some manufacturers/types of digital microphones I found Akustica
(AKU 1126 / 2000 / 2001 / 2002 / 2004 / 2103), Analog Devices (ADMP421), National Semiconductor
(digital microphones, amplifiers LMV1024, LMV1026) [1], [2], [3] and
Andrea Digital Array Microphones.

ALC268 specs [4] say that they actually support interfacing
LMV1024/1026, SPD0205ND (what the heck is this one?), AKU2000.

Umm wait, Aspire One has ALC269. ALC269 datasheet doesn't say anything
about microphone manufacturers.

Note that eeepc models 901++ have ALC269 as well
and - surprise, surprise - an inverted noise cancellation issue as well!!!!!:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331130

"Dreamcom 10 Laptop" [7]: " integrated Realtek HD audio processor, two
built-in Akustica digital microphones and two built-in stereo speakers"

This was the only reference up and down that I could find to _any_
notebook's microphone manufacturer listing. I suspect that
Aspire One has an Akustica microphone array as well since Akustica
seems to be the leading brand (hmm, any ideas about where the
second microphone is located if at all existing, but it must exist!!?
- probably at the front bottom?).
Note that I found that the 16bit inverted data is NOT exactly a sum
of 0x10000, IOW those _are_ two _separate_, inverted streams of audio data
(for noise cancellation somehow I guess).
OH WAIT!! If most Acer models have _both_ microphones at the screen
bezel (left and right side) yet Aspire One has them (as I'd guess) at
the top of the bezel (known) and at the front bottom, then this would
mean - hold your breath - that the microphone array's physical properties
(regarding noise cancellation) are moved by 90 degrees,
possibly exactly explaining the malfunctioning (this would explain why
Aspire One and eeepcs have issues whereas other Aspire models
probably don't have them!?!?).
Hmm OTOH providing an audio source from somewhere on the
left side / right side of the netbook doesn't suddenly provide any audio,
thus it's probably a nice theory ;)
But OTOH the fact remains that those netbooks have a drastic microphone
geometry design change versus the normal Acer notebooks, thus it likely is
the reason for this issue somehow, somewhere.


Another very widely used brochure phrase was
"Acer PureZone technology with two built-in stereo microphones featuring
beam forming, echo cancellation, and noise suppression technologies"
I couldn't locate more pointers to details here though.


Insightful Apple OS X ALC269 adaptation descriptions: [5].

Windows Vista (ick!) microphone array discussions: [6].


[1]. http://www.national.com/nationaledge/apr03/article.html (background explanations!)
[2]. https://www.national.com/appinfo/amps/microphone.html
[3]. http://www.national.com/GER/news/item/1,4300,50,00.html
[4]. https://nmso.mdg.ca/specsheets/Intel_ALC268_Sound.pdf
[5]. http://ipis-osx.wikidot.com/internal-sound
[6]. http://windowsteamblog.com/blogs/windowsvista/archive/2007/11/09/microphone-arrays-digital-microphones.aspx
[7]. http://www.lcr-europe.org/meter/12/stereo+speaker.html


Andreas
Andreas Mohr
2009-03-17 10:38:45 UTC
Permalink
Post by Andreas Mohr
"Dreamcom 10 Laptop" [7]: " integrated Realtek HD audio processor, two
built-in Akustica digital microphones and two built-in stereo speakers"
This was the only reference up and down that I could find to _any_
notebook's microphone manufacturer listing. I suspect that
Aspire One has an Akustica microphone array as well since Akustica
seems to be the leading brand (hmm, any ideas about where the
second microphone is located if at all existing, but it must exist!!?
- probably at the front bottom?).
NOPE. Aspire One most definitely has a Fortemedia SAM (small array
microphone) due to this output:
http://sites.google.com/site/kengell/acer-aspire-one---dmesg

"
...
ForteMedia SAM-Soft Library Loaded!

ALC INIT
...
"

I had already wanted to add the mention of Fortemedia as microphone
manufacturer (forgot this last time), then I researched more and found it.

Fortemedia device names include FM2018-380, not sure yet which one is in
Aspire One.

http://www.fortemedia.com/products/index.htm
( especially http://www.fortemedia.com/products/fm1182.htm )

Andreas
Andreas Mohr
2009-03-17 10:47:55 UTC
Permalink
Post by Andreas Mohr
NOPE. Aspire One most definitely has a Fortemedia SAM (small array
http://sites.google.com/site/kengell/acer-aspire-one---dmesg
"
...
ForteMedia SAM-Soft Library Loaded!
ALC INIT
...
"
I had already wanted to add the mention of Fortemedia as microphone
manufacturer (forgot this last time), then I researched more and found it.
Fortemedia device names include FM2018-380, not sure yet which one is in
Aspire One.
http://www.fortemedia.com/products/index.htm
( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf
mentions "FM201x" and www.sacg.com.tw (this one could be useful!).
Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and
FM2018 and thus
http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf
which is a relatively informative datasheet.

Andreas
Takashi Iwai
2009-03-17 11:25:13 UTC
Permalink
At Tue, 17 Mar 2009 11:47:55 +0100,
Post by Andreas Mohr
Post by Andreas Mohr
NOPE. Aspire One most definitely has a Fortemedia SAM (small array
http://sites.google.com/site/kengell/acer-aspire-one---dmesg
"
...
ForteMedia SAM-Soft Library Loaded!
ALC INIT
...
"
I had already wanted to add the mention of Fortemedia as microphone
manufacturer (forgot this last time), then I researched more and found it.
Fortemedia device names include FM2018-380, not sure yet which one is in
Aspire One.
http://www.fortemedia.com/products/index.htm
( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf
mentions "FM201x" and www.sacg.com.tw (this one could be useful!).
Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and
FM2018 and thus
http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf
which is a relatively informative datasheet.
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's
a digital-mic component by FortMedia together with their software
library for SAM handling.


BTW, a simple "fix" for the mono capture problem, you can patch
the config file for HD-audio in alsa-lib like below. Then the first
channel will be used for mono capture instead of averages.
Give it a try.

(But, this won't fix programs that prefer "hw" access such as
pulseaudio, of course.)


Takashi

---
diff --git a/src/conf/cards/HDA-Intel.conf b/src/conf/cards/HDA-Intel.conf
index 800281e..d3ac002 100644
--- a/src/conf/cards/HDA-Intel.conf
+++ b/src/conf/cards/HDA-Intel.conf
@@ -57,6 +57,8 @@ HDA-Intel.pcm.default {
max_dB 30.0
resolution 121
}
+ # to avoid possible phase inversions with digital mics
+ route_policy copy
}
hint.device 0
}
Andreas Mohr
2009-03-17 16:18:28 UTC
Permalink
Hi,
Post by Takashi Iwai
At Tue, 17 Mar 2009 11:47:55 +0100,
Post by Andreas Mohr
Post by Andreas Mohr
Fortemedia device names include FM2018-380, not sure yet which one is in
Aspire One.
http://www.fortemedia.com/products/index.htm
( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf
mentions "FM201x" and www.sacg.com.tw (this one could be useful!).
Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and
FM2018 and thus
http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf
which is a relatively informative datasheet.
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's
a digital-mic component by FortMedia together with their software
library for SAM handling.
I had the same thoughts later. Since they use an extensive SAM handling
library, there probably isn't such a chip, otherwise they probably
wouldn't need it ;)
Could you thus implement a nice beam-forming sound evaluation SAM
library for ALSA pretty pretty please? ;)
...or, is that SAM library available to us given that it exists in the
factory install? If so, then one should probably make good use of it...
Post by Takashi Iwai
BTW, a simple "fix" for the mono capture problem, you can patch
the config file for HD-audio in alsa-lib like below. Then the first
channel will be used for mono capture instead of averages.
Give it a try.
(But, this won't fix programs that prefer "hw" access such as
pulseaudio, of course.)
I'm not *quite* sure whether this is really what you meant,
but I patched /usr/share/alsa/cards/HDA-Intel.conf (libasound2
1.0.18-1ubuntu7) in exactly this way and then did
arecord -Dplughw:0 -fdat -c1 test.wav; aplay test.wav
but well, with equal slider positions there was no audio again.

Andreas
Takashi Iwai
2009-03-17 20:32:16 UTC
Permalink
At Tue, 17 Mar 2009 17:18:28 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Tue, 17 Mar 2009 11:47:55 +0100,
Post by Andreas Mohr
Post by Andreas Mohr
Fortemedia device names include FM2018-380, not sure yet which one is in
Aspire One.
http://www.fortemedia.com/products/index.htm
( especially http://www.fortemedia.com/products/fm1182.htm )
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf
mentions "FM201x" and www.sacg.com.tw (this one could be useful!).
Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and
FM2018 and thus
http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf
which is a relatively informative datasheet.
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's
a digital-mic component by FortMedia together with their software
library for SAM handling.
I had the same thoughts later. Since they use an extensive SAM handling
library, there probably isn't such a chip, otherwise they probably
wouldn't need it ;)
Could you thus implement a nice beam-forming sound evaluation SAM
library for ALSA pretty pretty please? ;)
A patch please :)
Post by Andreas Mohr
...or, is that SAM library available to us given that it exists in the
factory install? If so, then one should probably make good use of it...
An easy one would be a relatively simple algorithm, but I don't know
whether any free library code. Better to ask on LAD.
Post by Andreas Mohr
Post by Takashi Iwai
BTW, a simple "fix" for the mono capture problem, you can patch
the config file for HD-audio in alsa-lib like below. Then the first
channel will be used for mono capture instead of averages.
Give it a try.
(But, this won't fix programs that prefer "hw" access such as
pulseaudio, of course.)
I'm not *quite* sure whether this is really what you meant,
but I patched /usr/share/alsa/cards/HDA-Intel.conf (libasound2
1.0.18-1ubuntu7) in exactly this way and then did
arecord -Dplughw:0 -fdat -c1 test.wav; aplay test.wav
but well, with equal slider positions there was no audio again.
Don't use -Dplughw:0. Then the default setup will be used.

% arecord -fdat -c1 test.wav


Takashi
Andreas Mohr
2009-03-18 09:05:07 UTC
Permalink
Hi,
Post by Takashi Iwai
At Tue, 17 Mar 2009 17:18:28 +0100,
Post by Andreas Mohr
I had the same thoughts later. Since they use an extensive SAM handling
library, there probably isn't such a chip, otherwise they probably
wouldn't need it ;)
Could you thus implement a nice beam-forming sound evaluation SAM
library for ALSA pretty pretty please? ;)
A patch please :)
Not at the moment at least, sorry. But that would make for a nice
little (student?) project (or not so little).
Post by Takashi Iwai
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still
contains the patch, but equal Capture Volume sliders still silenced
audio input, whereas non-equal worked. Hmm.

Andreas
Takashi Iwai
2009-03-18 09:19:53 UTC
Permalink
At Wed, 18 Mar 2009 10:05:07 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Tue, 17 Mar 2009 17:18:28 +0100,
Post by Andreas Mohr
I had the same thoughts later. Since they use an extensive SAM handling
library, there probably isn't such a chip, otherwise they probably
wouldn't need it ;)
Could you thus implement a nice beam-forming sound evaluation SAM
library for ALSA pretty pretty please? ;)
A patch please :)
Not at the moment at least, sorry. But that would make for a nice
little (student?) project (or not so little).
Post by Takashi Iwai
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still
contains the patch, but equal Capture Volume sliders still silenced
audio input, whereas non-equal worked. Hmm.
What is the output with -v option?


Takashi
Andreas Mohr
2009-03-20 18:56:40 UTC
Permalink
Hi,
Post by Takashi Iwai
At Wed, 18 Mar 2009 10:05:07 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still
contains the patch, but equal Capture Volume sliders still silenced
audio input, whereas non-equal worked. Hmm.
What is the output with -v option?
Sorry for the delay!

$ arecord -fdat -c1 -v test.wav; aplay test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
ALSA <-> PulseAudio PCM I/O Plugin
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 1572864000
^CAborted by signal Interrupt...
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
***@andinet:/tmp$


Hmm. Note the pulseaudio stuff above...


I did verify that this test run using -v did exhibit failure again.

Thanks,

Andreas
Takashi Iwai
2009-03-20 20:33:19 UTC
Permalink
At Fri, 20 Mar 2009 19:56:40 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Wed, 18 Mar 2009 10:05:07 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
Don't use -Dplughw:0. Then the default setup will be used.
% arecord -fdat -c1 test.wav
Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still
contains the patch, but equal Capture Volume sliders still silenced
audio input, whereas non-equal worked. Hmm.
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
ALSA <-> PulseAudio PCM I/O Plugin
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 1572864000
^CAborted by signal Interrupt...
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hmm. Note the pulseaudio stuff above...
Yes, that's the very reason. If you don't PA and avoid the
default configuration override (e.g. defined in /etc/asound.conf)
my patch should work.


Takashi
Andreas Mohr
2009-03-22 12:55:17 UTC
Permalink
Hi,
Post by Takashi Iwai
At Fri, 20 Mar 2009 19:56:40 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
ALSA <-> PulseAudio PCM I/O Plugin
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 1572864000
^CAborted by signal Interrupt...
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hmm. Note the pulseaudio stuff above...
Yes, that's the very reason. If you don't PA and avoid the
default configuration override (e.g. defined in /etc/asound.conf)
my patch should work.
Sorry, but how would I achieve "don't PA"?
I've tried some Ubuntu suggestions
(e.g. http://ubuntuforums.org/showthread.php?t=852518 ; didn't work,
it's Jaunty here),
I tried asoundconf (un)set-pulseaudio (~/.asoundrc contents looked ok
then but didn't really help),
I tried pasuspender -- arecord -fdat -c1 -v test.wav
I always ended up with "ALSA <-> PulseAudio PCM I/O Plugin" mode.
(I didn't even attempt the ultimate solution, removing all traces of
PA packages, since that would be a ridiculous thing to do)
gnome-sound-properties didn't seem overly helpful either...
(Sound capture was already set as "ALSA")

If things are that impractical, then there needs to be another builtin way
to always have the microphone output end up correct, automatically,
instead of having to go through incredible convolutions to try to
access the raw ALSA device (which would probably provide a correct
mic stream) directly, by default.

Or, to put it another way, in many cases the default ALSA device
wouldn't be used (by sound layers or apps or whatever),
thus the patch above wouldn't work there if I'm not mistaken,
thus there needs to be a different way to fix the microphone.

Or, to have it even more condensed, the more you have to fiddle to make
the patch work, the more distance gets between you and the usual Linux
distribution use case.

Any ideas or suggestions?

Thanks,

Andreas
Takashi Iwai
2009-03-23 06:51:14 UTC
Permalink
At Sun, 22 Mar 2009 13:55:17 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
At Fri, 20 Mar 2009 19:56:40 +0100,
Post by Andreas Mohr
Hi,
Post by Takashi Iwai
What is the output with -v option?
Sorry for the delay!
$ arecord -fdat -c1 -v test.wav; aplay test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
ALSA <-> PulseAudio PCM I/O Plugin
stream : CAPTURE
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : NONE
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 1572864000
^CAborted by signal Interrupt...
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hmm. Note the pulseaudio stuff above...
Yes, that's the very reason. If you don't PA and avoid the
default configuration override (e.g. defined in /etc/asound.conf)
my patch should work.
Sorry, but how would I achieve "don't PA"?
I've tried some Ubuntu suggestions
(e.g. http://ubuntuforums.org/showthread.php?t=852518 ; didn't work,
it's Jaunty here),
I'm no Ubuntu user, so no idea.

Takashi

Maxim Levitsky
2008-11-12 17:20:08 UTC
Permalink
Post by Takashi Iwai
At Sun, 9 Nov 2008 21:09:29 +0100,
Post by Andreas Mohr
Post by Takashi Iwai
At Sun, 9 Nov 2008 16:13:23 +0100,
Post by Andreas Mohr
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
Build with the debug option (why turned off even if you *are*
debugging?). Then the driver will show you details.
Hmm, right, that would have been an (very useful) option, but not for the
majority of users OTOH.
I thought many ditros set this option...
Post by Andreas Mohr
Especially since this is a user-visible module parameter which should thus
be confirmed in mainstream user code, via logging.
You can check via /sys/modules/snd_hda_intel/parameters/model whether
you passed correctly or not, at least :)
Post by Andreas Mohr
Admittedly not many modules log their settings during startup,
but for snd_hda_intel with its two myriads of codec/machine variants
and a resulting quarter myriad of issues that would be very useful.
Passing the model option is already a kind of debugging work, IMO.
You shouldn't do it unless you need it, indeed.
Post by Andreas Mohr
Post by Takashi Iwai
Post by Andreas Mohr
--> I have to admit that usability sucks^Hcould be a lot better.
One would call it rather debuggability than usability.
These are completely different things.
See above ;)
Post by Takashi Iwai
Post by Andreas Mohr
i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
OK, then something is missing. But you should test by arecord first
than any complicated applications as a primary test.
Good point, will do.
Oh, and is there a way to manually alter codec registers?
Try hda-verb program. Build your kernel with CONFIG_SND_HDA_HWDEP=y
and access via the hwdep device.
ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2
Takashi
For the reference this this list of nodes on ALC268 (main mobo):

0x01 - params


output streams:
0x02 - DAC1 + volume
0x03 - DAC2 + volume (only headphones)
0x06 - s/pdif-out
0x1D - BEEP


input streams:
0x07 - ADC1
0x23 - ADC1 multiplexer + volume
0x08 - ADC2
0x24 - ADC2 multiplexer + volume


output pins(*): (***)

0x14 - LINE-OUT headphones <- 0x0f - line-out (mixer) <- DAC1 + beep
0x15 - HP-OUT speakers <- 0x10 - hp-out (mixer) <- DAC1 + DAC2 + beep
0x16 - MONO-OUT N/A <- 0x0e - mono out (mixer) <- DAC1
0x1E - spdif


input pins(**):
0x12 - DMIC1/2 N/A
0x13 - DMIC3/4 N/A
0x18 - MIC1 external mic + boost
0x19 - MIC2 internal mic + boost
0x1A - LINE-IN line-in + boost
0x1C - CD-IN N/A


* Most output pins may be used as input pins
** LINE-IN, MIC1 might be output of DAC1
*** those are pins that are connected on my main mobo.


/proc/asound/card0/codec#0 is attached (also for main computer, I will
test the 'one' tomorrow


Best regards,
Maxim Levitsky
Takashi Iwai
2008-11-12 18:53:47 UTC
Permalink
At Wed, 12 Nov 2008 12:08:28 +0100,
Post by Takashi Iwai
Post by Andreas Mohr
Post by Takashi Iwai
Post by Andreas Mohr
i-Mic on Ekiga with lotsa mixer fiddling didn't work either this time.
OK, then something is missing. But you should test by arecord first
than any complicated applications as a primary test.
Good point, will do.
Oh, and is there a way to manually alter codec registers?
Try hda-verb program. Build your kernel with CONFIG_SND_HDA_HWDEP=y
and access via the hwdep device.
ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2
BTW, for whom would like to fulfill the masochistic joy of debugging
on HD-audio, I uploaded my half-finished HD-audio emulator program.
The package is found at:
ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-emu-0.0.1.tar.gz
or
ftp://ftp.suse.com/pub/people/tiwai/misc/hda-emu-0.0.1.tar.gz

Have fun,

Takashi
Alan Jenkins
2008-11-09 10:43:28 UTC
Permalink
Post by Maxim Levitsky
Post by Alan Jenkins
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
revert msleep patch". Happily Len submitted it for mainline this
week. You will also find it if you try the acpi-test git tree.
We're all hoping 2.6.28 will be much improved in terms of reliable
operation of different ECs :).
Yes, this almost fixes all issues with that.
Almost because, it looks like the EC changes screen brightness on his
own when battery is plugged/unplugged,
but so does the gnome-power-manager, and thus it still hangs as before
on battery removal (but doesn't hang otherwise)
I disabled that behaver in gnome-power-manager and now no more hangs.
Please do report it as an ACPI EC bug. It's popular hardware, and if
nothing else it is important that upstream be aware of the workarounds
people are having to use.
Post by Maxim Levitsky
I see that this fix fixes the polled mode. Any chance to make irq mode work?
Probably not. It doesn't seem important, it may not be possible, and
even if you could fix the EC driver for your hardware, there's the risk
of breaking other peoples hardware.

The presumption is that you have weird hardware and it genuinely needs a
polling workaround. It's not too bad, now it uses udelay() it should
not impose any wakeups or significant latency, just some extra cpu time
in a busy loop. EC events such as acpi hotkeys are still received as
interrupts (although we then have to query the type of event using a
polled transaction).


I assume you get something like (text not exact):

"EC: started in polling mode"
...
"EC: non-query interrupt received, switching to interrupt mode"
...
"EC: missing confirmations, switching to polling mode"

all during boot.


There's one outstanding issue on a different machine, where the
occasional EC read fails and triggers polling mode sometime _after_
boot. It can be fixed by retrying the transaction

http://bugzilla.kernel.org/show_bug.cgi?id=11896

but I don't really expect your machine has the same problem.

<snip non-acpi problems>
Post by Maxim Levitsky
If I suspend/resume with compiz running, on resume I see wallpaper and
mouse cursor, everything hangs for minute or two, and sometimes forever.
2.6.27 worked fine.
Weird.

Did you try sysrq-W during the hang? That's supposed to dump a list of
blocked tasks to dmesg.
Post by Maxim Levitsky
Also hibernate doesn't work on my main notebook, but it is probably
fixed, I update kernel to really latest -git
and tell you.
But suspend to ram works? Usually it is the other way round :). If you
haven't already, you might read

Documentation/power/basic-pm-debugging.txt

it suggests some tests to narrow down the problem.
Post by Maxim Levitsky
Big thanks for bugfixes, you saved me a lot of work and bisecting.
I can't take credit for actual fixes. But I'm very happy to help people
avoid bisecting for known problems. I hope you have time to crack the
unknown ones :).

Alan
Maxim Levitsky
2008-11-12 17:48:41 UTC
Permalink
Post by Alan Jenkins
Post by Maxim Levitsky
Post by Alan Jenkins
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
revert msleep patch". Happily Len submitted it for mainline this
week. You will also find it if you try the acpi-test git tree.
We're all hoping 2.6.28 will be much improved in terms of reliable
operation of different ECs :).
Yes, this almost fixes all issues with that.
Almost because, it looks like the EC changes screen brightness on his
own when battery is plugged/unplugged,
but so does the gnome-power-manager, and thus it still hangs as before
on battery removal (but doesn't hang otherwise)
I disabled that behaver in gnome-power-manager and now no more hangs.
Please do report it as an ACPI EC bug. It's popular hardware, and if
nothing else it is important that upstream be aware of the workarounds
people are having to use.
Post by Maxim Levitsky
I see that this fix fixes the polled mode. Any chance to make irq mode work?
Probably not. It doesn't seem important, it may not be possible, and
even if you could fix the EC driver for your hardware, there's the risk
of breaking other peoples hardware.
The presumption is that you have weird hardware and it genuinely needs a
polling workaround. It's not too bad, now it uses udelay() it should
not impose any wakeups or significant latency, just some extra cpu time
in a busy loop. EC events such as acpi hotkeys are still received as
interrupts (although we then have to query the type of event using a
polled transaction).
"EC: started in polling mode"
...
"EC: non-query interrupt received, switching to interrupt mode"
...
"EC: missing confirmations, switching to polling mode"
all during boot.
Yes, this is what I see.
Post by Alan Jenkins
There's one outstanding issue on a different machine, where the
occasional EC read fails and triggers polling mode sometime _after_
boot. It can be fixed by retrying the transaction
http://bugzilla.kernel.org/show_bug.cgi?id=11896
but I don't really expect your machine has the same problem.
<snip non-acpi problems>
Post by Maxim Levitsky
If I suspend/resume with compiz running, on resume I see wallpaper and
mouse cursor, everything hangs for minute or two, and sometimes forever.
2.6.27 worked fine.
Weird.
Did you try sysrq-W during the hang? That's supposed to dump a list of
blocked tasks to dmesg.
Well, I see the wallpaper and can move the mouse, I will try to suspend from console
I think this is graphics bug.
nether ctrl+alt+bks nor SAK kill X.

After 2 minute wait, kernel log doesn't show anything unusual.
printk times, jump that 2 minutes around wireless association, but I tested it without ath5k loaded
and still the same happens.

Also if I disable compiz, everything resumes correctly, and instantly.
Post by Alan Jenkins
Post by Maxim Levitsky
Also hibernate doesn't work on my main notebook, but it is probably
fixed, I update kernel to really latest -git
and tell you.
But suspend to ram works? Usually it is the other way round :). If you
haven't already, you might read
Documentation/power/basic-pm-debugging.txt
Well, this is long story
details at http://lkml.org/lkml/2008/9/20/75
speaking shortly, bios doesn't pass control to kernel on second resume.
Thus I don't test it, but I see how it works now.

Suspend to disk still doesn't work.
First of all system hangs in the end of image writeout.
If I power it down manually, and boot, system resumes from disk, and then hangs.
2.6.27 works fine.

(This is about my main notebook)
Post by Alan Jenkins
it suggests some tests to narrow down the problem.
Post by Maxim Levitsky
Big thanks for bugfixes, you saved me a lot of work and bisecting.
I can't take credit for actual fixes. But I'm very happy to help people
avoid bisecting for known problems. I hope you have time to crack the
unknown ones :).
Alan
Best regards,
Maxim Levitsky


PS: sorry for late reply
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Maxim Levitsky
2008-11-14 19:06:09 UTC
Permalink
Post by Alan Jenkins
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
That sounds like a known issue. It has been resolved by "ACPI: EC: revert msleep patch". Happily Len submitted it for mainline this week. You will also find it if you try the acpi-test git tree. We're all hoping 2.6.28 will be much improved in terms of reliable operation of different ECs :).
** 2 - wireless: not to mention the fact that ath5k wasn't installed by default in ubuntu...
wireless more or less works, but kernel log is full of backtraces.
Well, that doesn't tell us much. Did they still happen after upgrading to 2.6.28-rc3? Can we see them?
Was able to connect to my WPA2 access point.
Sometimes wireless fails completely, especially after suspend to ram.
Advanced features like monitor/injection work, but when I changed the card's
mac address it stopped working.
I also noticed that if I then start airodump, then wireless works with new mac.
** 3 - internal mic doesn't work.
tried model=acer, model=auto.
Overall it seems that alsa misprograms O/B realteck
codec.
I talk about this later.
Have same issue on my acer 5720
** 4 - wireless led doesn't work.
ath5k devs, can you fix this?
** 5 - coretemp doesn't show cpu temperature,
I have seen somewhere that atom support same thermal diode as core2
and only patch to detect it is needed.
Please include such path in 2.6.28 if exists.
Patch for that does exits, but doesn't apply to latest git,
I will apply in manually.
This should go to .28 I think, this is trivial thing.
Post by Alan Jenkins
** 6 - both card readers are missing from lspci, is this normal?
<http://bugzilla.kernel.org/show_bug.cgi?id=11828>
so one assumes that it worked on the machines with linux pre-installed. Hopefully without requiring any hacks.
It seems that for now a workaround may be to pass the option debug_quirks=1 to the sdhci module...
<http://marc.info/?l=linux-kernel&m=122509648027303&w=2>
...or that it may help if you insert an SD card before booting.
Apparently the reporter also investigated pcie hotplug. Probably the BIOS doesn't provide the normal support. You can try "modprobe pciehp pciehp_force=1", maybe it helps the kernel discover the devices. It worked for something else on my EeePC. But then it will reportedly disappear the ethernet controller.
However, at the moment pciehp can cause delays of 10s of seconds during resume.
Got, a SD card, and with help of pciehp it works almost perfectly in both slots.
Almost, due to the fact that R/O switch is ignored.
(Just as I expected, a s/w switch, couldn't they think more, and include a hardware switch?)
On my main acer R/O switch works.

However I have to use pciehp_force=1, I understand that probably acpi tables are broken,
but could you add a workaround (dmi quirk?)

Also, there is a acpiphp driver, which doesn't work here.
pciehp is supposed to support so called native mode, don't yet know what it is,
but here it still uses acpi.
Post by Alan Jenkins
** 7 - opengl is broken, I tried running neverball in fullscreen, but it shows wrong/corrupted
textures (compiz is running, and working well thought)
I almost sure why this happens, opengl application is out of textures,
I need to install gem enabled intel driver here, and see how it works.



Best regards,
Maxim Levitsky
Alan Jenkins
2008-11-14 19:59:25 UTC
Permalink
Post by Maxim Levitsky
Post by Alan Jenkins
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
That sounds like a known issue. It has been resolved by "ACPI: EC: revert
msleep patch". Happily Len submitted it for mainline this week. You will
also find it if you try the acpi-test git tree. We're all hoping 2.6.28
will be much improved in terms of reliable operation of different ECs :).
** 2 - wireless: not to mention the fact that ath5k wasn't installed by
default in ubuntu...
wireless more or less works, but kernel log is full of backtraces.
Well, that doesn't tell us much. Did they still happen after upgrading to
2.6.28-rc3? Can we see them?
Was able to connect to my WPA2 access point.
Sometimes wireless fails completely, especially after suspend to ram.
Advanced features like monitor/injection work, but when I changed the card's
mac address it stopped working.
I also noticed that if I then start airodump, then wireless works with new mac.
** 3 - internal mic doesn't work.
tried model=acer, model=auto.
Overall it seems that alsa misprograms O/B realteck
codec.
I talk about this later.
Have same issue on my acer 5720
** 4 - wireless led doesn't work.
ath5k devs, can you fix this?
** 5 - coretemp doesn't show cpu temperature,
I have seen somewhere that atom support same thermal diode as core2
and only patch to detect it is needed.
Please include such path in 2.6.28 if exists.
Patch for that does exits, but doesn't apply to latest git,
I will apply in manually.
This should go to .28 I think, this is trivial thing.
Post by Alan Jenkins
** 6 - both card readers are missing from lspci, is this normal?
<http://bugzilla.kernel.org/show_bug.cgi?id=11828>
so one assumes that it worked on the machines with linux pre-installed.
Hopefully without requiring any hacks.
It seems that for now a workaround may be to pass the option
debug_quirks=1 to the sdhci module...
<http://marc.info/?l=linux-kernel&m=122509648027303&w=2>
...or that it may help if you insert an SD card before booting.
Apparently the reporter also investigated pcie hotplug. Probably the BIOS
doesn't provide the normal support. You can try "modprobe pciehp
pciehp_force=1", maybe it helps the kernel discover the devices. It
worked for something else on my EeePC. But then it will reportedly
disappear the ethernet controller.
However, at the moment pciehp can cause delays of 10s of seconds during resume.
Got, a SD card, and with help of pciehp it works almost perfectly in both slots.
Almost, due to the fact that R/O switch is ignored.
(Just as I expected, a s/w switch, couldn't they think more, and include a
hardware switch?)
On my main acer R/O switch works.
However I have to use pciehp_force=1, I understand that probably acpi tables are broken,
but could you add a workaround (dmi quirk?)
Also, there is a acpiphp driver, which doesn't work here.
pciehp is supposed to support so called native mode, don't yet know what it is,
but here it still uses acpi.
Matthew Garret tells me the Aspire One should be handled by acpiphp
patches he posted on the linux acpi mailing list recently.
--
A: Because it messes up the order in which people normally read text.
Post by Maxim Levitsky
Q: Why is top-posting such a bad thing?
Post by Alan Jenkins
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Maxim Levitsky
2008-11-15 12:52:36 UTC
Permalink
Post by Alan Jenkins
Post by Maxim Levitsky
Post by Alan Jenkins
I have just bought an Aspire one A150, XP version,
as it was the only available here, and installed ubuntu on it.
[ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode.
Maybe this is the reason for the fact that gnome power manager freezes when I unplug
the AC, and freezes often when I try to see battery status.
(Note: same is seen on my acer aspire 5720)
That sounds like a known issue. It has been resolved by "ACPI: EC: revert
msleep patch". Happily Len submitted it for mainline this week. You will
also find it if you try the acpi-test git tree. We're all hoping 2.6.28
will be much improved in terms of reliable operation of different ECs :).
** 2 - wireless: not to mention the fact that ath5k wasn't installed by
default in ubuntu...
wireless more or less works, but kernel log is full of backtraces.
Well, that doesn't tell us much. Did they still happen after upgrading to
2.6.28-rc3? Can we see them?
Was able to connect to my WPA2 access point.
Sometimes wireless fails completely, especially after suspend to ram.
Advanced features like monitor/injection work, but when I changed the card's
mac address it stopped working.
I also noticed that if I then start airodump, then wireless works with new mac.
** 3 - internal mic doesn't work.
tried model=acer, model=auto.
Overall it seems that alsa misprograms O/B realteck
codec.
I talk about this later.
Have same issue on my acer 5720
** 4 - wireless led doesn't work.
ath5k devs, can you fix this?
** 5 - coretemp doesn't show cpu temperature,
I have seen somewhere that atom support same thermal diode as core2
and only patch to detect it is needed.
Please include such path in 2.6.28 if exists.
Patch for that does exits, but doesn't apply to latest git,
I will apply in manually.
This should go to .28 I think, this is trivial thing.
Post by Alan Jenkins
** 6 - both card readers are missing from lspci, is this normal?
<http://bugzilla.kernel.org/show_bug.cgi?id=11828>
so one assumes that it worked on the machines with linux pre-installed.
Hopefully without requiring any hacks.
It seems that for now a workaround may be to pass the option
debug_quirks=1 to the sdhci module...
<http://marc.info/?l=linux-kernel&m=122509648027303&w=2>
...or that it may help if you insert an SD card before booting.
Apparently the reporter also investigated pcie hotplug. Probably the BIOS
doesn't provide the normal support. You can try "modprobe pciehp
pciehp_force=1", maybe it helps the kernel discover the devices. It
worked for something else on my EeePC. But then it will reportedly
disappear the ethernet controller.
However, at the moment pciehp can cause delays of 10s of seconds during resume.
Got, a SD card, and with help of pciehp it works almost perfectly in both slots.
Almost, due to the fact that R/O switch is ignored.
(Just as I expected, a s/w switch, couldn't they think more, and include a
hardware switch?)
On my main acer R/O switch works.
However I have to use pciehp_force=1, I understand that probably acpi tables are broken,
but could you add a workaround (dmi quirk?)
Also, there is a acpiphp driver, which doesn't work here.
pciehp is supposed to support so called native mode, don't yet know what it is,
but here it still uses acpi.
Matthew Garret tells me the Aspire One should be handled by acpiphp
patches he posted on the linux acpi mailing list recently.
I applied his first patch, and now acpiphp works great
(loads fast, and detects both readers)


Best regards,
Maxim Levitsky
Matthew Garrett
2008-11-15 12:55:10 UTC
Permalink
Post by Maxim Levitsky
I applied his first patch, and now acpiphp works great
(loads fast, and detects both readers)
Excellent, good to know.
--
Matthew Garrett | ***@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Loading...