"test" models in Intel HDA (and probably some other drivers)

"test" models in Intel HDA (and probably some other drivers)

[Rimas Kudelis]

Hello,

This message is about Intel HDA driver, but it may apply to other
drivers too.

Currently, a few codecs for HDA (ALC880 and ALC260, in particular) have
model configurations, named "test", that enable the user to use (almost)
any possible control widget in their mixer. This is very useful for
people with new and untested laptops, for example, that are sometimes
left muted or hardly controllable when the driver is loaded with a
different "model" argument.

The problem I see here is that those "test" models are only available as
a debug feature, which is compiled into the driver only when 
CONFIG_SND_DEBUG is defined. I think it would be much more useful to
always enable them. On one hand, this wouldn't get in anybody's way, if
you don't want it (i.e. you would simply never autodetect this model),
while on the other hand, you could just as easily make this model the
default for laptops (everything is up to your policy). And in case you
wouldn't want to clutter the mixer interface by default, this "test"
model would still silently be available for people like me, having
absolute silence with all the other configs. This is what is currently
happening with many Acer laptop users around the world.

Jonathan Woithe said he supports my idea. Takashi, what's your opinion
about it? Would you commit a patch fixing this problem to the CVS?

best regards,

Rimas Kudelis


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Takashi Iwai]

At Wed, 15 Feb 2006 09:39:11 +0200,
Rimas Kudelis wrote:
> 
> Hello,
> 
> This message is about Intel HDA driver, but it may apply to other
> drivers too.
> 
> Currently, a few codecs for HDA (ALC880 and ALC260, in particular) have
> model configurations, named "test", that enable the user to use (almost)
> any possible control widget in their mixer. This is very useful for
> people with new and untested laptops, for example, that are sometimes
> left muted or hardly controllable when the driver is loaded with a
> different "model" argument.
> 
> The problem I see here is that those "test" models are only available as
> a debug feature, which is compiled into the driver only when 
> CONFIG_SND_DEBUG is defined. I think it would be much more useful to
> always enable them. On one hand, this wouldn't get in anybody's way, if
> you don't want it (i.e. you would simply never autodetect this model),
> while on the other hand, you could just as easily make this model the
> default for laptops (everything is up to your policy). And in case you
> wouldn't want to clutter the mixer interface by default, this "test"
> model would still silently be available for people like me, having
> absolute silence with all the other configs. This is what is currently
> happening with many Acer laptop users around the world.
> 
> Jonathan Woithe said he supports my idea. Takashi, what's your opinion
> about it? Would you commit a patch fixing this problem to the CVS?

The test model exists clearly for the debugging purpose.  If only this
model can bring your device sounds, it means that you need debug
anyway.  In other words, the test model is not a solution but a method
to find a solution.

So, basically I disagree with changing it.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Rimas Kudelis]

Hi again,

>> The problem I see here is that those "test" models are only available as
>> a debug feature, which is compiled into the driver only when 
>> CONFIG_SND_DEBUG is defined. I think it would be much more useful to
>> always enable them. On one hand, this wouldn't get in anybody's way, if
>> you don't want it (i.e. you would simply never autodetect this model),
>> while on the other hand, you could just as easily make this model the
>> default for laptops (everything is up to your policy). And in case you
>> wouldn't want to clutter the mixer interface by default, this "test"
>> model would still silently be available for people like me, having
>> absolute silence with all the other configs. This is what is currently
>> happening with many Acer laptop users around the world.
>>
>> Jonathan Woithe said he supports my idea. Takashi, what's your opinion
>> about it? Would you commit a patch fixing this problem to the CVS?
>>     
>
> The test model exists clearly for the debugging purpose.  If only this
> model can bring your device sounds, it means that you need debug
> anyway.  In other words, the test model is not a solution but a method
> to find a solution.
>   

That's right, but there's a problem - you cannot find all solutions
yourself in this case. You need more people for that. IMHO, the more
people will have access to the method to find a solution, the more
solutions you'll get. Isn't that a right thing? Especially when, as I
said, the presence and availability of the "test" model wouldn't really
get in anyones way. It would not even clutter kernel logs.

OTOH, what is the default model now? HP? Fujitsu? Their subset? IMHO, a
reasonable superset should be the default for unknown models, not the
other way round. And "reasonable" means "based on many different brands
and models" in this case. Just "HP, IBM and Fujitsu" is not enough, as
you can see.

Don't forget that there are many people around who aren't Linux geeks,
and they don't know how to (or simply are afraid/don't want to) compile
kernel drivers. If we want more Linux on desktops, we should make sure
Linux is friendly enough for people like them.
> So, basically I disagree with changing it.
>   

Please consider it once more... It *won't* get in anyones way.

regards,
Rimas


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Takashi Iwai]

At Wed, 15 Feb 2006 14:27:38 +0200,
Rimas Kudelis wrote:
> 
> Hi again,
> 
> >> The problem I see here is that those "test" models are only available as
> >> a debug feature, which is compiled into the driver only when 
> >> CONFIG_SND_DEBUG is defined. I think it would be much more useful to
> >> always enable them. On one hand, this wouldn't get in anybody's way, if
> >> you don't want it (i.e. you would simply never autodetect this model),
> >> while on the other hand, you could just as easily make this model the
> >> default for laptops (everything is up to your policy). And in case you
> >> wouldn't want to clutter the mixer interface by default, this "test"
> >> model would still silently be available for people like me, having
> >> absolute silence with all the other configs. This is what is currently
> >> happening with many Acer laptop users around the world.
> >>
> >> Jonathan Woithe said he supports my idea. Takashi, what's your opinion
> >> about it? Would you commit a patch fixing this problem to the CVS?
> >>     
> >
> > The test model exists clearly for the debugging purpose.  If only this
> > model can bring your device sounds, it means that you need debug
> > anyway.  In other words, the test model is not a solution but a method
> > to find a solution.
> >   
> 
> That's right, but there's a problem - you cannot find all solutions
> yourself in this case. You need more people for that. IMHO, the more
> people will have access to the method to find a solution, the more
> solutions you'll get. Isn't that a right thing?

Only if more people use the _right_ method for finding a solution.

The first thing you need to debug is to use the latest ALSA version.
That is, if you cannot compile drivers, there is no way to debug
further in the current situation -- even if you can use test model.

>  Especially when, as I
> said, the presence and availability of the "test" model wouldn't really
> get in anyones way. It would not even clutter kernel logs.

Again, the test model is NOT provided for anyone's daily use.  It's
specially for someone who wants to debug the driver for his/her
device.

> OTOH, what is the default model now? HP? Fujitsu? Their subset?

Parsed from BIOS setting.

>  IMHO, a
> reasonable superset should be the default for unknown models, not the
> other way round. And "reasonable" means "based on many different brands
> and models" in this case. Just "HP, IBM and Fujitsu" is not enough, as
> you can see.

It's not.

> Don't forget that there are many people around who aren't Linux geeks,
> and they don't know how to (or simply are afraid/don't want to) compile
> kernel drivers.

CONFIG_SND_DEBUG is not for geeks but can be safely used generally.
In fact, SUSE kernels have always CONFIG_SND_DEBUG=y.

>  If we want more Linux on desktops, we should make sure
> Linux is friendly enough for people like them.

It's a different topic, IMO.  Compiling the drivers is mandatory for
debugging the device support right (for the time being).  So, it's not
the matter of friendlyness.

Sorry, I see no reason to change test model for anyone's use.  As I
mentioned, it alone won't help us better debugging.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Lee Revell]

On Wed, 2006-02-15 at 09:39 +0200, Rimas Kudelis wrote:
> And in case you
> wouldn't want to clutter the mixer interface by default, this "test"
> model would still silently be available for people like me, having
> absolute silence with all the other configs. This is what is currently
> happening with many Acer laptop users around the world. 

Please provide the bug ID# of a case where a user could only get sound
with the "test" model.

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Rimas Kudelis]

On Wed, Feb 15, 2006 at 02:14:01PM -0500, Lee Revell wrote:
> On Wed, 2006-02-15 at 09:39 +0200, Rimas Kudelis wrote:
> > And in case you
> > wouldn't want to clutter the mixer interface by default, this "test"
> > model would still silently be available for people like me, having
> > absolute silence with all the other configs. This is what is currently
> > happening with many Acer laptop users around the world. 
> 
> Please provide the bug ID# of a case where a user could only get sound
> with the "test" model.

It's a bug 1618, which affects me too..

Rimas



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Jonathan Woithe]

Rimas wrote:
> > The problem I see here is that those "test" models are only available as
> > a debug feature, which is compiled into the driver only when 
> > CONFIG_SND_DEBUG is defined. I think it would be much more useful to
> > always enable them. ...
> > 
> > Jonathan Woithe said he supports my idea. Takashi, what's your opinion
> > about it? Would you commit a patch fixing this problem to the CVS?

Well, what I said was that I could understand and be happy if the
maintainers wanted to make this change but I wouldn't do it myself - 
there was obviously a reason behind the decision to have things the way
they are and I wasn't fully aware of the issues.

Takashi wrote:
> The test model exists clearly for the debugging purpose.  If only this
> model can bring your device sounds, it means that you need debug
> anyway.  In other words, the test model is not a solution but a method
> to find a solution.

I'm actually not personally fussed either way.  I understand Takashi's
reason for keeping things as they are, but at the same time I can see how
having the test models "in by default" would broaden the potential test base
for these codecs.  If the test models were always available users could
submit useful information to ALSA for their laptop without having to
recompile or patch ALSA - and many people with these laptops have no idea
how to recompile a kernel, nor do they want to.  If the test model was
always available we could simply get them to load that model (which is much
easier than getting source, compiling, installing etc), play with the mixer
and report the findings.  This would be far more useful to ALSA than what
we'd get from these people now (something limited to the likes of "sound
doesn't work").

It is true that the test model is *not* a solution and is rather a tool, as
Takashi said.  One danger of having it "always in" is that some users would
treat it as the solution and we wouldn't get bug reports.

Rimas said:
> That's right, but there's a problem - you cannot find all solutions
> yourself in this case. You need more people for that. IMHO, the more
> people will have access to the method to find a solution, the more
> solutions you'll get. Isn't that a right thing? ...
> :
> Don't forget that there are many people around who aren't Linux geeks,
> and they don't know how to (or simply are afraid/don't want to) compile
> kernel drivers. If we want more Linux on desktops, we should make sure
> Linux is friendly enough for people like them.

This is pretty much along the lines of what I said above.  I guess I can see
both sides to the issue, and there's no real "killer argument" for either
side.

Takashi wrote:
> > So, basically I disagree with changing it.

On balance, if it were up to me I would probably err on the side of always
including the test driver at this stage, for no other reason than to make it
easier for more people to contribute useful information to ALSA.  Down the
track, when the number of untested hardware configurations has decreased
somewhat (resulting in most laptops working out the box under Linux), the
"testing" drivers might well revert to "debug only" status.  However, at the
end of the day Takashi is the maintainer of this driver and I'm happy to go
with whatever he considers is best for the future of ALSA.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642

Re: "test" models in Intel HDA (and probably some other drivers)

[Jonathan Woithe]

Takashi wrote:
> The first thing you need to debug is to use the latest ALSA version.
> That is, if you cannot compile drivers, there is no way to debug
> further in the current situation -- even if you can use test model.

This is true of course if there's a lowlevel issue - a problem talking to
the codec and getting it to generate analog output.  In this case I agree
completely with the above comments.

However, in fairness there are a large number of laptops out there utilising
the HDA hardware with the realtek codecs.  In these cases the basic codec
functionality is mostly working fine and has been ever since I started
playing with ALSA on my S7020 (around 1.0.9 or there abouts, from memory). 
The *only* problem on such laptops is the issue of which chip pins the
laptop manufacturers have connected to which jacks/speakers etc.  In these
situations you do not necessarily need the latest CVS (unless of course that
particular model has been recently added) - all you need is a mixer with all
the pin controls enabled so one can discover what controls what.

To consider the situation I'm most familiar with, if you purchase a laptop
today using the ALC260 codec chip, the intel-hda driver will basically work
- the DAC will produce audio quite nicely.  The issue will be one of ensuring
that ALSA's idea of the pin connections reflects reality for that laptop;
if it doesn't ALSA may not present controls which relate to pins in use on
that laptop (resulting in "no sound") or controls which are presented might
not control what ALSA thinks they control.  It is this situation where having
access to the test models would be helpful for users and where the ability
to compile is not necessarily required IMHO.

Lee wrote:
> Please provide the bug ID# of a case where a user could only get sound
> with the "test" model.

I didn't file a bug at the time since I ended up diving in and providing a
patch.  However, the situation I had with the Fujitsu S7020 is one where the
test model, had it existed at the time (Aug/Sept 2005), would have allowed
me to get sound out of all the jacks and the internal speaker, and work out
the routing required without having to resort to hacking mixer controls to
do the tests.  The default HDA model at the time could only manage the
internal speaker (and labelled it "headphones").

The situation being considered is one where the lowlevel hardware is
operating fine and the only problem is the analog routing chosen by the
respective laptop makers.

Of course, whether the presence of the test model in the non-debug
configuration would translate to more bug reports in reality I don't know. 
I guess evidence thus far suggests it wouldn't.

Anyway, I've said enough, the decision has been made and I respect that.

Regards
  jonathan


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642