Discrepancies - alsasound script versus alsaconf

[aus9]

Jason W,

In the same of spirit of sharing information,

I too wish to report that I can't use alsaconf but am not complaining either.

I did however expand the wiki and may have "forgotten" to mention alsaconf

Sorry if this is hijack but I can't write a wiki unless I can show snapshots.....showing my level of expertise or lack thereof...heh heh

the onboard sound device shows in the wiki
http://wiki.tinycorelinux.com/Setting+up+Sound

but more info if needed is

Code: [Select]

lspci -vv

00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 01)
    Subsystem: Elitegroup Computer Systems Device 2633
    Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 32 bytes
    Interrupt: pin A routed to IRQ 41
    Region 0: Memory at f9ffc000 (64-bit, non-prefetchable) [size=16K]
    Capabilities: <access denied>
    Kernel driver in use: HDA Intel


[Jason W]

Hi aus9,
Is it alsaconf that you cannot use, or alsasound?

Also, could you post the output of:

lspci -k | grep "Kernel modules" | grep "snd"


Thanks

[SamK]

[...]
I have a few ideas to fine tune the ISA setup to where it will not load unneeded sound drivers, at least after the first run of the script.  Perhaps the first use of alsasound can echo the correct driver to a temp file, and then the contents of that temp file if it exists can be read so that only that module is loaded from then on instead of modprobing all the listed ISA sound modules.  The temp file can then be placed in a backup so use of alsasound on subsequent boots would only load the needed driver. 
[...]

If this idea is implemented it will be helpful if the temporary configuration file can be stored and restored using either:

• a user specified location

OR

• the /opt directory

Such an outcome will cater for those circumstances where persistent storage is used and backup is not conducted via filetool.sh.
     

[Jason W]

Samk-   you are right, I will move file to /opt.     But I will keep it simple rather than user specified to save folks having to either pass another argument or edit the script.

[Jason W]

It is done.  /opt/.alsadriver is the file where ISA kernel modules can be placed.

The command "  echo "snd-sb16" > /opt/.alsadriver   ", or adding snd-sb16 to that file with a text editor will cause /usr/local/etc/init.d/alsasound  to not probe for other cards but insert that module instead, provided that ISA hardware has been detected.  Otherwise the module will not be loaded if no ISA devices are detected. 

This does not affect it's dealing with PCI cards, and there can be both ISA and PCI cards in the system.

[aus9]

Jason W

hmm now on 3.2....

sudo alsaconf now works...not sure what has changed from when I expanded wiki.

[Jason W]

Hey,

Does alsasound work? 

[curaga]

It's been a while since I last used ISA sound. IIRC OSS 4 dropped support for some ISA sound cards compared to 3.

On my ISA cards I don't remember ever having just-working sound after OSS3. Alsa always required manual selection of the card in alsaconf, OSS4 didn't have support for the card. [this was before the current changes, if some ISA cards can now be autodetected via the alsasound script, great!]

On my PCI cards I generally have sound without running any script on both sound systems, it's just the general volumes-down-with-alsa -> put them up -> put a restore-volumes call to bootlocal.sh.

[aus9]

Jason W


 on 3.2 both alsasound and alsaconf work

I have never had any issues with alsasound but on 3.1 alsaconf fails.

I never bothered to keep 3.1 to find out why as I use xfburn to blank the rewriteable to update to 3.2

I will have to do some thinking....eek.....on what to do with the wiki now alsaconf works for me

regards

[Jason W]

Great.

One last detail.  When /opt/.alsadriver exists, I will let the module specified in it be modprobed without depending on an ISA card first being detected, to give user control in the event an existing ISA card is not detected by the script first.  Automatic modprobing of known ISA modules will of course remain contingent on hardware first being detected and the lack of a successful modprobe/setup of an /opt/.alsadriver entry.  If there is one or more entry in /opt/.alsadriver, and an ISA sound card is detected in the system, and it dos not result in the card being activated, the script will then resort to the automatic modprobing.  That should be the last changes unless bugs are found.

[Jason W]

One more change.  If you need to use alsaconf to set up your card whether be one not detected by the alsasound script or if you have two soundcards or whatever, information is saved in /opt/alsa so that the next time you run /usr/local/etc/init.d/alsasound it will use the info acquired by alsaconf instead of looking for a card or inserting modules.  This way if alsasound by itself uses a different card as the primary one than you want to and you need to use alsaconf to set a different one as primary, then the next time you stop and restart alsasound it will still use the your desired card as the primary one that you chose in alsaconf.   Probably an intended upstream behavior that got left out when making alsasound more standalone.  And using the result of alsaconf this way should mean a quicker setup of sound with alsasound as it will not have to look for anything.

To reboot and retain the card preferences set in alsaconf without having to run it again upon boot, back up these files:

opt/alsa
etc/modprobe.conf

and for volume settings:

etc/asound.state

The /opt/.alsadriver file is now also in /opt/alsa as /opt/alsa/.alsadriver.

[aus9]

hi

thats really great.

thanks for the backup info as well