Getting alsa actual card driver to show in output - one method, in branches about inxi HOT 5 OPEN

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.

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.

[deleted comment]

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

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.