SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I don't have a SB600 chip handy, nor familiar with hda-analyzer, but the Intel chipset on a laptop running Slackware14-RC3 uses the same hda-intel module with no issues. Perhaps its a hardware mapping issue with HDMI? Mic jack autosensing? Conflict with internal mic? Did you look at 'alsamixer' F4: Capture In F3: Playback is the Mic Jack Mode "Mic In" if you are trying to record from a microphone? How about creating/editing /etc/modprobe.d/snd-hda-intel.conf with
options snd-hda-intel model=auto
(See also /usr/src/linux/Documentation/sound/alsa/HD-Audio-Models.txt) This should get rid of alsaconf "no supported pci or PCI card found" so that alsaconf can set up reasonable defualts....maybe...
From Mr. Obvious, as root, once you set alsamixzer, you will need to run 'alsactl store' to avoid "nobbling." One good way to test is to use Audacity. It will see what inputs are available. Keep monkeying around until something records.
Thanks for the reply. Yes we did discuss this before, and still no luck. I have read /usr/src/linux/Documentation/sound/alsa/HD-Audio-Models.txt, and /usr/src/linux/Documentation/sound/alsa/HD-Audio.txt. There's some suffering!
There's _no_ internal mic, and output is to 2 crappy little speakers and a headphone socket. No line-in/line-out, just a mic socket which shows under capture in alsamixer. No newbie errors.
The HDA Intel chip is a number of input, internal and output amps. The in and out volumes on many of them are variable, afaict to make use of built in capacitors (design your own filter). There is one alsa module, but it needs support for different incarnations of the chip (Realtek, Nvidia, Intel, Amd, IDT/Sigmatel, Via, Cirrus, Conexant, Creative, C-Media & Silicon Labs).
What seems to matter is internal mappings and volumes and the way the device is brought up. This _never_ worked under Slackware64. I have sent alsa-info.sh outputs from each system
slamd (working) and slackware (no capture) https://skydrive.live.com/#cid=99361...4096FF2C07!208
Also up there are 2 pictures -
1. hda-analyzer showing one screen (my contentious pin 0x18) of the analyzer and
2. hda-graph with the internal graph of the chip output by the system.
I'd love to find what's different, fix it, and go away. But it's not that simple. Just listening to the sound, Slamd has a very well balanced and high quality capture, and what I get up in Slackware is rough and noisy by comparison.
I'd say look at the difference in kernel configs for the audio.
I did. I remade 3.0.4 from the working config. As they are both on the same box, I copied the respective /lib/modules subdirs and booted each kernel in the other distro. There are issues, (amd/ati VIDEO, Locales, and slamd is basically knackered beyond a console)
I did get a blind (working capture) 184.108.40.206 kernel going in my Slackware setup, logged inh and ran an arecord & aplay command blind. No capture, so I reckon the kernel is now eliminated.
Originally Posted by H_TeXMeX_H
You could try using 'mknod' to create a node with the same major and minor numbers ... but I think it may be a driver issue instead.
I did this, and arecord wouldn't run. Reviewing
* Kernels seem to be eliminated
* /etc/alsa & any config files I can find are copied from working to not working.
* I have tried about 5 times with the hda-analyzer script, but running alsactl or alsamixer buggers things completely.
EDIT: I also grabbed /proc/asound/card0/codec#0 from the working system, placed it into the dud one, and no joy.
Short of the m$ solution - uninstalling alsa and reinstalling
1. Slamd stuff
2. Slackware stuff
I'm clean out of ideas ( a rare occurence!). So I am defeated, until I get my next idea.
/goes off to try uninstalling & reinstalling. But this never works.
Last edited by business_kid; 08-27-2012 at 09:59 AM.
I caught one mistake - /etc/asound.state did not copy over, as asound.state has moved to /var/lib/alsa, and slackware has a symlink there in /etc :-(.
Copying in slamd's asound.state has given me capture (HURRAY!) but with 100% echo (BOO!), but through some weird channels where it is fed into the (non-existent)internal microphone amp, instead of coming through capture where it should. Some filter is skewed.
I have it in alsamixer on Capture, Digital, & pcm channels. Turning up digital, and killing capture seems best. I have no adjustment columns for: Mic; Mixer; Docking station. I have 3 Mic boost columns and 2of them work, but are not necessary. I also have an unwanted & unfitted internal Mic column.
I have asound.state.slamd - purr-fect capture in slamd
Also asound state.slack - no capture at all in slackware
and asound.echo in slackware after a reboot and alsactl commands. Echoes.
It eventually dawned on me that they were passing mono to stereo, and one side of the stereo had very little, and the problem is eased by killing volume one side of the stereo amps. But that's mono capture, which is crap, with an echo. What happens if I have a stereo signal?
At this point I have reinstalled the slackware alsa stuff from disk. I also threw up the latest alsa-info, (alsa-info.echo) and I'll compare them tomorrow
One thing I notice right away is that 'Capture Switch' is false in slackware ... so basically this means that it is not capturing because it is set to not capture.
Remember in alsamixer to press F4 for the capture settings, then press <Space> on 'Capture', and 'L R Capture' should appear in red, meaning that capturing is enabled. Without this, nothing is captured. This may be the problem.
Well, that explains a bit. Mind you, I had capture L&R in red. But I sorted it.
I went into slamd, THEN copied over the /etc/asound.state to slackware's /var/lib/asound.state. So when I booted slackware, I had the card set up via 'alsactl restore' from cold. That seemed to sort it. There's a minor echo, but I can live with that. It could even be in the room.
Alsa never has got past this stage, has it? And I've never got past spending unreal amounts of time sorting stupid little things.
Reluctantly, I'm pulling this back into the undecided comumn. :-((.
Well, at your suggestion, I went to turn off Mic boos, and found I had switched nothing, having copied /slamd/etc/asound.state to /var/lib/asound.state - while slackware is reading /var/lib/alsa/asound.state
2 reboots followed with the slamd asound.state in slackware, I have a firm echo. No echo at all in Slamd64 :-/. I had tweaked and fiddled to minimise it, and that was what I heard. Furthermore, I get the following errors from running 'alsactl restore' when run in a terminal
bash-4.1$ sudo alsactl restore
Found hardware: "HDA-Intel" "Analog Devices AD1981" "HDA:11d41981,103c30c2,00100200 HDA:11c11040,103c1378,00100200" "0x103c" "0x30c2"
Hardware is initialized using a generic method
alsactl: set_control:1267: failed to obtain info for control #5 (No such file or directory)
alsactl: set_control:1267: failed to obtain info for control #6 (No such file or directory)
5 & 6 are Mic boost & pcm playback respectively. This all indicates to me that it's basically ignoring stuff and making guesses at what to do and those guesses aren't very good (very good) :-/.