Getting alsa actual card driver to show in output - one method, in branches

[GoogleCodeExporter]

What steps will reproduce the problem?
1. lscpi -nn gives sound card output
2. /proc/asound/cards is present

What is the expected output? What do you see instead?
The output is as expected, the problem is that there doesn't appear to be 
any way I can see to link the driver output of /proc/asound/cards to the 
sound card data from lscpi -nn.

I have a version in branches/one that shows this difference, for some 
sound cards the output for both is similar, but for others, it's totally 
unrelated, no regex of any type could link the data for the card 
from /proc/asound/cards and the data from lspci -nn

There may be some other place the data can be linked, but I a giving up 
now on this problem, though it would be nice to see inxi show the alsa 
driver for each sound card.

Currently this only works if lspci does not give output, I discovered 
this possibility by chance on an older machine where I think I turned the 
sound card off in the mobo, but I think alsa cards still remembers it, 
thus the difference.

inxi -! 11 will upgrade to branches/one inxi if you want to see for 
yourself, then run: inxi -A
And compare it to the inxi -A output of the main trunk inxi (the branch 
one is set to not show lspci -nn output thus imitating the condition that 
will make /proc/asound/cards get used instead.

This is an interesting problem, and I think someone else with a different 
perspective can maybe figure it out, I can't.
Please use labels and text to provide additional information.

Original issue reported on code.google.com by inxi-...@techpatterns.com on 14 Nov 2008 at 5:25

[GoogleCodeExporter]

Please note, I did a hacked workaround that will generally work for any system 
that 
has only one audio card or mobo audio device, but it will fail/provide buggy 
output 
for any other case, including webcams, which are seen by /proc/asound/cards as 
an 
audio device as well.

I can find no way to filter out by regex rules webcams, nor can I find any 
consistent way to match the devices listed by cat /proc/asound/cards and the 
output 
from lspci -nn <audio card data>.

I've found and fixed the modem case, so that's filtered out.

Since I'd rather see slightly wrong audio driver  output than none, I am 
leaving 
the hacked method in for now, but hopefully at some point someone can come up 
with 
something a bit more robust and elegant, and less prone to error.

Original comment by inxi-...@techpatterns.com on 19 Nov 2008 at 10:35

[GoogleCodeExporter]

This issue is largely resolved, but I'm going to leave this up because for 
single 
card instances where lspci -v provides no driver output (ie,  most Etch,  older 
kernels) inxi still relies on something of a hack, which isn't totally reliable.

But for any newer system that gets a card driver / and maybe driver version 
from 
lspci -v, the issue is totally resolved.

See the get_audio_data() function to get the method, and the hack for single 
card 
failed detection of driver.

So this one is 'Started', but since this issues page has no selection for: 
'Almost 
done but still lacking in elegance' I'm going to leave the issue up, for a 
future 
time where someone might find a better way to do it.

Failure cases still occur, and should be fixable, where the user has for 
example a 
usb videocam and a system sound card, then the driver will show for both if 
they 
don't have a lspci -v driver output, but that's a fringe case now, but it is 
real, 
I've seen it.

The filter for 'usb' is not working, I don't know why. So that's a real 
lingering 
fringe part of this issue.

Original comment by inxi-...@techpatterns.com on 24 Nov 2008 at 7:50

• Changed state: Started

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I know this is an ALSA issue and not pulseaudio per se

I know this is old but

lspci -k (appears) useful for my hardware

00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio 
Controller (rev 01) Subsystem: Elitegroup Computer Systems Device 2633
Kernel driver in use: snd_hda_intel

but for those with HDMI may not be as useful, from a forum I find

00:14.2 Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel 
HDA)
Kernel driver in use: snd_hda_intel

01:05.1 Audio device: Advanced Micro Devices [AMD] nee ATI RS780 HDMI Audio 
[Radeon HD 3000-3300 Series]
Kernel modules: snd-hda-intel

and it needed a new command to get codec

head -n 1 /proc/asound/card*/codec*

--> giving result

/proc/asound/card0/codec#0 <==
Codec: VIA VT1708S

/proc/asound/card1/codec#0 <==
Codec: ATI RS690/780 HDMI

In other words, if an user comes to forum or IRC and uses inxi for HDMI 
trouble shooting, inxi is not quite the tool to provide it

and

inxi -c20 -v5 for my hardware gives

Audio:     Card: Intel N10/ICH 7 Family High Definition Audio Controller 
driver: snd_hda_intel bus-ID: 00:1b.0
Sound: Advanced Linux Sound Architecture ver: 1.0.25

but does appear to display codec or that I am currently on pulseaudio

thanks for reading

comment was editted to fix up some grammar

Original comment by debsids...@gmail.com on 4 Sep 2012 at 5:47

[GoogleCodeExporter]

By the way, I think I never saw this last posting. DO NOT TACK ON AN UNRELATED 
ISSUE TO THIS THREAD.

That is not how you get issues resolved. Showing codecs has nothing to do with 
the alsa issue, nor does anything related to hdmi.

This is basically a new feature request, tacked onto a completed issue.

In general, if you want your issue reports to be ignored or missed, do exactly 
what this person did, fail to start a new issue for your actual issue.

Codecs are too specific at this point, it's just not in the realm of what I 
think inxi should show. 

I can't split this last comment out and start a new issue with it, so I just 
have to leave this as is. But the actual issue here was resolved years ago.

When filing an issue report, do not tack on one unrelated issue to another. I 
actually never even noticed this since that issue was already resolved, and 
there was no reason to even notice anything new added, so the result was, for 2 
years this went unnoticed.

I honestly do not see much to be gained by showing codec output to be honest, 
if things are that specific, just get the data from the user directly, like:

head -n 1 /proc/asound/card*/codec*
lspci -v

There has to be a limit to what inxi shows, and the closer it gets to software, 
the harder it is to maintain and debug, though I can certainly add these items 
to the inxi debug data collector just to get a basic working set of information 
from varied user systems.

Original comment by inxi-...@techpatterns.com on 28 Mar 2014 at 8:07