Re: [alsa-devel] Bugs on aspire one A150
Alan Jenkins wrote:
Maxim Levitsky wrote:
I have just bought an Aspire one A150, XP version, as it was the only available here, and installed ubuntu on it.
Bugs I discovered so far:
** 1 - embedded controler works in polling mode, due to this:
[ 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?
** 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.
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.
** 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)
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.
I am aware of this, but don't yet have a SD card to test.
** 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)
Now I installed 2.6.28-rc3 (actually latest -git)
Sadly nothing improved. I only found few regressions:
- 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.
- 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.
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
[Only about sound stuff, stripped irrelevant addresses from cc]
At Sun, 09 Nov 2008 02:52:05 +0200, Maxim Levitsky wrote:
** 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
Hi,
[Takashi]:
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
Hi,
[Takashi]:
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.
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
At Sun, 9 Nov 2008 16:13:23 +0100, Andreas Mohr wrote:
Hi,
[Takashi]:
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.
--> 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.
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
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
On Sun, Nov 09, 2008 at 07:58:17PM +0100, Takashi Iwai wrote:
At Sun, 9 Nov 2008 16:13:23 +0100, Andreas Mohr wrote:
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.
--> 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 ;)
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?
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
At Sun, 9 Nov 2008 21:09:29 +0100, Andreas Mohr wrote:
On Sun, Nov 09, 2008 at 07:58:17PM +0100, Takashi Iwai wrote:
At Sun, 9 Nov 2008 16:13:23 +0100, Andreas Mohr wrote:
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...
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 :)
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.
--> 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 ;)
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
Takashi Iwai wrote:
At Sun, 9 Nov 2008 21:09:29 +0100, Andreas Mohr wrote:
On Sun, Nov 09, 2008 at 07:58:17PM +0100, Takashi Iwai wrote:
At Sun, 9 Nov 2008 16:13:23 +0100, Andreas Mohr wrote:
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...
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 :)
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.
--> 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 ;)
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
Hi,
On Wed, Nov 12, 2008 at 07:07:04PM +0200, Maxim Levitsky wrote:
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:
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!
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)
And now for unfixable problems:
- 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...
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'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
Andreas Mohr wrote:
Hi,
On Wed, Nov 12, 2008 at 07:07:04PM +0200, Maxim Levitsky wrote:
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:
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!
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)
And now for unfixable problems:
- 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...
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'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 wrote:
Andreas Mohr wrote:
Hi,
On Wed, Nov 12, 2008 at 07:07:04PM +0200, Maxim Levitsky wrote:
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:
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!
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)
And now for unfixable problems:
- 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...
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'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:
- 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
So aspire one support is almost, only need to add support to restore beep volume after resume.
Best regards, Maxim Levitsky
Hi,
On Sat, Nov 22, 2008 at 09:00:18PM +0200, Maxim Levitsky wrote:
Maxim Levitsky wrote:
- 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
At Sat, 22 Nov 2008 21:00:18 +0200, Maxim Levitsky wrote:
Maxim Levitsky wrote:
Andreas Mohr wrote:
Hi,
On Wed, Nov 12, 2008 at 07:07:04PM +0200, Maxim Levitsky wrote:
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:
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!
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)
And now for unfixable problems:
- 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...
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'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:
- 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
Hi,
On Mon, Nov 24, 2008 at 03:35:10PM +0100, Takashi Iwai wrote:
At Sat, 22 Nov 2008 21:00:18 +0200, Maxim Levitsky wrote:
Maxim Levitsky wrote:
Andreas Mohr wrote:
Hi,
On Wed, Nov 12, 2008 at 07:07:04PM +0200, Maxim Levitsky wrote:
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:
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!
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)
And now for unfixable problems:
- 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...
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'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:
- 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):
andi@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... andi@andinet:~$ aplay test.wav Playing WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono andi@andinet:~$
Non-working test (Capture sliders are equal):
andi@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... andi@andinet:~$ aplay test.wav Playing WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono andi@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
Hi,
On Sun, Mar 15, 2009 at 10:21:17AM +0100, Andreas Mohr wrote:
Hi,
On Mon, Nov 24, 2008 at 03:35:10PM +0100, Takashi Iwai wrote:
At Sat, 22 Nov 2008 21:00:18 +0200, Maxim Levitsky wrote:
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
At Mon, 16 Mar 2009 13:03:12 +0100, Andreas Mohr wrote:
Hi,
On Sun, Mar 15, 2009 at 10:21:17AM +0100, Andreas Mohr wrote:
Hi,
On Mon, Nov 24, 2008 at 03:35:10PM +0100, Takashi Iwai wrote:
At Sat, 22 Nov 2008 21:00:18 +0200, Maxim Levitsky wrote:
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
Hi,
On Mon, Mar 16, 2009 at 01:09:50PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 13:03:12 +0100, Andreas Mohr wrote:
Hi,
On Sun, Mar 15, 2009 at 10:21:17AM +0100, Andreas Mohr wrote:
Hi,
On Mon, Nov 24, 2008 at 03:35:10PM +0100, Takashi Iwai wrote:
At Sat, 22 Nov 2008 21:00:18 +0200, Maxim Levitsky wrote:
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).
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?
thanks,
Takashi
Thank You,
Andreas
At Mon, 16 Mar 2009 14:30:01 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 01:09:50PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 13:03:12 +0100, Andreas Mohr wrote:
Hi,
On Sun, Mar 15, 2009 at 10:21:17AM +0100, Andreas Mohr wrote:
Hi,
On Mon, Nov 24, 2008 at 03:35:10PM +0100, Takashi Iwai wrote:
At Sat, 22 Nov 2008 21:00:18 +0200, Maxim Levitsky wrote:
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
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
Hi,
On Mon, Mar 16, 2009 at 03:18:20PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 14:30:01 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 01:09:50PM +0100, Takashi Iwai wrote:
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.
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
At Mon, 16 Mar 2009 15:31:58 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 03:18:20PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 14:30:01 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 01:09:50PM +0100, Takashi Iwai wrote:
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"?
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
Hi,
On Mon, Mar 16, 2009 at 03:42:54PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 15:31:58 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 03:18:20PM +0100, Takashi Iwai wrote:
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 ;)
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
At Mon, 16 Mar 2009 15:50:36 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 03:42:54PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 15:31:58 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 03:18:20PM +0100, Takashi Iwai wrote:
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
Hi,
On Mon, Mar 16, 2009 at 04:34:05PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 15:50:36 +0100, Andreas Mohr wrote:
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
At Mon, 16 Mar 2009 17:02:08 +0100, Andreas Mohr wrote:
Hi,
On Mon, Mar 16, 2009 at 04:34:05PM +0100, Takashi Iwai wrote:
At Mon, 16 Mar 2009 15:50:36 +0100, Andreas Mohr wrote:
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 wrote:
At Sun, 9 Nov 2008 21:09:29 +0100, Andreas Mohr wrote:
On Sun, Nov 09, 2008 at 07:58:17PM +0100, Takashi Iwai wrote:
At Sun, 9 Nov 2008 16:13:23 +0100, Andreas Mohr wrote:
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...
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 :)
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.
--> 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 ;)
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
Codec: Realtek ALC268 Address: 0 Vendor Id: 0x10ec0268 Subsystem Id: 0x1025011e Revision Id: 0x100003 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: [0x32 0x32] 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: [0x32 0x32] 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 [0x6]: 16 20 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 [0x6]: 16 20 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] [0x80 0x80] 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 0x0820: 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 0x13 [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: 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 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 0x081003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x0221101f: [Jack] HP Out at Ext Front Conn = 1/8, Color = Black DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=04, enabled=1 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: [0x80 0x80] Pincap 0x081003c: 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 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 0x0810: 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 0x083734: IN OUT Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x02a19840: [Jack] Mic at Ext Front Conn = 1/8, Color = Pink DefAssociation = 0x4, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 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 0x083724: IN Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x99a30941: [Fixed] Mic at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x4, Sequence = 0x1 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 0x083734: IN OUT Detect Vref caps: HIZ 50 GRD 80 100 Pin Default 0x0281304e: [Jack] Line In at Ext Front Conn = 1/8, Color = Blue DefAssociation = 0x4, Sequence = 0xe Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=00, enabled=0 Connection: 1 0x02 Node 0x1b [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1c [Pin Complex] wcaps 0x400001: Stereo Pincap 0x0820: 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 0x0820: IN Pin Default 0x4017952d: [N/A] Speaker at Ext N/A Conn = Analog, Color = Pink DefAssociation = 0x2, Sequence = 0xd Misc = NO_PRESENCE Pin-ctls: 0x20: IN Node 0x1e [Pin Complex] wcaps 0x400380: Mono Digital Pincap 0x0810: OUT Pin Default 0x02451130: [Jack] SPDIF Out at Ext Front Conn = Optical, Color = Black DefAssociation = 0x3, 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=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x0b 0x0b] Connection: 7 0x18* 0x19 0x1a 0x1c 0x14 0x15 0x12 Node 0x24 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out Amp-Out caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-Out vals: [0x00 0x00] Connection: 7 0x18* 0x19 0x1a 0x1c 0x14 0x15 0x13
At Wed, 12 Nov 2008 12:08:28 +0100, I wrote:
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
participants (3)
-
Andreas Mohr -
Maxim Levitsky -
Takashi Iwai