All of lore.kernel.org
 help / color / mirror / Atom feed
* Major reworks on patch_via.c (TESTERS WANTED)
@ 2011-06-20 15:06 Takashi Iwai
  2011-06-20 15:16 ` Takashi Iwai
                   ` (3 more replies)
  0 siblings, 4 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-06-20 15:06 UTC (permalink / raw)
  To: ALSA Development Mailing List
  Cc: Raymond Yau, alex.baldacchino.alsasub, haraldwelte, lydiawang

Hi,

as there have many problems reported for VIA codecs, I started looking
at the driver code, and decided to rework on it.

The current development is found in sound git tree topic/via-cleanup
branch:
   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

You can pull into the latest Linus tree from topic/via-cleanup
branch:
   # this is the vanilla tree
   % cd linux-2.6 
   % git pull \
      git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ 
      topic/via-cleanup  

A good thing is that a fair amount of code reduction is done there:

% git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c
 sound/pci/hda/patch_via.c | 5892 +++++++++++----------------------------------
 1 files changed, 1453 insertions(+), 4439 deletions(-)

But, the driver isn't tested with real machines, yet.  That is, I need
testers with real machines.

Could VIA machine owners take a look at these commits and test it if
possible?  Especially, I'd like to know whether the headphone
auto-mute works in this form or not.

FWIW, the branch was merged to sound-unstable tree, so you can build
from alsa-driver-unstable snapshot tarball if you'd like to build
external modules without the kernel tree and git-merge.
  ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz


Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me
know.  It'd be very helpful for debugging, since I can check it via
hda-emu with alsa-info.sh output.  For now, I have the files of only
VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs.  The alsa-info.sh
outputs of other VIA codecs would be greatly appreciated.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-20 15:06 Major reworks on patch_via.c (TESTERS WANTED) Takashi Iwai
@ 2011-06-20 15:16 ` Takashi Iwai
  2011-06-21 10:01 ` David Henningsson
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-06-20 15:16 UTC (permalink / raw)
  To: ALSA Development Mailing List
  Cc: Raymond Yau, alex.baldacchino.alsasub, haraldwelte, lydiawang

At Mon, 20 Jun 2011 17:06:51 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> as there have many problems reported for VIA codecs, I started looking
> at the driver code, and decided to rework on it.
> 
> The current development is found in sound git tree topic/via-cleanup
> branch:
>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git

BTW, this changes the logic of detecting the HP-independent stream and
smart51 pins.  So, beware possible regressions or behavior changes
regarding them.  At least, the handling of the side/HP shared channel
is missing for now.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-20 15:06 Major reworks on patch_via.c (TESTERS WANTED) Takashi Iwai
  2011-06-20 15:16 ` Takashi Iwai
@ 2011-06-21 10:01 ` David Henningsson
  2011-06-21 11:01   ` Takashi Iwai
  2011-06-22  8:02 ` Jan Binder
  2011-06-22 14:28 ` Takashi Iwai
  3 siblings, 1 reply; 19+ messages in thread
From: David Henningsson @ 2011-06-21 10:01 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Raymond Yau, ALSA Development Mailing List,
	alex.baldacchino.alsasub, haraldwelte, lydiawang

On 2011-06-20 17:06, Takashi Iwai wrote:
> Hi,
>
> as there have many problems reported for VIA codecs, I started looking
> at the driver code, and decided to rework on it.

Excellent initiative, thanks!

> The current development is found in sound git tree topic/via-cleanup
> branch:
>     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
>
> You can pull into the latest Linus tree from topic/via-cleanup
> branch:
>     # this is the vanilla tree
>     % cd linux-2.6
>     % git pull \
>        git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \
>        topic/via-cleanup

The tree as of today, is now also available for easy testing for Ubuntu 
users: Just download and install 
http://people.canonical.com/~diwic/temp/alsa-hda-dkms-viacleanup_0.1_all.deb 
(works at least on Ubuntu 10.10 and 11.04), reboot and test.

> But, the driver isn't tested with real machines, yet.  That is, I need
> testers with real machines.
>
> Could VIA machine owners take a look at these commits and test it if
> possible?  Especially, I'd like to know whether the headphone
> auto-mute works in this form or not.

I have tested the new driver code on a machine here, and automute does 
work. There is however no enable/disable automute yet, as Realtek has. 
There are no input jack devices either (i e those we're debating in the 
other thread).

On the input side I notice a minor thing: "Front Mic Playback Volume" 
has an unneccessary index on it. Well, the Front mic is actually an 
internal mic, but that's BIOS lying to us, I guess.

Otherwise it seems to work fine here, so well done! :-)

> Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me
> know.  It'd be very helpful for debugging, since I can check it via
> hda-emu with alsa-info.sh output.  For now, I have the files of only
> VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs.  The alsa-info.sh
> outputs of other VIA codecs would be greatly appreciated.

Alsa-info for the machine I have here will follow shortly.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-21 10:01 ` David Henningsson
@ 2011-06-21 11:01   ` Takashi Iwai
  2011-06-21 11:38     ` David Henningsson
  0 siblings, 1 reply; 19+ messages in thread
From: Takashi Iwai @ 2011-06-21 11:01 UTC (permalink / raw)
  To: David Henningsson
  Cc: Raymond Yau, ALSA Development Mailing List,
	alex.baldacchino.alsasub, haraldwelte, lydiawang

At Tue, 21 Jun 2011 12:01:16 +0200,
David Henningsson wrote:
> 
> On 2011-06-20 17:06, Takashi Iwai wrote:
> > Hi,
> >
> > as there have many problems reported for VIA codecs, I started looking
> > at the driver code, and decided to rework on it.
> 
> Excellent initiative, thanks!
> 
> > The current development is found in sound git tree topic/via-cleanup
> > branch:
> >     git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> >
> > You can pull into the latest Linus tree from topic/via-cleanup
> > branch:
> >     # this is the vanilla tree
> >     % cd linux-2.6
> >     % git pull \
> >        git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \
> >        topic/via-cleanup
> 
> The tree as of today, is now also available for easy testing for Ubuntu 
> users: Just download and install 
> http://people.canonical.com/~diwic/temp/alsa-hda-dkms-viacleanup_0.1_all.deb 
> (works at least on Ubuntu 10.10 and 11.04), reboot and test.

Thanks!

> > But, the driver isn't tested with real machines, yet.  That is, I need
> > testers with real machines.
> >
> > Could VIA machine owners take a look at these commits and test it if
> > possible?  Especially, I'd like to know whether the headphone
> > auto-mute works in this form or not.
> 
> I have tested the new driver code on a machine here, and automute does 
> work. There is however no enable/disable automute yet, as Realtek has. 

Right.  This will be for future.

> There are no input jack devices either (i e those we're debating in the 
> other thread).

I haven't tracked this fully yet; can anyone give a short summary
and alsa-info.sh output of the affected system?

> On the input side I notice a minor thing: "Front Mic Playback Volume" 
> has an unneccessary index on it. Well, the Front mic is actually an 
> internal mic, but that's BIOS lying to us, I guess.

Fixed now in topic/via-cleanup branch.
Also the smart51 detection and some output-path initializations were
fixed.

> Otherwise it seems to work fine here, so well done! :-)
> 
> > Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me
> > know.  It'd be very helpful for debugging, since I can check it via
> > hda-emu with alsa-info.sh output.  For now, I have the files of only
> > VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs.  The alsa-info.sh
> > outputs of other VIA codecs would be greatly appreciated.
> 
> Alsa-info for the machine I have here will follow shortly.

Thanks, that's appreciated.


Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-21 11:01   ` Takashi Iwai
@ 2011-06-21 11:38     ` David Henningsson
  2011-06-21 12:28       ` Takashi Iwai
  0 siblings, 1 reply; 19+ messages in thread
From: David Henningsson @ 2011-06-21 11:38 UTC (permalink / raw)
  To: Takashi Iwai
  Cc: Raymond Yau, ALSA Development Mailing List,
	alex.baldacchino.alsasub, haraldwelte, lydiawang

On 2011-06-21 13:01, Takashi Iwai wrote:
>> There are no input jack devices either (i e those we're debating in the
>> other thread).
>
> I haven't tracked this fully yet; can anyone give a short summary
> and alsa-info.sh output of the affected system?

I mean, there are no calls to snd_hda_input_jack_* from patch_via.c yet.

You should have received alsa-info in a private email by now.

>> On the input side I notice a minor thing: "Front Mic Playback Volume"
>> has an unneccessary index on it. Well, the Front mic is actually an
>> internal mic, but that's BIOS lying to us, I guess.
>
> Fixed now in topic/via-cleanup branch.
> Also the smart51 detection and some output-path initializations were
> fixed.

Btw, I have not tested the smart51 / independent HP stuff.

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-21 11:38     ` David Henningsson
@ 2011-06-21 12:28       ` Takashi Iwai
  0 siblings, 0 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-06-21 12:28 UTC (permalink / raw)
  To: David Henningsson
  Cc: Raymond Yau, ALSA Development Mailing List,
	alex.baldacchino.alsasub, haraldwelte, lydiawang

At Tue, 21 Jun 2011 13:38:12 +0200,
David Henningsson wrote:
> 
> On 2011-06-21 13:01, Takashi Iwai wrote:
> >> There are no input jack devices either (i e those we're debating in the
> >> other thread).
> >
> > I haven't tracked this fully yet; can anyone give a short summary
> > and alsa-info.sh output of the affected system?
> 
> I mean, there are no calls to snd_hda_input_jack_* from patch_via.c yet.

Ah, I understand.  Yeah, it's also missing.

> You should have received alsa-info in a private email by now.

Yes, I got it.  Thanks.

> >> On the input side I notice a minor thing: "Front Mic Playback Volume"
> >> has an unneccessary index on it. Well, the Front mic is actually an
> >> internal mic, but that's BIOS lying to us, I guess.
> >
> > Fixed now in topic/via-cleanup branch.
> > Also the smart51 detection and some output-path initializations were
> > fixed.
> 
> Btw, I have not tested the smart51 / independent HP stuff.

I guess smart51 should work now, but not sure about independent HP.
I'll check hda-emu with your info.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-20 15:06 Major reworks on patch_via.c (TESTERS WANTED) Takashi Iwai
  2011-06-20 15:16 ` Takashi Iwai
  2011-06-21 10:01 ` David Henningsson
@ 2011-06-22  8:02 ` Jan Binder
  2011-06-22  8:52   ` Takashi Iwai
  2011-06-22 14:28 ` Takashi Iwai
  3 siblings, 1 reply; 19+ messages in thread
From: Jan Binder @ 2011-06-22  8:02 UTC (permalink / raw)
  To: alsa-devel
  Cc: Takashi Iwai, Raymond Yau, alex.baldacchino.alsasub, haraldwelte,
	lydiawang

Am Montag, 20. Juni 2011, 17:06:51 schrieb Takashi Iwai:
> Hi,
> 
> as there have many problems reported for VIA codecs, I started looking
> at the driver code, and decided to rework on it.
> 
> The current development is found in sound git tree topic/via-cleanup
> branch:
>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> 
> You can pull into the latest Linus tree from topic/via-cleanup
> branch:
>    # this is the vanilla tree
>    % cd linux-2.6
>    % git pull \
>       git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \
>       topic/via-cleanup
> 
> A good thing is that a fair amount of code reduction is done there:
> 
> % git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c
>  sound/pci/hda/patch_via.c | 5892
> +++++++++++---------------------------------- 1 files changed, 1453
> insertions(+), 4439 deletions(-)
> 
> But, the driver isn't tested with real machines, yet.  That is, I need
> testers with real machines.
> 
> Could VIA machine owners take a look at these commits and test it if
> possible?  Especially, I'd like to know whether the headphone
> auto-mute works in this form or not.

I will have a look at this.
On a related note, I am experiencing a bug regarding SPDIF output as  
described here: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4330
If this could be fixed within this rework, it would be greatly appreciated.

> FWIW, the branch was merged to sound-unstable tree, so you can build
> from alsa-driver-unstable snapshot tarball if you'd like to build
> external modules without the kernel tree and git-merge.
>  
> ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-un
> stable-snapshot.tar.gz
> 
> 
> Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me
> know.  It'd be very helpful for debugging, since I can check it via
> hda-emu with alsa-info.sh output.  For now, I have the files of only
> VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs.  The alsa-info.sh
> outputs of other VIA codecs would be greatly appreciated.

You can find the info-alsa.sh output for my VIA VT1708B 8-Ch at
http://www.alsa-project.org/db/?f=05281895eb77de2a22257e27fb2ecab1a959cb92
 
> thanks,
> 
> Takashi
--
Jan Binder

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-22  8:02 ` Jan Binder
@ 2011-06-22  8:52   ` Takashi Iwai
  0 siblings, 0 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-06-22  8:52 UTC (permalink / raw)
  To: Jan Binder
  Cc: Raymond Yau, alsa-devel, alex.baldacchino.alsasub, haraldwelte,
	lydiawang

At Wed, 22 Jun 2011 10:02:25 +0200,
Jan Binder wrote:
> 
> Am Montag, 20. Juni 2011, 17:06:51 schrieb Takashi Iwai:
> > Hi,
> > 
> > as there have many problems reported for VIA codecs, I started looking
> > at the driver code, and decided to rework on it.
> > 
> > The current development is found in sound git tree topic/via-cleanup
> > branch:
> >    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > 
> > You can pull into the latest Linus tree from topic/via-cleanup
> > branch:
> >    # this is the vanilla tree
> >    % cd linux-2.6
> >    % git pull \
> >       git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \
> >       topic/via-cleanup
> > 
> > A good thing is that a fair amount of code reduction is done there:
> > 
> > % git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c
> >  sound/pci/hda/patch_via.c | 5892
> > +++++++++++---------------------------------- 1 files changed, 1453
> > insertions(+), 4439 deletions(-)
> > 
> > But, the driver isn't tested with real machines, yet.  That is, I need
> > testers with real machines.
> > 
> > Could VIA machine owners take a look at these commits and test it if
> > possible?  Especially, I'd like to know whether the headphone
> > auto-mute works in this form or not.
> 
> I will have a look at this.
> On a related note, I am experiencing a bug regarding SPDIF output as  
> described here: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4330
> If this could be fixed within this rework, it would be greatly appreciated.

The SPDIF should work now.  At least, hda-emu shows the devices.

> > FWIW, the branch was merged to sound-unstable tree, so you can build
> > from alsa-driver-unstable snapshot tarball if you'd like to build
> > external modules without the kernel tree and git-merge.
> >  
> > ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-un
> > stable-snapshot.tar.gz
> > 
> > 
> > Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me
> > know.  It'd be very helpful for debugging, since I can check it via
> > hda-emu with alsa-info.sh output.  For now, I have the files of only
> > VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs.  The alsa-info.sh
> > outputs of other VIA codecs would be greatly appreciated.
> 
> You can find the info-alsa.sh output for my VIA VT1708B 8-Ch at
> http://www.alsa-project.org/db/?f=05281895eb77de2a22257e27fb2ecab1a959cb92

Great, thanks.


Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-20 15:06 Major reworks on patch_via.c (TESTERS WANTED) Takashi Iwai
                   ` (2 preceding siblings ...)
  2011-06-22  8:02 ` Jan Binder
@ 2011-06-22 14:28 ` Takashi Iwai
  2011-07-02 16:00   ` alex dot baldacchino dot alsasub at gmail dot com
  2011-07-04 19:37   ` Jan Binder
  3 siblings, 2 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-06-22 14:28 UTC (permalink / raw)
  To: ALSA Development Mailing List
  Cc: Raymond Yau, alex.baldacchino.alsasub, haraldwelte, lydiawang

At Mon, 20 Jun 2011 17:06:51 +0200,
Takashi Iwai wrote:
> 
> Hi,
> 
> as there have many problems reported for VIA codecs, I started looking
> at the driver code, and decided to rework on it.
> 
> The current development is found in sound git tree topic/via-cleanup
> branch:
>    git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> 
> You can pull into the latest Linus tree from topic/via-cleanup
> branch:
>    # this is the vanilla tree
>    % cd linux-2.6 
>    % git pull \
>       git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git \ 
>       topic/via-cleanup  
> 
> A good thing is that a fair amount of code reduction is done there:
> 
> % git diff HEAD..topic/via-cleanup --stat sound/pci/hda/patch_via.c
>  sound/pci/hda/patch_via.c | 5892 +++++++++++----------------------------------
>  1 files changed, 1453 insertions(+), 4439 deletions(-)
> 
> But, the driver isn't tested with real machines, yet.  That is, I need
> testers with real machines.
> 
> Could VIA machine owners take a look at these commits and test it if
> possible?  Especially, I'd like to know whether the headphone
> auto-mute works in this form or not.
> 
> FWIW, the branch was merged to sound-unstable tree, so you can build
> from alsa-driver-unstable snapshot tarball if you'd like to build
> external modules without the kernel tree and git-merge.
>   ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-unstable-snapshot.tar.gz
> 
> 
> Also, if anyone has alsa-info.sh outputs of VIA codecs, please let me
> know.  It'd be very helpful for debugging, since I can check it via
> hda-emu with alsa-info.sh output.  For now, I have the files of only
> VT1702, VT1708S, VT1718S, VT1828S and VT2020 codecs.  The alsa-info.sh
> outputs of other VIA codecs would be greatly appreciated.

I implemented the dynamic ADC switching, mainly for VT1702 machines
with the digital-mic connection like Gateway or Packard-Bell laptops.

When you have such a machine, i.e. an internal-mic input that doesn't
work as default properly, give it a try.

What I can implement more in a short time frame would be:
 - The automatic input switching for int-/ext-mics on laptop
 - Auto-mute Mode enum like in Realtek codec driver

Also, the rewrite of set_widgets_power_state() would be nice.
We can use the parsed input/output-paths for determining whether each
widget can be turned down or not.

In anyways, any positive / negative feedbacks or tests would be
appreciated.  When no big problem is found, I'm going to merge the new
code in the next week or next-next week.

(And yes, I'm still gathering alsa-info.sh outputs of VIA codecs;
 please contribute them if you have!)


thanks,

Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-22 14:28 ` Takashi Iwai
@ 2011-07-02 16:00   ` alex dot baldacchino dot alsasub at gmail dot com
  2011-07-04 12:55     ` Takashi Iwai
  2011-07-04 19:37   ` Jan Binder
  1 sibling, 1 reply; 19+ messages in thread
From: alex dot baldacchino dot alsasub at gmail dot com @ 2011-07-02 16:00 UTC (permalink / raw)
  To: ALSA Development Mailing List
  Cc: Takashi Iwai, Raymond Yau, haraldwelte, lydiawang

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

2011/6/22 Takashi Iwai <tiwai@suse.de>:
> At Mon, 20 Jun 2011 17:06:51 +0200,
> Takashi Iwai wrote:
>>
>> Hi,
>>
>> as there have many problems reported for VIA codecs, I started looking
>> at the driver code, and decided to rework on it.
>> [...]

I've installed and tested (from tarballs) both snapshot
alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz)
- up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang,
I think.

I've found problems with both. That's a quite huge change in the
implementation from older code, so I need to study it more in depth to
understand it better... At the moment I can only describe the problems
and give my first impressions on them.

First of all, I can't get sound from the front playback (rear
line-out). It would seem there's no problem opening the pcm and
setting the stream; If I switch Independent HP mode off, I can listen
to anything from my front audio panel (though with the old
implementation I could switch it on and off repeatedly and ensure that
sound came only from front dac (0x8), now the imux is 'blocked' as
busy while playing and it would seem the same stream is sent to hp dac
as well, even if its corresponding audio selector switches to front
dac - 0x8 - so hp shouldn't get sound by 0xb when in redirected mode;
perhaps I should add a few printk calls to
snd_hda_multi_out_analog_prepare() or snd_hda_codec_setup_stream() to
see what happens for nid 0x8, though I think it works, and maybe I can
confirm it indirectly).

Could there be the need to update cached values somewhere in the code?
Perhaps where certain nids are un-muted? I had a similar problem (with
the old implementation) while trying to create a pair or input muxs to
enable/disable the AA-path and avoid getting noisy feedback from my
headset mic (such as hearing my breath). For my codec (and a few
others - AFAICT, all flavours of VT1718S, all flavours of VT2002P and
VT1812) it was a matter of muting/un-muting the input from 0x21
(stereo mixer) to each mixer widget sending output to my green jacks;
however, trying to send a direct verb to those widgets I got some
problems I solved by calling snd_hda_codec_amp_stereo(), which updates
cached values as well (I had sent a mail with code slices to the list,
but it might have gone lost, because I cannot find a link in the
archives, just in case anyone wished to give it a look). Is there a
chance that a few calls to snd_hda_codec_write are not enough alone,
in this new implementation of the driver? Though it should be relevant
only if retrieving correct values for volumes is important for correct
handling of a stream setup (that is, if any decision is took basing on
results of a read operation on volumes), otherwise there could be some
error in nids' path parsing.


Second: Independent HP mode doesn't work as well - tested with aplay
-Dhw:0,2,0, since now a separate pcm device is created for headphones.
However, this is easy to fix, since it's just a matter of nid
mismatching in set_widgets_power_state_vt1718S():

...

	if (spec->hp_independent_mode) {
		/* PW4 (28h), MW3 (1bh), MUX1(34h), AOW4 (ch) */
		parm = AC_PWRST_D3;
		set_pin_power_state(codec, 0x28, &parm);
		snd_hda_codec_write(codec, 0x1b, 0,
				    AC_VERB_SET_POWER_STATE, parm);
		snd_hda_codec_write(codec, 0x34, 0,
				    AC_VERB_SET_POWER_STATE, parm);
-		snd_hda_codec_write(codec, 0xc, 0,
+		snd_hda_codec_write(codec, spec->hp_dac_nid, 0,
				    AC_VERB_SET_POWER_STATE, parm);
	}
}



By the way, in old code I had made a few changes to this function
basing on following considerations - which could no more apply, so I'm
posting the code below just to compare notes:

- this codec (family) has two adc's that seem to be 'almost
independent', meaning AIW1 (nid 0x11, coupled with MUX7, nid 0x1f), if
not in use, could be in state D3 while AIW0 (nid 0x10, coupled with
MUX6, nid 0x1e) is in D0, whereas the opposite should be avoided,
since mic boost controls and digital (mic) seem to be bound to AIW0;
moreover, MUX7 could be connected to stereo mixer, and this should be
taken into account when setting state for 0x21;

- when in redirected mode, hp Pin Widget (nid 0x28) should get input
only from front dac (nid 0x8) as selected by Audio Selector 0x34, thus
hp dac (0x0c or 0x0b) could be set in D3, and, if nothing is connected
to it (to 0x28) both Mixer 0x1b and MUX 0x34 could be set in D3
independently from state of pin 0x24 (front).



static void set_widgets_power_state_vt1718S(struct hda_codec *codec)
{
	struct via_spec *spec = codec->spec;
	unsigned int imux_is_smixer[ 2 ];
	unsigned int parm, parm_mux[ 2 ] = { AC_PWRST_D3, AC_PWRST_D3 };
	unsigned int imux_conn[2];

	/* get connection for MUX 6/7 (1eh/1fh) */
	imux_conn[ 0 ] = snd_hda_codec_read(codec, 0x1e, 0,
AC_VERB_GET_CONNECT_SEL, 0x00);
	imux_conn[ 1 ] = snd_hda_codec_read(codec, 0x1f, 0,
AC_VERB_GET_CONNECT_SEL, 0x00);
	/* MUX 6/7 (1eh/1fh) = stereo mixer ? */
	imux_is_smixer[ 0 ] = ( imux_conn[ 0 ] == 5 );	
	imux_is_smixer[ 1 ] = ( imux_conn[ 1 ] == 5 );

	/* inputs */
	/* PW 5/6/7 (29h/2ah/2bh) */
	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x29, &parm);
	if( imux_conn[ 0 ] == 3 ) /* MUX6 (1eh) connected to 0x29 */
		parm_mux[ 0 ] = parm;
	if( imux_conn[ 1 ] == 3 ) /* MUX7 (1fh) connected to 0x29 */
		parm_mux[ 1 ] = parm;

	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x2a, &parm);
	if( imux_conn[ 0 ] == 2 ) /* MUX6 (1eh) connected to 0x2a */
		parm_mux[ 0 ] = parm;
	if( imux_conn[ 1 ] == 2 ) /* MUX7 (1fh) connected to 0x2a */
		parm_mux[ 1 ] = parm;

	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x2b, &parm);
	if( imux_conn[ 0 ] == 1 ) /* MUX6 (1eh) connected to 0x2b */
		parm_mux[ 0 ] = parm;
	if( imux_conn[ 1 ] == 1 ) /* MUX7 (1fh) connected to 0x2b */
		parm_mux[ 1 ] = parm;

	/* MUX6 (1eh) = stereo mixer */
	if( imux_is_smixer[ 0 ] )
		parm_mux[ 0 ] = AC_PWRST_D0;
	/* MUX7 (1fh) = stereo mixer */
	if( imux_is_smixer[ 1 ] )
		parm_mux[ 1 ] = AC_PWRST_D0;
	/* this codec has switches for front/rear boost captures and digital
mic binded to AIW0 (10h) */
	/* therefore, if those are needed when using stuff connected to MUX7
(1fh), MUX6 must be on*/
	if( parm_mux[ 1 ] == AC_PWRST_D0 )
		parm_mux[ 0 ] = parm_mux[ 1 ];

	/* MUX6/7 (1eh/1fh), AIW 0/1 (10h/11h) */
	snd_hda_codec_write( codec, 0x1e, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 0 ] );
	snd_hda_codec_write( codec, 0x10, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 0 ] );
	snd_hda_codec_write( codec, 0x1f, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 1 ] );
	snd_hda_codec_write( codec, 0x11, 0, AC_VERB_SET_POWER_STATE, parm_mux[ 1 ] );

	/* outputs */
	/* PW3 (27h), MW2 (1ah), AOW3 (bh) */
	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x27, &parm);
	snd_hda_codec_write(codec, 0x1a, 0, AC_VERB_SET_POWER_STATE, parm);
	snd_hda_codec_write(codec, 0xb, 0, AC_VERB_SET_POWER_STATE, parm);

	/* PW2 (26h), AOW2 (ah) */
	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x26, &parm);
	if (spec->smart51_enabled)
		set_pin_power_state(codec, 0x2b, &parm);
	snd_hda_codec_write(codec, 0xa, 0, AC_VERB_SET_POWER_STATE, parm);

	/* PW0 (24h), AOW0 (8h) */
	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x24, &parm);
	if (!spec->hp_independent_mode){ /* check for redirected HP */
		unsigned int parm_hp = AC_PWRST_D3;
		set_pin_power_state( codec, 0x28, &parm_hp );
		snd_hda_codec_write( codec, 0x1b, 0,
				    AC_VERB_SET_POWER_STATE, parm_hp );
		snd_hda_codec_write( codec, 0x34, 0,
				    AC_VERB_SET_POWER_STATE, parm_hp );
		/* in redirected mode, hp_nid isn't in use */
		snd_hda_codec_write( codec, spec->multiout.hp_nid, 0,
				    AC_VERB_SET_POWER_STATE, AC_PWRST_D3 );
		if( parm_hp == AC_PWRST_D0 )
			parm = AC_PWRST_D0;
	}
	snd_hda_codec_write(codec, 0x8, 0, AC_VERB_SET_POWER_STATE, parm);

	/* MW9 (21h), Mw2 (1ah), AOW0 (8h) */
	/* don't understand  above comment - may guess dependence on front
dac, but am unsure...
	   and can't see any dependence on MW 1ah */
	snd_hda_codec_write( codec, 0x21, 0, AC_VERB_SET_POWER_STATE,
		   imux_is_smixer[ 0 ] || imux_is_mixer[ 1 ] ? AC_PWRST_D0 : parm );

	/* PW1 (25h), AOW1 (9h) */
	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x25, &parm);
	if (spec->smart51_enabled)
		set_pin_power_state(codec, 0x2a, &parm);
	snd_hda_codec_write(codec, 0x9, 0, AC_VERB_SET_POWER_STATE, parm);

	if (spec->hp_independent_mode) {
		/* PW4 (28h), MW3 (1bh), MUX1(34h), AOW4 (ch) */
		parm = AC_PWRST_D3;
		set_pin_power_state(codec, 0x28, &parm);
		snd_hda_codec_write(codec, 0x1b, 0,
				    AC_VERB_SET_POWER_STATE, parm);
		snd_hda_codec_write(codec, 0x34, 0,
				    AC_VERB_SET_POWER_STATE, parm);
		snd_hda_codec_write(codec, spec->multiout.hp_nid, 0,
				    AC_VERB_SET_POWER_STATE, parm);
	}
}


(if applicable to actual implementation, any occurrence of
spec->multiout.hp_nid should be replaced with spec->hp_dac_nid - the
above doesn't yet take care of the possible re-tasking of line-in as
side, which I didn't try)


----

But let's come back to current state. There could be an initialization
verb missing from array  vt1718S_init_verbs and present in old
vt1718S_volume_init_verbs, which is "almost" a vendor-specific verb,
to un-mute the apparently non-existent (not seen by the driver)
connection at index #5 for stereo mixer (0x21):


static const struct hda_verb vt1718S_init_verbs[] = {
	/* Enable MW0 adjust Gain 5 */
	{0x1, 0xfb2, 0x10},
	/* Enable Boost Volume backdoor */
	{0x1, 0xf88, 0x8},
+	/* Unmute front dac connection to stereo mixer */
+	{0x21, AC_VERB_SET_AMP_GAIN_MUTE, AMP_IN_UNMUTE(5)},

	{ }
};


If I remember well what Lydia Wang told me in another thread, 0x21 is
connected to a dac (should be the front dac), even if the connection
isn't visible through the driver. Without that verb, if I set 'stereo
mixer' as first input source and try to record some playback, I get
only noise, with such initialization I can record an ongoing playback
(eventually mixed with other sound, e.g. from my mic). Such a result
tells me nid 0x8 (front dac, the only involved in my recording test)
should work properly even if no sound gets to front line-out pin
(0x24). A side effect of this, however, is that, depending on volumes
settings, whatever widget getting input also by 0x21 (and if such
connection isn't muted), will get sound by 0x8 while playing - e.g. I
can hear, at a lower volume, a playback setup for the front dac from
my headset even when Independent HP is set to ON; on the other hand,
lowering volumes attenuates such, but playback may become unrecordable
(due to volume being too low).


I'm attaching alsa-info.sh output for both the original version of
this new implementation (latest version from tarballs, described at
the beginning) and the modified version I'm using to both make
Independent HP work and activate that "hidden" connection for stereo
mixer. Though, it looks like they don't tell much about the problem
with front audio from front pin (I've compiled drivers with verbose
debug).

One notably thing is that the new (for codec VT1718S family) Master
control misses a few slaves, mainly:

- as expectable, there's neither a "Side Playback Volume" nor a "Side
Playback Switch", since there's no grey jack (to support 7.1 systems,
my motherboard line-in (0x2a) should be re-tasked as output and get
input from the now available 0xc, which is no more used by headphones)

- more noticeably, there's no "Headphone Playback Volume" control.
There was one in old implementation, explicitly created by
vt1718S_auto_create_hp_ctls(); within that function it was easy to
bind that control to the actual hp_nid (replacing any occurrence of
0xc with spec->multiout.hp_nid in all relevant functions, the switch
from 0xc to 0xb was complete), given that the only reason to test
usability of dac at 0xb for headphone was, initially, to check whether
0xc could be freed for use with 0x2a as side (and ensure, or confirm,
this codec family can handle as much as 10 channels - but to confirm
it definitely an attempt to retask 0x2a should be made).


Moreover, looking at codec informations, now control "Independent HP"
is attached to hp pin, altogether with control "Headphone Playback
Switch". This should be somehow more consistent with those codecs not
using an intermidiate selector to choose the nid to get sound from
(perhaps the majority), so that such control always sticks in same (or
corresponding) places. However, this way there is more 'distance'
between such control and the 'real' nid it works on.


A final (minor) question/consideration on the code. I've noticed now
.put helpers validate data gathered from userspace (typically, passed
through ucontrol parameter), which is a good choice to protect against
some bug external to the driver; however, if I'm not mistaken,
via_mux_enum_put (and corresponding _get) could still be missing
something: since any data in ucontrol->id is passed as is to
snd_ctl_get_ioffidx, is there any chance that the result could be an
invalid index? If that's possible, perhaps such value should be
validated as well, comparing it to the max number of mux nids,
eventually defined in a constant for easier maintenance, such as:

#define VIA_NUM_MUXS   3

then, in struct via_spec:

-	hda_nid_t mux_nids[3];
+	hda_nid_t mux_nids[ VIA_NUM_MUXS ];
	hda_nid_t aa_mix_nid;

...

	struct via_input inputs[AUTO_CFG_MAX_INS + 1];
-	unsigned int cur_mux[3];
+	unsigned int cur_mux[ VIA_NUM_MUXS ];


then, in via_mux_enum_put() (same for via_mux_enum_get)

either:

	if( idx >= VIA_NUM_MUXS )
		return -EINVAL;

or:

	if( idx >= VIA_NUM_MUXS )
		/* recovering from wrong value, assuming the last valid entry was
the real target */
		idx = VIA_NUM_MUXS -1;

(more applicable for via_mux_enum_get)

The latter strategy suggested by analogy with similar implementation
of data correctness control in snd_hda_input_mux_put (previously used)
and by comparison with other recovery attempts made in .put helpers,
such as double negation of ucontrol->value.enumerated.item[0] in
via_independent_hp_put and the single negation in
via_pin_power_ctl_{get, put} to always get one of the two only
possible values in that contexts (0 or 1). Perhaps the same should be
done in via_smart51_put() as well, to 'normalize'
*ucontrol->value.integer.value as boolean before assigning it to
spec->smart51_enabled, maybe returning immediately if old and new
values match against each other (as done in via_independent_hp_put and
via_pin_power_ctl_put) -- Possibly, the same might apply to
vt1716s_dmic_{get,put} helpers, but only if nid 0x26 had just two
connections (I was considering it for the old code too, but I haven't
been able to find any info about VT1716S).

Regards,

Alex

[-- Attachment #2: alsa-info.tar.gz --]
[-- Type: application/x-gzip, Size: 13898 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-02 16:00   ` alex dot baldacchino dot alsasub at gmail dot com
@ 2011-07-04 12:55     ` Takashi Iwai
  2011-07-04 14:02       ` Takashi Iwai
  2011-07-06  0:49       ` alex dot baldacchino dot alsasub at gmail dot com
  0 siblings, 2 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-07-04 12:55 UTC (permalink / raw)
  To: alex dot baldacchino dot alsasub at gmail dot com
  Cc: Raymond Yau, ALSA Development Mailing List, haraldwelte, lydiawang

At Sat, 2 Jul 2011 18:00:27 +0200,
alex dot baldacchino dot alsasub at gmail dot com wrote:
> 
> 2011/6/22 Takashi Iwai <tiwai@suse.de>:
> > At Mon, 20 Jun 2011 17:06:51 +0200,
> > Takashi Iwai wrote:
> >>
> >> Hi,
> >>
> >> as there have many problems reported for VIA codecs, I started looking
> >> at the driver code, and decided to rework on it.
> >> [...]
> 
> I've installed and tested (from tarballs) both snapshot
> alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz)
> - up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang,
> I think.
> 
> I've found problems with both. That's a quite huge change in the
> implementation from older code, so I need to study it more in depth to
> understand it better... At the moment I can only describe the problems
> and give my first impressions on them.
> 
> First of all, I can't get sound from the front playback (rear
> line-out).
...
> If I remember well what Lydia Wang told me in another thread, 0x21 is
> connected to a dac (should be the front dac), even if the connection
> isn't visible through the driver. Without that verb, if I set 'stereo
> mixer' as first input source and try to record some playback, I get
> only noise, with such initialization I can record an ongoing playback
> (eventually mixed with other sound, e.g. from my mic). Such a result
> tells me nid 0x8 (front dac, the only involved in my recording test)
> should work properly even if no sound gets to front line-out pin
> (0x24). A side effect of this, however, is that, depending on volumes
> settings, whatever widget getting input also by 0x21 (and if such
> connection isn't muted), will get sound by 0x8 while playing - e.g. I
> can hear, at a lower volume, a playback setup for the front dac from
> my headset even when Independent HP is set to ON; on the other hand,
> lowering volumes attenuates such, but playback may become unrecordable
> (due to volume being too low).

These should be fixed now by Lydia's patch.  I updated sound git
tree and snapshot tarball now.  Please check it later.


> One notably thing is that the new (for codec VT1718S family) Master
> control misses a few slaves, mainly:
> 
> - as expectable, there's neither a "Side Playback Volume" nor a "Side
> Playback Switch", since there's no grey jack (to support 7.1 systems,
> my motherboard line-in (0x2a) should be re-tasked as output and get
> input from the now available 0xc, which is no more used by headphones)
> 
> - more noticeably, there's no "Headphone Playback Volume" control.
> There was one in old implementation, explicitly created by
> vt1718S_auto_create_hp_ctls(); within that function it was easy to
> bind that control to the actual hp_nid (replacing any occurrence of
> 0xc with spec->multiout.hp_nid in all relevant functions, the switch
> from 0xc to 0xb was complete), given that the only reason to test
> usability of dac at 0xb for headphone was, initially, to check whether
> 0xc could be freed for use with 0x2a as side (and ensure, or confirm,
> this codec family can handle as much as 10 channels - but to confirm
> it definitely an attempt to retask 0x2a should be made).
> 
> 
> Moreover, looking at codec informations, now control "Independent HP"
> is attached to hp pin, altogether with control "Headphone Playback
> Switch". This should be somehow more consistent with those codecs not
> using an intermidiate selector to choose the nid to get sound from
> (perhaps the majority), so that such control always sticks in same (or
> corresponding) places. However, this way there is more 'distance'
> between such control and the 'real' nid it works on.

Hm, I'll check this with your alsa-info.sh output.


> A final (minor) question/consideration on the code. I've noticed now
> .put helpers validate data gathered from userspace (typically, passed
> through ucontrol parameter), which is a good choice to protect against
> some bug external to the driver; however, if I'm not mistaken,
> via_mux_enum_put (and corresponding _get) could still be missing
> something: since any data in ucontrol->id is passed as is to
> snd_ctl_get_ioffidx, is there any chance that the result could be an
> invalid index?

No, such an invalid id will be filtered out in the upper layer.


thanks,

Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-04 12:55     ` Takashi Iwai
@ 2011-07-04 14:02       ` Takashi Iwai
  2011-07-06  0:55         ` alex dot baldacchino dot alsasub at gmail dot com
  2011-07-06  0:49       ` alex dot baldacchino dot alsasub at gmail dot com
  1 sibling, 1 reply; 19+ messages in thread
From: Takashi Iwai @ 2011-07-04 14:02 UTC (permalink / raw)
  To: alex dot baldacchino dot alsasub at gmail dot com
  Cc: Raymond Yau, ALSA Development Mailing List, haraldwelte, lydiawang

At Mon, 04 Jul 2011 14:55:31 +0200,
Takashi Iwai wrote:
> 
> > One notably thing is that the new (for codec VT1718S family) Master
> > control misses a few slaves, mainly:
> > 
> > - as expectable, there's neither a "Side Playback Volume" nor a "Side
> > Playback Switch", since there's no grey jack (to support 7.1 systems,
> > my motherboard line-in (0x2a) should be re-tasked as output and get
> > input from the now available 0xc, which is no more used by headphones)
> > 
> > - more noticeably, there's no "Headphone Playback Volume" control.
> > There was one in old implementation, explicitly created by
> > vt1718S_auto_create_hp_ctls(); within that function it was easy to
> > bind that control to the actual hp_nid (replacing any occurrence of
> > 0xc with spec->multiout.hp_nid in all relevant functions, the switch
> > from 0xc to 0xb was complete), given that the only reason to test
> > usability of dac at 0xb for headphone was, initially, to check whether
> > 0xc could be freed for use with 0x2a as side (and ensure, or confirm,
> > this codec family can handle as much as 10 channels - but to confirm
> > it definitely an attempt to retask 0x2a should be made).
> > 
> > 
> > Moreover, looking at codec informations, now control "Independent HP"
> > is attached to hp pin, altogether with control "Headphone Playback
> > Switch". This should be somehow more consistent with those codecs not
> > using an intermidiate selector to choose the nid to get sound from
> > (perhaps the majority), so that such control always sticks in same (or
> > corresponding) places. However, this way there is more 'distance'
> > between such control and the 'real' nid it works on.
> 
> Hm, I'll check this with your alsa-info.sh output.

The missing headphone-volume control is fixed now with the commit
18bd2c44b9c7f0ee775e756dd59e12e0939f7ab9
    ALSA: hda - Create HP-vol control properly for VIA codecs
    
For the retasking for a side-channel, I'm still considering what would
be the best.  Currently we have smart51 control while other driver
has "Channel Mode" enum control.  I think the latter can be used more
generically for both smart51 and side-channel re-tasking.


Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-06-22 14:28 ` Takashi Iwai
  2011-07-02 16:00   ` alex dot baldacchino dot alsasub at gmail dot com
@ 2011-07-04 19:37   ` Jan Binder
  2011-07-05  5:25     ` Takashi Iwai
  1 sibling, 1 reply; 19+ messages in thread
From: Jan Binder @ 2011-07-04 19:37 UTC (permalink / raw)
  To: alsa-devel
  Cc: Takashi Iwai, Raymond Yau, alex.baldacchino.alsasub, haraldwelte,
	lydiawang

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

Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
> At Mon, 20 Jun 2011 17:06:51 +0200,
> 
> Takashi Iwai wrote:
> > Hi,
> > 
> > as there have many problems reported for VIA codecs, I started looking
> > at the driver code, and decided to rework on it.
> > [snip]

After not being able to compile the kernel from git, I now compiled modules 
from today's snapshot (up to 7b5017f56c69ef88f92e6472ec2578708b892211).

I will describe what worked for me and what did not, as I lack the experience 
to point to details in the code.

* When enabling Dynamic Power-Control in alsamixer, I get no sound, except on 
the internal SPDIF output.

* Independent HP worked, when I could turn it on in alsamixer and correctly 
produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable 
Independent HP in alsamixer, sometimes it would not change status ans aplay 
claimed that hw:0,2,0 was busy.

* Headphone automute (muting rear line out when headphones are plugged in, if 
I understand correctly) does not seem to work in any setting.

* I can only get SPDIF output from the internal connector on the mainboard 
(pin 0x20 if I interpret hda-analyzer correctly) and not from the SPDIF socket 
on the rear panel.
It looks like this might be pin 0x21, which looks like an SPDIF Input in hda-
analyzer, but the mainboard manual says that this should be an output.

* Output of alsa-info.sh is attached.

Regards,
Jan

[-- Attachment #2: VT1708B_8-Ch_alsa-info.txt --]
[-- Type: text/plain, Size: 35989 bytes --]

upload=true&script=true&cardinfo=
!!################################
!!ALSA Information Script v 0.4.60
!!################################

!!Script ran on: Mon Jul  4 19:02:22 UTC 2011


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

Debian GNU/Linux wheezy/sid \n \l


!!DMI Information
!!---------------

Manufacturer:      System manufacturer
Product Name:      System Product Name
Product Version:   System Version


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

Kernel release:    3.0.0-rc5-amd64
Operating System:  GNU/Linux
Architecture:      x86_64
Processor:         unknown
SMP Enabled:       Yes


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

Driver version:     1.0.24
Library version:    1.0.23
Utilities version:  1.0.23


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

snd_hda_intel
snd_hda_intel


!!Sound Servers on this system
!!----------------------------

Pulseaudio:
      Installed - Yes (/usr/bin/pulseaudio)
      Running - Yes

ESound Daemon:
      Installed - Yes (/usr/bin/esd)
      Running - No

aRts:
      Installed - Yes (/usr/bin/artsd)
      Running - No

Jack:
      Installed - Yes (/usr/bin/jackd)
      Running - No


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

 0 [SB             ]: HDA-Intel - HDA ATI SB
                      HDA ATI SB at 0xfbcf4000 irq 16
 1 [HDMI           ]: HDA-Intel - HDA ATI HDMI
                      HDA ATI HDMI at 0xfbdec000 irq 44


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

00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
01:00.1 Audio device: ATI Technologies Inc HD48x0 audio


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

00:14.2 0403: 1002:4383
	Subsystem: 1043:8345
--
01:00.1 0403: 1002:aa30
	Subsystem: 174b:aa30


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

snd-atiixp-modem: index=-2
snd-intel8x0m: index=-2
snd-via82xx-modem: index=-2
snd-pcsp: index=-2
snd-usb-audio: index=-2


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

!!Module: snd_hda_intel
	bdl_pos_adj : 32,32,-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
	beep_mode : 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 : -1
	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 : (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)
	patch : (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)
	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 : 0
	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
	probe_only : 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
	single_cmd : N

!!Module: snd_hda_intel
	bdl_pos_adj : 32,32,-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
	beep_mode : 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 : -1
	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 : (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)
	patch : (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)
	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 : 0
	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
	probe_only : 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
	single_cmd : N


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

Codec: VIA VT1708B 8-Ch
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x1106e721
Subsystem Id: 0x10438345
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
    rates [0x0]:
    bits [0x0]:
    formats [0x0]:
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x10 [Audio Output] wcaps 0x411: Stereo
  Device: name="VT1708B 8-Ch Analog", type="Audio", device=0
  Converter: stream=5, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x11 [Audio Output] wcaps 0x411: Stereo
  Converter: stream=5, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x12 [Audio Output] wcaps 0x611: Stereo Digital
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
  Device: name="VT1708B 8-Ch Digital", type="SPDIF", device=1
  Converter: stream=8, channel=0
  Digital: Enabled GenLevel
  Digital category: 0x2
  PCM:
    rates [0x1e0]: 44100 48000 88200 96000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x13 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Control: name="Capture Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Capture Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Device: name="VT1708B 8-Ch Analog", type="Audio", device=0
  Amp-In caps: ofs=0x00, nsteps=0x14, stepsize=0x06, mute=1
  Amp-In vals:  [0x00 0x00]
  Converter: stream=1, channel=0
  SDI-Select: 0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x17
Node 0x14 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Control: name="Capture Volume", index=1, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Capture Switch", index=1, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x14, stepsize=0x06, mute=1
  Amp-In vals:  [0x00 0x00]
  Converter: stream=2, channel=0
  SDI-Select: 0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x1e
Node 0x15 [Audio Input] wcaps 0x100711: Stereo Digital
  Converter: stream=0, channel=0
  SDI-Select: 0
  Digital:
  Digital category: 0x0
  PCM:
    rates [0x1f0]: 32000 44100 48000 88200 96000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x21
Node 0x16 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In
  Control: name="PCM Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="PCM Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Rear Mic Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=2, ofs=0
  Control: name="Rear Mic Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=2, ofs=0
  Control: name="Front Mic Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=4, ofs=0
  Control: name="Front Mic Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=4, ofs=0
  Control: name="Line Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=3, ofs=0
  Control: name="Line Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=3, ofs=0
  Control: name="CD Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=1, ofs=0
  Control: name="CD Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=1, ofs=0
  Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x06, mute=1
  Amp-In vals:  [0x0c 0x0c] [0x80 0x80] [0x80 0x80] [0x8c 0x8c] [0x1f 0x1f] [0x80 0x80]
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 6
     0x10 0x1f 0x1a 0x1b 0x1e 0x25
Node 0x17 [Audio Selector] wcaps 0x300501: Stereo
  Control: name="Input Source", index=0, device=0
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 5
     0x16 0x1f 0x1a 0x1b 0x1e*
Node 0x18 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
  Control: name="Surround Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Surround Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x1b, nsteps=0x1b, stepsize=0x06, mute=1
  Amp-Out vals:  [0x1b 0x1b]
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x11
Node 0x19 [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x0000001c: OUT HP Detect
  Pin Default 0x01011012: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Black
    DefAssociation = 0x1, Sequence = 0x2
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x18
Node 0x1a [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x00002334: IN OUT Detect
    Vref caps: HIZ 50 100
  Pin Default 0x01a19036: [Jack] Mic at Ext Rear
    Conn = 1/8, Color = Pink
    DefAssociation = 0x3, Sequence = 0x6
  Pin-ctls: 0x21: IN VREF_50
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x26
Node 0x1b [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x00002334: IN OUT Detect
    Vref caps: HIZ 50 100
  Pin Default 0x0181303e: [Jack] Line In at Ext Rear
    Conn = 1/8, Color = Blue
    DefAssociation = 0x3, Sequence = 0xe
  Pin-ctls: 0x20: IN VREF_HIZ
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x18
Node 0x1c [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Front Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Front Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x1b, nsteps=0x1b, stepsize=0x06, mute=1
  Amp-Out vals:  [0x1a 0x1a]
  Pincap 0x0000001c: OUT HP Detect
  Pin Default 0x01014010: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x16
Node 0x1d [Pin Complex] wcaps 0x40058d: Stereo Amp-Out
  Control: name="Headphone Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Independent HP", index=0, device=0
  Amp-Out caps: ofs=0x1b, nsteps=0x1b, stepsize=0x06, mute=1
  Amp-Out vals:  [0x1b 0x1b]
  Pincap 0x0000001c: OUT HP Detect
  Pin Default 0x0221401f: [Jack] HP Out at Ext Front
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0xf
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=21, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 2
     0x16* 0x25
Node 0x1e [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x00002334: IN OUT Detect
    Vref caps: HIZ 50 100
  Pin Default 0x02a19038: [Jack] Mic at Ext Front
    Conn = 1/8, Color = Pink
    DefAssociation = 0x3, Sequence = 0x8
  Pin-ctls: 0x21: IN VREF_50
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x27
Node 0x1f [Pin Complex] wcaps 0x400401: Stereo
  Pincap 0x00000020: IN
  Pin Default 0x90370137: [Fixed] CD at Int N/A
    Conn = Analog, Color = Unknown
    DefAssociation = 0x3, Sequence = 0x7
    Misc = NO_PRESENCE
  Pin-ctls: 0x20: IN
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x20 [Pin Complex] wcaps 0x400701: Stereo Digital
  Pincap 0x00000010: OUT
  Pin Default 0x074311f0: [Jack] SPDIF Out at Ext Rear Panel
    Conn = ATAPI, Color = Black
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x12
Node 0x21 [Pin Complex] wcaps 0x400601: Stereo Digital
  Pincap 0x00010030: IN OUT EAPD
  EAPD 0x0:
  Pin Default 0x47c421f0: [N/A] SPDIF In at Ext Rear Panel
    Conn = RCA, Color = Grey
    DefAssociation = 0xf, Sequence = 0x0
    Misc = NO_PRESENCE
  Pin-ctls: 0x40: OUT
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x22 [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x00000014: OUT Detect
  Pin Default 0x01016011: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Orange
    DefAssociation = 0x1, Sequence = 0x1
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x26
Node 0x23 [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x00000014: OUT Detect
  Pin Default 0x01012014: [Jack] Line Out at Ext Rear
    Conn = 1/8, Color = Grey
    DefAssociation = 0x1, Sequence = 0x4
  Pin-ctls: 0x40: OUT
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x27
Node 0x24 [Audio Output] wcaps 0x411: Stereo
  Converter: stream=5, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x25 [Audio Output] wcaps 0x411: Stereo
  Device: name="VT1708B 8-Ch HP", type="Audio", device=2
  Converter: stream=5, channel=0
  PCM:
    rates [0x5e0]: 44100 48000 88200 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
Node 0x26 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
  Control: name="Center Playback Volume", index=0, device=0
    ControlAmp: chs=1, dir=Out, idx=0, ofs=0
  Control: name="Center Playback Switch", index=0, device=0
    ControlAmp: chs=1, dir=Out, idx=0, ofs=0
  Control: name="LFE Playback Volume", index=0, device=0
    ControlAmp: chs=2, dir=Out, idx=0, ofs=0
  Control: name="LFE Playback Switch", index=0, device=0
    ControlAmp: chs=2, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x1b, nsteps=0x1b, stepsize=0x06, mute=1
  Amp-Out vals:  [0x1b 0x1b]
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x24
Node 0x27 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
  Control: name="Side Playback Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Side Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x1b, nsteps=0x1b, stepsize=0x06, mute=1
  Amp-Out vals:  [0x1b 0x1b]
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x25
Codec: ATI R6xx HDMI
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x1002aa01
Subsystem Id: 0x00aa0100
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
    rates [0x70]: 32000 44100 48000
    bits [0x2]: 16
    formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
GPIO: io=0, o=0, i=0, unsolicited=0, wake=0
Node 0x02 [Audio Output] wcaps 0x201: Stereo Digital
  Converter: stream=1, channel=0
  Digital: Enabled GenLevel
  Digital category: 0x2
Node 0x03 [Pin Complex] wcaps 0x400381: Stereo Digital
  Control: name="IEC958 Playback Con Mask", index=0, device=0
  Control: name="IEC958 Playback Pro Mask", index=0, device=0
  Control: name="IEC958 Playback Default", index=0, device=0
  Control: name="IEC958 Playback Switch", index=0, device=0
  Pincap 0x00000094: OUT Detect HDMI
  Pin Default 0x18560010: [Jack] Digital Out at Int HDMI
    Conn = Digital, Color = Unknown
    DefAssociation = 0x1, Sequence = 0x0
  Pin-ctls: 0x00:
  Unsolicited: tag=03, enabled=1
  Connection: 1
     0x02
--endcollapse--


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

crw-rw----+ 1 root audio 116,  7 Jul  4 20:24 /dev/snd/controlC0
crw-rw----+ 1 root audio 116, 10 Jul  4 20:24 /dev/snd/controlC1
crw-rw----+ 1 root audio 116,  6 Jul  4 20:24 /dev/snd/hwC0D0
crw-rw----+ 1 root audio 116,  9 Jul  4 20:24 /dev/snd/hwC1D0
crw-rw----+ 1 root audio 116,  5 Jul  4 20:49 /dev/snd/pcmC0D0c
crw-rw----+ 1 root audio 116,  4 Jul  4 21:01 /dev/snd/pcmC0D0p
crw-rw----+ 1 root audio 116,  3 Jul  4 21:01 /dev/snd/pcmC0D1p
crw-rw----+ 1 root audio 116,  2 Jul  4 20:24 /dev/snd/pcmC0D2p
crw-rw----+ 1 root audio 116,  8 Jul  4 20:29 /dev/snd/pcmC1D3p
crw-rw----+ 1 root audio 116,  1 Jul  4 20:24 /dev/snd/seq
crw-rw----+ 1 root audio 116, 33 Jul  4 20:24 /dev/snd/timer

/dev/snd/by-path:
total 0
drwxr-xr-x 2 root root  80 Jul  4 20:24 .
drwxr-xr-x 3 root root 280 Jul  4 20:24 ..
lrwxrwxrwx 1 root root  12 Jul  4 20:24 pci-0000:00:14.2 -> ../controlC0
lrwxrwxrwx 1 root root  12 Jul  4 20:24 pci-0000:01:00.1 -> ../controlC1


!!ALSA configuration files
!!------------------------

!!System wide config file (/etc/asound.conf)


pcm.!default {
	type pulse
}

ctl.!default {
	type pulse
}

pcm.pulse {
	type pulse
}

ctl.pulse {
	type pulse
}


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

APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: VT1708B 8-Ch Analog [VT1708B 8-Ch Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 1: VT1708B 8-Ch Digital [VT1708B 8-Ch Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 2: VT1708B 8-Ch HP [VT1708B 8-Ch HP]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: HDMI [HDA ATI HDMI], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: VT1708B 8-Ch Analog [VT1708B 8-Ch Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1

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

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

Card hw:0 'SB'/'HDA ATI SB at 0xfbcf4000 irq 16'
  Mixer name	: 'VIA VT1708B 8-Ch'
  Components	: 'HDA:1106e721,10438345,00100100'
  Controls      : 36
  Simple ctrls  : 19
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 27
  Mono: Playback 27 [100%] [6.75dB] [on]
Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 27
  Mono:
  Front Left: Playback 27 [100%] [0.00dB] [on]
  Front Right: Playback 27 [100%] [0.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 12 [39%] [-19.25dB] [on]
  Front Right: Playback 12 [39%] [-19.25dB] [on]
Simple mixer control 'Front',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 27
  Mono:
  Front Left: Playback 26 [96%] [-1.75dB] [on]
  Front Right: Playback 26 [96%] [-1.75dB] [on]
Simple mixer control 'Front Mic',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 31 [100%] [14.00dB] [on]
  Front Right: Playback 31 [100%] [14.00dB] [on]
Simple mixer control 'Surround',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 27
  Mono:
  Front Left: Playback 27 [100%] [0.00dB] [on]
  Front Right: Playback 27 [100%] [0.00dB] [on]
Simple mixer control 'Center',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 27
  Mono: Playback 27 [100%] [0.00dB] [on]
Simple mixer control 'LFE',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 27
  Mono: Playback 27 [100%] [0.00dB] [on]
Simple mixer control 'Side',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 27
  Mono:
  Front Left: Playback 27 [100%] [0.00dB] [on]
  Front Right: Playback 27 [100%] [0.00dB] [on]
Simple mixer control 'Line',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 12 [39%] [-19.25dB] [off]
  Front Right: Playback 12 [39%] [-19.25dB] [off]
Simple mixer control 'CD',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-40.25dB] [off]
  Front Right: Playback 0 [0%] [-40.25dB] [off]
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]
Simple mixer control 'IEC958 Default PCM',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [off]
Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 20
  Front Left: Capture 0 [0%] [0.00dB] [on]
  Front Right: Capture 0 [0%] [0.00dB] [on]
Simple mixer control 'Capture',1
  Capabilities: cvolume cswitch penum
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 20
  Front Left: Capture 0 [0%] [0.00dB] [on]
  Front Right: Capture 0 [0%] [0.00dB] [on]
Simple mixer control 'Dynamic Power-Control',0
  Capabilities: enum
  Items: 'Disabled' 'Enabled'
  Item0: 'Disabled'
Simple mixer control 'Independent HP',0
  Capabilities: enum
  Items: 'OFF' 'ON'
  Item0: 'OFF'
Simple mixer control 'Input Source',0
  Capabilities: cenum
  Items: 'Rear Mic' 'Front Mic' 'Line' 'CD' 'Stereo Mixer'
  Item0: 'Front Mic'
Simple mixer control 'Rear Mic',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 0 [0%] [-40.25dB] [off]
  Front Right: Playback 0 [0%] [-40.25dB] [off]

!!-------Mixer controls for card 1 [HDMI]

Card hw:1 'HDMI'/'HDA ATI HDMI at 0xfbdec000 irq 44'
  Mixer name	: 'ATI R6xx HDMI'
  Components	: 'HDA:1002aa01,00aa0100,00100100'
  Controls      : 4
  Simple ctrls  : 1
Simple mixer control 'IEC958',0
  Capabilities: pswitch pswitch-joined penum
  Playback channels: Mono
  Mono: Playback [on]


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

--startcollapse--
state.SB {
	control.1 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 27'
		comment.dbmin -4725
		comment.dbmax 0
		iface MIXER
		name 'Front Playback Volume'
		value.0 26
		value.1 26
	}
	control.2 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Front Playback Switch'
		value.0 true
		value.1 true
	}
	control.3 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 27'
		comment.dbmin -4725
		comment.dbmax 0
		iface MIXER
		name 'Surround Playback Volume'
		value.0 27
		value.1 27
	}
	control.4 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Surround Playback Switch'
		value.0 true
		value.1 true
	}
	control.5 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 27'
		comment.dbmin -4725
		comment.dbmax 0
		iface MIXER
		name 'Center Playback Volume'
		value 27
	}
	control.6 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Center Playback Switch'
		value true
	}
	control.7 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 27'
		comment.dbmin -4725
		comment.dbmax 0
		iface MIXER
		name 'LFE Playback Volume'
		value 27
	}
	control.8 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'LFE Playback Switch'
		value true
	}
	control.9 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 27'
		comment.dbmin -4725
		comment.dbmax 0
		iface MIXER
		name 'Side Playback Volume'
		value.0 27
		value.1 27
	}
	control.10 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Side Playback Switch'
		value.0 true
		value.1 true
	}
	control.11 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 31'
		comment.dbmin -4025
		comment.dbmax 1400
		iface MIXER
		name 'PCM Playback Volume'
		value.0 12
		value.1 12
	}
	control.12 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'PCM Playback Switch'
		value.0 true
		value.1 true
	}
	control.13 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 27'
		comment.dbmin -4725
		comment.dbmax 0
		iface MIXER
		name 'Headphone Playback Volume'
		value.0 27
		value.1 27
	}
	control.14 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Headphone Playback Switch'
		value.0 true
		value.1 true
	}
	control.15 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 20'
		comment.dbmin 0
		comment.dbmax 3500
		iface MIXER
		name 'Capture Volume'
		value.0 0
		value.1 0
	}
	control.16 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Capture Switch'
		value.0 true
		value.1 true
	}
	control.17 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 20'
		comment.dbmin 0
		comment.dbmax 3500
		iface MIXER
		name 'Capture Volume'
		index 1
		value.0 0
		value.1 0
	}
	control.18 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Capture Switch'
		index 1
		value.0 true
		value.1 true
	}
	control.19 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 'Rear Mic'
		comment.item.1 'Front Mic'
		comment.item.2 Line
		comment.item.3 CD
		comment.item.4 'Stereo Mixer'
		iface MIXER
		name 'Input Source'
		value 'Front Mic'
	}
	control.20 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 31'
		comment.dbmin -4025
		comment.dbmax 1400
		iface MIXER
		name 'Rear Mic Playback Volume'
		value.0 0
		value.1 0
	}
	control.21 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Rear Mic Playback Switch'
		value.0 false
		value.1 false
	}
	control.22 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 31'
		comment.dbmin -4025
		comment.dbmax 1400
		iface MIXER
		name 'Front Mic Playback Volume'
		value.0 31
		value.1 31
	}
	control.23 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Front Mic Playback Switch'
		value.0 true
		value.1 true
	}
	control.24 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 31'
		comment.dbmin -4025
		comment.dbmax 1400
		iface MIXER
		name 'Line Playback Volume'
		value.0 12
		value.1 12
	}
	control.25 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'Line Playback Switch'
		value.0 false
		value.1 false
	}
	control.26 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 2
		comment.range '0 - 31'
		comment.dbmin -4025
		comment.dbmax 1400
		iface MIXER
		name 'CD Playback Volume'
		value.0 0
		value.1 0
	}
	control.27 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 2
		iface MIXER
		name 'CD Playback Switch'
		value.0 false
		value.1 false
	}
	control.28 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 OFF
		comment.item.1 ON
		iface MIXER
		name 'Independent HP'
		value OFF
	}
	control.29 {
		comment.access 'read write'
		comment.type ENUMERATED
		comment.count 1
		comment.item.0 Disabled
		comment.item.1 Enabled
		iface MIXER
		name 'Dynamic Power-Control'
		value Disabled
	}
	control.30 {
		comment.access read
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Con Mask'
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.31 {
		comment.access read
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.32 {
		comment.access 'read write'
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Default'
		value '0482000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.33 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Switch'
		value true
	}
	control.34 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'IEC958 Default PCM Playback Switch'
		value false
	}
	control.35 {
		comment.access 'read write'
		comment.type INTEGER
		comment.count 1
		comment.range '0 - 27'
		comment.dbmin 0
		comment.dbmax 675
		iface MIXER
		name 'Master Playback Volume'
		value 27
	}
	control.36 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'Master Playback Switch'
		value true
	}
}
state.HDMI {
	control.1 {
		comment.access read
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Con Mask'
		value '0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.2 {
		comment.access read
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Pro Mask'
		value '0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.3 {
		comment.access 'read write'
		comment.type IEC958
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Default'
		value '0482000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
	}
	control.4 {
		comment.access 'read write'
		comment.type BOOLEAN
		comment.count 1
		iface MIXER
		name 'IEC958 Playback Switch'
		value true
	}
}
--endcollapse--


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

Module
powernow_k8
cpufreq_userspace
cpufreq_stats
cpufreq_powersave
cpufreq_conservative
mperf
battery
ppdev
lp
rfcomm
bnep
tun
vboxnetadp
vboxnetflt
vboxdrv
binfmt_misc
fuse
nfsd
nfs
lockd
fscache
auth_rpcgss
nfs_acl
sunrpc
bridge
stp
ext4
jbd2
ext3
jbd
mbcache
lirc_dev
it87
hwmon_vid
loop
btusb
bluetooth
rfkill
crc16
cdc_acm
joydev
snd_hda_codec_hdmi
snd_hda_codec_via
snd_hda_intel
snd_hda_codec
radeon
snd_hwdep
snd_pcm_oss
ttm
snd_mixer_oss
sp5100_tco
snd_pcm
drm_kms_helper
snd_seq_dummy
drm
snd_seq_oss
i2c_algo_bit
snd_seq_midi
i2c_piix4
snd_rawmidi
snd_seq_midi_event
snd_seq
i2c_core
snd_timer
pcspkr
snd_seq_device
psmouse
snd
parport_pc
parport
power_supply
k10temp
serio_raw
evdev
asus_atk0110
processor
button
edac_core
edac_mce_amd
thermal_sys
soundcore
snd_page_alloc
jfs
usbhid
hid
raid1
md_mod
sg
sd_mod
sr_mod
cdrom
crc_t10dif
ata_generic
ohci_hcd
ahci
libahci
3c59x
pata_atiixp
libata
r8169
mii
ehci_hcd
scsi_mod
usbcore


!!Sysfs Files
!!-----------

/sys/class/sound/hwC0D0/init_pin_configs:
0x19 0x01011012
0x1a 0x01a19036
0x1b 0x0181303e
0x1c 0x01014010
0x1d 0x0221401f
0x1e 0x02a19038
0x1f 0x90370137
0x20 0x074311f0
0x21 0x47c421f0
0x22 0x01016011
0x23 0x01012014

/sys/class/sound/hwC0D0/driver_pin_configs:

/sys/class/sound/hwC0D0/user_pin_configs:

/sys/class/sound/hwC0D0/init_verbs:

/sys/class/sound/hwC1D0/init_pin_configs:
0x03 0x18560010

/sys/class/sound/hwC1D0/driver_pin_configs:

/sys/class/sound/hwC1D0/user_pin_configs:

/sys/class/sound/hwC1D0/init_verbs:


!!ALSA/HDA dmesg
!!------------------

[    7.713225] [drm] Loading RV770 Microcode
[    7.772444] snd_hda_intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[    7.838526] radeon 0000:01:00.0: WB enabled
--
[    8.581517] [drm] Initialized radeon 2.10.0 20080528 for 0000:01:00.0 on minor 0
[    8.581894] snd_hda_intel 0000:01:00.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
[    8.581983] snd_hda_intel 0000:01:00.1: irq 44 for MSI/MSI-X
[    8.582008] snd_hda_intel 0000:01:00.1: setting latency timer to 64
[    8.636675] HDMI status: Codec=0 Pin=3 Presence_Detect=0 ELD_Valid=0
[    8.636952] input: HDA ATI HDMI HDMI/DP as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input5
[   10.388803] generic-usb 0003:056D:0002.0005: hiddev0,hidraw4: USB HID v1.10 Device [EIZO EIZO USB HID Monitor] on usb-0000:00:12.2-2.3/input0
--
[   54.429850] br0: port 2(ubi) entering forwarding state
[   55.753122] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
[   59.440013] br0: port 2(ubi) entering forwarding state
[   99.875847] EXT4-fs (md8): re-mounted. Opts: commit=0
[ 1060.364957] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.



[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-04 19:37   ` Jan Binder
@ 2011-07-05  5:25     ` Takashi Iwai
  2011-07-05  9:20       ` Raymond Yau
  2011-07-06  0:58       ` alex dot baldacchino dot alsasub at gmail dot com
  0 siblings, 2 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-07-05  5:25 UTC (permalink / raw)
  To: phoenix.diablo
  Cc: Raymond Yau, alsa-devel, alex.baldacchino.alsasub, haraldwelte,
	lydiawang

At Mon, 4 Jul 2011 21:37:46 +0200,
Jan Binder wrote:
> 
> Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
> > At Mon, 20 Jun 2011 17:06:51 +0200,
> > 
> > Takashi Iwai wrote:
> > > Hi,
> > > 
> > > as there have many problems reported for VIA codecs, I started looking
> > > at the driver code, and decided to rework on it.
> > > [snip]
> 
> After not being able to compile the kernel from git, I now compiled modules 
> from today's snapshot (up to 7b5017f56c69ef88f92e6472ec2578708b892211).
> 
> I will describe what worked for me and what did not, as I lack the experience 
> to point to details in the code.
> 
> * When enabling Dynamic Power-Control in alsamixer, I get no sound, except on 
> the internal SPDIF output.

OK, this and the third item make me wonder whether the jack-detection
works on your machine at all.  Could you check it via hda-verb or
whatever?

> * Independent HP worked, when I could turn it on in alsamixer and correctly 
> produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable 
> Independent HP in alsamixer, sometimes it would not change status ans aplay 
> claimed that hw:0,2,0 was busy.

This is intentional.  The switching is racy, so it can't be changed
safely when the multi-channel PCM is opened/used.

> * Headphone automute (muting rear line out when headphones are plugged in, if 
> I understand correctly) does not seem to work in any setting.

See above.

> * I can only get SPDIF output from the internal connector on the mainboard 
> (pin 0x20 if I interpret hda-analyzer correctly) and not from the SPDIF socket 
> on the rear panel.
> It looks like this might be pin 0x21, which looks like an SPDIF Input in hda-
> analyzer, but the mainboard manual says that this should be an output.

You can change the pin 0x21 in user_pin_config sysfs file, then
trigger reconfig sysfs file dynamically.  See
Documentation/sound/alsa/HD-Audio.txt file.

> * Output of alsa-info.sh is attached.

Thanks, I'll check it later.


Takashi

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-05  5:25     ` Takashi Iwai
@ 2011-07-05  9:20       ` Raymond Yau
  2011-07-06  0:58       ` alex dot baldacchino dot alsasub at gmail dot com
  1 sibling, 0 replies; 19+ messages in thread
From: Raymond Yau @ 2011-07-05  9:20 UTC (permalink / raw)
  To: ALSA Development Mailing List

2011/7/5 Takashi Iwai <tiwai@suse.de>:
> At Mon, 4 Jul 2011 21:37:46 +0200,
> Jan Binder wrote:
>
>> * Independent HP worked, when I could turn it on in alsamixer and correctly
>> produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable
>> Independent HP in alsamixer, sometimes it would not change status ans aplay
>> claimed that hw:0,2,0 was busy.
>
> This is intentional.  The switching is racy, so it can't be changed
> safely when the multi-channel PCM is opened/used.
>
>> * Headphone automute (muting rear line out when headphones are plugged in, if
>> I understand correctly) does not seem to work in any setting.
>
> See above.
>

The second ADC can only be connected to Mic at Front Panel ,

It seem that this is a prefect candidate to create device 2 for this
ADC instead of subdevice 1 so that user can use device 2 for the front
panel hp and mic



Node 0x14 [Audio Input] wcaps 0x10051b: Stereo Amp-In
  Control: name="Capture Volume", index=1, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Capture Switch", index=1, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Amp-In caps: ofs=0x00, nsteps=0x14, stepsize=0x06, mute=1
  Amp-In vals:  [0x00 0x00]
  Converter: stream=2, channel=0
  SDI-Select: 0
  PCM:
    rates [0x560]: 44100 48000 96000 192000
    bits [0xa]: 16 24
    formats [0x1]: PCM
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x1e


Node 0x1e [Pin Complex] wcaps 0x400581: Stereo
  Pincap 0x00002334: IN OUT Detect
    Vref caps: HIZ 50 100
  Pin Default 0x02a19038: [Jack] Mic at Ext Front
    Conn = 1/8, Color = Pink
    DefAssociation = 0x3, Sequence = 0x8
  Pin-ctls: 0x21: IN VREF_50
  Unsolicited: tag=20, enabled=1
  Power states:  D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x27



APLAY

**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: VT1708B 8-Ch Analog [VT1708B 8-Ch Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 1: VT1708B 8-Ch Digital [VT1708B 8-Ch Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 2: VT1708B 8-Ch HP [VT1708B 8-Ch HP]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

ARECORD

**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: VT1708B 8-Ch Analog [VT1708B 8-Ch Analog]
  Subdevices: 2/2
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-04 12:55     ` Takashi Iwai
  2011-07-04 14:02       ` Takashi Iwai
@ 2011-07-06  0:49       ` alex dot baldacchino dot alsasub at gmail dot com
  1 sibling, 0 replies; 19+ messages in thread
From: alex dot baldacchino dot alsasub at gmail dot com @ 2011-07-06  0:49 UTC (permalink / raw)
  To: ALSA Development Mailing List
  Cc: Takashi Iwai, Raymond Yau, haraldwelte, lydiawang

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

2011/7/4 Takashi Iwai <tiwai@suse.de>:
> At Sat, 2 Jul 2011 18:00:27 +0200,
> alex dot baldacchino dot alsasub at gmail dot com wrote:
>>
>> 2011/6/22 Takashi Iwai <tiwai@suse.de>:
>> > At Mon, 20 Jun 2011 17:06:51 +0200,
>> > Takashi Iwai wrote:
>> >>
>> >> Hi,
>> >>
>> >> as there have many problems reported for VIA codecs, I started looking
>> >> at the driver code, and decided to rework on it.
>> >> [...]
>>
>> I've installed and tested (from tarballs) both snapshot
>> alsa-driver-20110630 and latest version (alsa-driver-snapshot.tar.gz)
>> - up to commit e5e14681404ec27a422d635284bf564dabde3f81 by Lydia Wang,
>> I think.
>>
>> I've found problems with both. That's a quite huge change in the
>> implementation from older code, so I need to study it more in depth to
>> understand it better... At the moment I can only describe the problems
>> and give my first impressions on them.
>>
>> First of all, I can't get sound from the front playback (rear
>> line-out).
> ...
>
> These should be fixed now by Lydia's patch.  I updated sound git
> tree and snapshot tarball now.  Please check it later.
>

I've been far from my pc yesterday for some reasons, and haven't had
got too much time today as well, but I've gathered latest version of
patch_via.c from
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound-2.6.git;a=commit;h=bac4b92cf7a444c0af8dd7b269c8791595c44052
and made a few tests in different conditions, with following results:

Booting with both front and hp connected:
- no sound from rear green jack (front pin);
- louder and noisier recording of ongoing playback (gives me an idea
of stereo mixer quality);
- louder sound on hp regardless of independent mode being set on or
off, but when nothing is connected to front pin (0x24) - of course,
since nothing connected to 0x24 means parm == AC_PWRST_D3 and HP
Independent mode ON means state of hp pin (0x28) to be disregarded,
thus 0x8 is set to D3 by set_widgets_power_state_vt1718S():


	/* PW0 (24h), AOW0 (8h) */
	parm = AC_PWRST_D3;
	set_pin_power_state(codec, 0x24, &parm);
	if (!spec->hp_independent_mode) /* check for redirected HP */
		set_pin_power_state(codec, 0x28, &parm);
	snd_hda_codec_write(codec, 0x8, 0, AC_VERB_SET_POWER_STATE, parm);


Booting with only front pin connected:
- same as above for recording and sound out of hp pin;
- now I get sound from front pin, thus it would seem that some
automuting is triggered at boot-time (and only at boot-time and/or
driver re-load after rmmod'ing - though not tested - since
detaching/attaching connectors after boot-up/after drivers are loaded
doesn't change such behaviour); such didn't happen in older
implementation (before this rework) and, personally, I preferred that
behavior;
- using same stream settings as front when stream channels are less
then line-outs (for exceeding line-outs) works as well.


Independent HP doesn't work, as before, problem (and fix) still being the same:


--- ./alsa-driver/alsa-kernel/pci/hda/patch_via.c.last	2011-07-05
16:25:35.844001455 +0200
+++ ./alsa-driver/alsa-kernel/pci/hda/patch_via.c	2011-07-05
16:25:23.652001521 +0200
@@ -2974,7 +2974,7 @@ static void set_widgets_power_state_vt17
 				    AC_VERB_SET_POWER_STATE, parm);
 		snd_hda_codec_write(codec, 0x34, 0,
 				    AC_VERB_SET_POWER_STATE, parm);
-		snd_hda_codec_write(codec, 0xc, 0,
+		snd_hda_codec_write(codec, spec->hp_dac_nid, 0,
 				    AC_VERB_SET_POWER_STATE, parm);
 	}
 }



>
>> One notably thing is that the new (for codec VT1718S family) Master
>> control misses a few slaves, mainly:
>> ...
>> - more noticeably, there's no "Headphone Playback Volume" control.
>> ...
>
> Hm, I'll check this with your alsa-info.sh output.
>

Now "Headphone Playback Volume" is back, thanks.

>
>> A final (minor) question/consideration on the code. I've noticed now
>> .put helpers validate data gathered from userspace (typically, passed
>> through ucontrol parameter), which is a good choice to protect against
>> some bug external to the driver; however, if I'm not mistaken,
>> via_mux_enum_put (and corresponding _get) could still be missing
>> something: since any data in ucontrol->id is passed as is to
>> snd_ctl_get_ioffidx, is there any chance that the result could be an
>> invalid index?
>
> No, such an invalid id will be filtered out in the upper layer.
>
>
> thanks,
>
> Takashi
>


Thanks for your clarification.

Attaching alsa-info.sh output for my last test (with the above changes
to make Independent HP work)

Regards,

Alex

[-- Attachment #2: alsa-info.tar.gz --]
[-- Type: application/x-gzip, Size: 7219 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-04 14:02       ` Takashi Iwai
@ 2011-07-06  0:55         ` alex dot baldacchino dot alsasub at gmail dot com
  0 siblings, 0 replies; 19+ messages in thread
From: alex dot baldacchino dot alsasub at gmail dot com @ 2011-07-06  0:55 UTC (permalink / raw)
  To: ALSA Development Mailing List
  Cc: Takashi Iwai, Raymond Yau, haraldwelte, lydiawang

2011/7/4 Takashi Iwai <tiwai@suse.de>:
> At Mon, 04 Jul 2011 14:55:31 +0200,
> Takashi Iwai wrote:
>>
>> > One notably thing is that the new (for codec VT1718S family) Master
>> > control misses a few slaves, mainly:
>> > ...
>> >
>> > - more noticeably, there's no "Headphone Playback Volume" control.
>> > There was one in old implementation, explicitly created by
>> > vt1718S_auto_create_hp_ctls(); within that function it was easy to
>> > bind that control to the actual hp_nid (replacing any occurrence of
>> > 0xc with spec->multiout.hp_nid in all relevant functions, the switch
>> > from 0xc to 0xb was complete), given that the only reason to test
>> > usability of dac at 0xb for headphone was, initially, to check whether
>> > 0xc could be freed for use with 0x2a as side (and ensure, or confirm,
>> > this codec family can handle as much as 10 channels - but to confirm
>> > it definitely an attempt to retask 0x2a should be made).
>> >
>> > ...
>>
>> Hm, I'll check this with your alsa-info.sh output.
>
> The missing headphone-volume control is fixed now with the commit
> 18bd2c44b9c7f0ee775e756dd59e12e0939f7ab9
>    ALSA: hda - Create HP-vol control properly for VIA codecs
>
> For the retasking for a side-channel, I'm still considering what would
> be the best.  Currently we have smart51 control while other driver
> has "Channel Mode" enum control.  I think the latter can be used more
> generically for both smart51 and side-channel re-tasking.
>
>
> Takashi
>


That can be a good choice (at first glance, I'd agree with that). If
choosing to modify smart51 behavior to add side re-tasking, instead,
perhaps the control name exposed to mixers should be changed, to avoid
confusing an end user trying to set up a 7.1 system and finding only
support for 5.1, apparently.

An alternative, for instance, could be using channels' switches
directly and make any change/re-tasking transparent for the user. Such
an implementation would require:

- missing controls (such as side volume/switch) to be created and
(switches) attached to a proper jack pin (basing on common
configurations, and/or on the number of missing jacks - that is, first
fill dacs for existing jacks, than look if anything else can/must be
re-tasked - and/or on what dac is connected with what input pin,
etc.);

- custom .put callbacks to be created, e.g. checking if an independent
jack does exist and is appropriate for that control (for instance
looking at wcaps, defconfig, colour, etc. of passed-in kcontrol nid,
or to values recorded in some struct for that nid), or if that's an
input pin to be re-tasked, and making appropriate choices;

- some coordination with input switches and callbacks, so that when an
input jack is re-tasked as output its corresponding input settings are
registered, its input 'state' is switched to 'off' and its input
controls are made inactive (input controls callbacks should handle the
opposite case, that is re-tasking those jacks as input, resetting old
values/states and deactivating corresponding output controls;
deactivation could be, to say, 'virtual', on the same line as
'Independent HP' .put method, that is taking care of ongoing streaming
and, possibly, ongoing recording, and returning -EBUYSY in such cases,
both to avoid any possible race/conflict, and because playing with
input/output settings and re-tasking while playing/recording, that is
while corresponding jacks are no longer input/output jacks, doesn't
make much sense).

Just a thought.

Regards,

Alex

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-05  5:25     ` Takashi Iwai
  2011-07-05  9:20       ` Raymond Yau
@ 2011-07-06  0:58       ` alex dot baldacchino dot alsasub at gmail dot com
  2011-07-15  6:03         ` Takashi Iwai
  1 sibling, 1 reply; 19+ messages in thread
From: alex dot baldacchino dot alsasub at gmail dot com @ 2011-07-06  0:58 UTC (permalink / raw)
  To: alsa-devel
  Cc: Takashi Iwai, phoenix.diablo, Raymond Yau, lydiawang, haraldwelte

2011/7/5 Takashi Iwai <tiwai@suse.de>:
> At Mon, 4 Jul 2011 21:37:46 +0200,
> Jan Binder wrote:
>>
>> Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
>> > At Mon, 20 Jun 2011 17:06:51 +0200,
>> >
>> > Takashi Iwai wrote:
>> > > Hi,
>> > >
>> > > as there have many problems reported for VIA codecs, I started looking
>> > > at the driver code, and decided to rework on it.
>> > > [snip]
>> * Independent HP worked, when I could turn it on in alsamixer and correctly
>> produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable
>> Independent HP in alsamixer, sometimes it would not change status ans aplay
>> claimed that hw:0,2,0 was busy.
>
> This is intentional.  The switching is racy, so it can't be changed
> safely when the multi-channel PCM is opened/used.
>

Is it alway racy or only for those codecs sharing the same DAC between
hp and side channel and/or requiring same stream as front to be set up
for hp nid as well (e.g. not being connected to the front dac in any
manner, if there is any such a via codec)?

In old implementation via_independent_hp_put() explicitly cleaned up
any ongoing stream for hp dac and updated side mute status; in my case
(vt2020) I didn't noticed errors or problems turning independent mode
on/off several times while playing - I might have been just lucky and
never met races, or just my codec isn't one of the above cases
(indeed, there's no dac shared by hp and side, and my hp pin can be
connected directly to front dac and gets also input by the stereo
mixer being connected to front dac; actually, I haven't been able to
find any info about via codecs with hp pin not being connected to
front dac one way or another, so I don't follow why setting up same
stream as front for hp dac, when in redirected mode).

By the way, I can think of at least one use case where switching hp
mode while playing could be useful/desirable: it might not be
extremely frequent, but it might happen that somebody ask you to set a
lower volume or to make no 'noise' at all, for a number of reasons,
and one might choose to plug a headset in his/her case front audio
panel, switch to redirected mode and turn off external speakers. With
actual implementation, such would require to stop the playback
completely (so that via_playback_multi_pcm_close() is called and
spec->num_active_streams is decremented), to change mode, then to
restart that playback: this could be annoying. Perhaps, such a
scenario could be taken into account.

>
> Takashi
>

Regards,

Alex

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Major reworks on patch_via.c (TESTERS WANTED)
  2011-07-06  0:58       ` alex dot baldacchino dot alsasub at gmail dot com
@ 2011-07-15  6:03         ` Takashi Iwai
  0 siblings, 0 replies; 19+ messages in thread
From: Takashi Iwai @ 2011-07-15  6:03 UTC (permalink / raw)
  To: alex dot baldacchino dot alsasub at gmail dot com
  Cc: Raymond Yau, phoenix.diablo, alsa-devel, haraldwelte, lydiawang

At Wed, 6 Jul 2011 02:58:09 +0200,
alex dot baldacchino dot alsasub at gmail dot com wrote:
> 
> 2011/7/5 Takashi Iwai <tiwai@suse.de>:
> > At Mon, 4 Jul 2011 21:37:46 +0200,
> > Jan Binder wrote:
> >>
> >> Am Mittwoch, 22. Juni 2011, 16:28:36 schrieb Takashi Iwai:
> >> > At Mon, 20 Jun 2011 17:06:51 +0200,
> >> >
> >> > Takashi Iwai wrote:
> >> > > Hi,
> >> > >
> >> > > as there have many problems reported for VIA codecs, I started looking
> >> > > at the driver code, and decided to rework on it.
> >> > > [snip]
> >> * Independent HP worked, when I could turn it on in alsamixer and correctly
> >> produced sound with aplay -Dhw:0,2,0 . I could not always reliably enable
> >> Independent HP in alsamixer, sometimes it would not change status ans aplay
> >> claimed that hw:0,2,0 was busy.
> >
> > This is intentional.  The switching is racy, so it can't be changed
> > safely when the multi-channel PCM is opened/used.
> >
> 
> Is it alway racy or only for those codecs sharing the same DAC between
> hp and side channel and/or requiring same stream as front to be set up
> for hp nid as well (e.g. not being connected to the front dac in any
> manner, if there is any such a via codec)?

Right, it's because of shared DAC.  If an individual DAC is available,
the driver won't block.

> In old implementation via_independent_hp_put() explicitly cleaned up
> any ongoing stream for hp dac and updated side mute status; in my case
> (vt2020) I didn't noticed errors or problems turning independent mode
> on/off several times while playing - I might have been just lucky and
> never met races, or just my codec isn't one of the above cases
> (indeed, there's no dac shared by hp and side, and my hp pin can be
> connected directly to front dac and gets also input by the stereo
> mixer being connected to front dac; actually, I haven't been able to
> find any info about via codecs with hp pin not being connected to
> front dac one way or another, so I don't follow why setting up same
> stream as front for hp dac, when in redirected mode).
> 
> By the way, I can think of at least one use case where switching hp
> mode while playing could be useful/desirable: it might not be
> extremely frequent, but it might happen that somebody ask you to set a
> lower volume or to make no 'noise' at all, for a number of reasons,
> and one might choose to plug a headset in his/her case front audio
> panel, switch to redirected mode and turn off external speakers. With
> actual implementation, such would require to stop the playback
> completely (so that via_playback_multi_pcm_close() is called and
> spec->num_active_streams is decremented), to change mode, then to
> restart that playback: this could be annoying. Perhaps, such a
> scenario could be taken into account.

Yes, the dynamic DAC stream change is also in my TODO list.
I haven't implemented it yet because it needs some testing with real
machines.  But, judging from your experiences, it seems OK to do that.

Maybe I'll try to hack in the next week, but feel free to add by
yourself before me (and send a patch).


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2011-07-15  6:03 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-20 15:06 Major reworks on patch_via.c (TESTERS WANTED) Takashi Iwai
2011-06-20 15:16 ` Takashi Iwai
2011-06-21 10:01 ` David Henningsson
2011-06-21 11:01   ` Takashi Iwai
2011-06-21 11:38     ` David Henningsson
2011-06-21 12:28       ` Takashi Iwai
2011-06-22  8:02 ` Jan Binder
2011-06-22  8:52   ` Takashi Iwai
2011-06-22 14:28 ` Takashi Iwai
2011-07-02 16:00   ` alex dot baldacchino dot alsasub at gmail dot com
2011-07-04 12:55     ` Takashi Iwai
2011-07-04 14:02       ` Takashi Iwai
2011-07-06  0:55         ` alex dot baldacchino dot alsasub at gmail dot com
2011-07-06  0:49       ` alex dot baldacchino dot alsasub at gmail dot com
2011-07-04 19:37   ` Jan Binder
2011-07-05  5:25     ` Takashi Iwai
2011-07-05  9:20       ` Raymond Yau
2011-07-06  0:58       ` alex dot baldacchino dot alsasub at gmail dot com
2011-07-15  6:03         ` Takashi Iwai

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.