WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Discrepancies - alsasound script versus alsaconf  (Read 7634 times)

Offline SamK

  • Hero Member
  • *****
  • Posts: 713
Discrepancies - alsasound script versus alsaconf
« on: October 15, 2010, 09:20:50 AM »
I have a few venerable PC's which I am looking to press back into service conducting light duties with TC3x.  Currently they are performing really well, but one is having a problem with sound from an ISA "Creative ViBRA16X PnP" card.  Sound output fails when configured using
sudo /usr/local/etc/init.d/alsasound start
but works if configured using
sudo alsaconf

The card is found during boot-up, as shown by this extract from dmesg:
Quote
isapnp: Scanning for PnP cards...
pnp 01:01.00: increased option port range from 0x388-0x388 to 0x388-0x3f8
pnp 01:01.00: increased option port range from 0x388-0x388 to 0x388-0x3f8
 01:01: card 'Creative ViBRA16X PnP'
isapnp: 1 Plug & Play card detected total

No kernel module is loaded for it.
lsmod
Quote
Module                  Size  Used by    Not tainted
cifs                   161640  2
squashfs            14728 25
ramzswap           10240  1
loop                     8068 50
scsi_wait_scan         276  0
via_rhine              12704  0

Alsa is listed in OnBoot and after running
sudo /usr/local/etc/init.d/alsasound start
Quote
amixer: Mixer attach default error: No such file or directory
sound is not reproduced using
speaker-test --channels=2
however, additional kernel modules are loaded
lsmod
Quote
Module                           Size  Used by    Not tainted
snd_seq_dummy             648  0
snd_seq_oss              15364  0
snd_seq_midi_event      2624  1 snd_seq_oss
snd_seq                     26036  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device           2808  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss             24484  0
snd_pcm                    37628  1 snd_pcm_oss
snd_timer                  10564  2 snd_seq,snd_pcm
snd_page_alloc            4016  1 snd_pcm
snd_mixer_oss             8648  1 snd_pcm_oss
snd                           26200  7 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss
soundcore                  2640  1 snd

cifs                         161640  2
squashfs                  14728 37
ramzswap                 10240  1
loop                          8068 74
scsi_wait_scan              276  0
via_rhine                   12704  0

After running
sudo alsaconf
sound is reproduced using
speaker-test --channels=2
however, yet further kernel modules are loaded
lsmod
Quote
Module                  Size  Used by    Not tainted
snd_sb16                5144  0
snd_opl3_lib            4888  1 snd_sb16
snd_sb16_dsp            4696  1 snd_sb16
snd_sb16_csp            5932  1 snd_sb16
snd_sb_common           7184  3 snd_sb16,snd_sb16_dsp,snd_sb16_csp
snd_hwdep               3004  2 snd_opl3_lib,snd_sb16_csp
snd_mpu401_uart         2780  1 snd_sb16
snd_rawmidi            10004  1 snd_mpu401_uart

snd_seq_dummy            648  0
snd_seq_oss            15364  0
snd_seq_midi_event      2624  1 snd_seq_oss
snd_seq                26036  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device          2808  5 snd_opl3_lib,snd_rawmidi,snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            24484  0
snd_pcm                37628  3 snd_sb16,snd_sb16_dsp,snd_pcm_oss
snd_timer              10564  3 snd_opl3_lib,snd_seq,snd_pcm
snd_page_alloc          4016  1 snd_pcm
snd_mixer_oss           8648  1 snd_pcm_oss
snd                    26200 15 snd_sb16,snd_opl3_lib,snd_sb16_dsp,snd_sb16_csp,snd_sb_common,
snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_oss,snd_seq,
snd_seq_device,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss
soundcore            2640  1 snd  
 
cifs                  161640  2
squashfs               14728 37
ramzswap               10240  1
loop                    8068 74
scsi_wait_scan           276  0
via_rhine              12704  0

This is hindering a simple, automated set-up of sound at boot-up.  I suppose one could load each of the modules individually during boot-up but it does seem rather clumsy and inelegant.  As alsaconf is able to successfully conduct the set-up is it possible for the alsasound script to do likewise?
  

(Modified by Jason w to fit on page)
« Last Edit: October 15, 2010, 01:49:00 PM by Jason W »

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #1 on: October 15, 2010, 09:42:05 AM »
It has been a while since I dealt with ISA sound cards, but I have a few laying around including an sb16 that I can play with.  Does alsaconf find that card non-interactively?   I can't remember if it does.  If it does, then I can likely work a routine into the alsasound script for PnP ISA cards.

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #2 on: October 15, 2010, 10:13:00 AM »
Upon viewing alsaconf, it has various options that can be used, and perhaps one of those options can be used to probe only legacy PnP cards non-interactively.  That would be better than duplicating the functionality in alsasound that would slow things down for everyone. 

If there is not an option to probe for PnP ISA cards and either fail or succeed non-interactively I will see if I can add it in.   Folks with ISA cards then could just use the alsaconf command instead of alsasound, but will serve the same purpose.

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #3 on: October 15, 2010, 11:06:10 AM »
There is not an option to run alsaconf for PCI or ISA PnP cards without interaction, so I will aim for adding that as an option for those cases that need alsaconf. 

Or I may be able to add the lines to /usr/local/etc/init.d/alsasound to probe for PnP when no PCI card has been found, along with a "status" option so it will play well with the services tool in base.

Offline SamK

  • Hero Member
  • *****
  • Posts: 713
Re: Discrepancies - alsasound script versus alsaconf
« Reply #4 on: October 15, 2010, 11:10:45 AM »
Quote from: Jason W
It has been a while since I dealt with ISA sound cards...
Yeah me too, and I suspect for many others also.  I had to spend time "scratching my brain" to remember what to do.

Quote from: Jason W
Upon viewing alsaconf, it has various options that can be used, and perhaps one of those options can be used to probe only legacy PnP cards non-interactively.
[...]
If there is not an option to probe for PnP ISA cards and either fail or succeed non-interactively I will see if I can add it in.
I've had a look at the help options and cannot find one which is specifically for legacy PnP cards, or fails/succeeds in the way you describe.

Manually requesting a list of cards returns:
sudo alsaconf --listprobe
Code: [Select]
opl3sa2 cs4236 cs4232 cs4231 es18xx es1688 sb16 sb8
I don't know if this varies with different cards.

Manually probing the card returns:
sudo alsaconf --probe sb16
Code: [Select]
0 [S16            ]: SB16 - Sound Blaster 16
Probing the other candidates (from --listprobe) returns either failed or no card found.

I cannot see how it goes on to identify which modules to install.

Not much help, but here's hoping you fare better.
 
(Note: caught twice in cross-posting but thought I would offer it anyway.)
 

aus9

  • Guest
Re: Discrepancies - alsasound script versus alsaconf
« Reply #5 on: October 15, 2010, 06:28:02 PM »
hi

1) I would personally try out OSS first

2) from the alsa wiki ....alsa config text link

Quote
Module snd-sb16 and snd-sbawe
  -----------------------------

    Module for 16-bit SoundBlaster cards: SoundBlaster 16 (PnP),
                      SoundBlaster AWE 32 (PnP),
                      SoundBlaster AWE 64 PnP

    mic_agc    - Mic Auto-Gain-Control - 0 = disable, 1 = enable (default)
    csp        - ASP/CSP chip support - 0 = disable (default), 1 = enable
    isapnp    - ISA PnP detection - 0 = disable, 1 = enable (default)

    with isapnp=0, the following options are available:

    port    - port # for SB DSP 4.x chip (0x220,0x240,0x260)
    mpu_port    - port # for MPU-401 UART (0x300,0x330), -1 = disable
    awe_port    - base port # for EMU8000 synthesizer (0x620,0x640,0x660)
                   (snd-sbawe module only)
    irq        - IRQ # for SB DSP 4.x chip (5,7,9,10)
    dma8    - 8-bit DMA # for SB DSP 4.x chip (0,1,3)
    dma16    - 16-bit DMA # for SB DSP 4.x chip (5,6,7)
    
    This module supports multiple cards, autoprobe and ISA PnP.

    Note: To use Vibra16X cards in 16-bit half duplex mode, you must
          disable 16bit DMA with dma16 = -1 module parameter.
          Also, all Sound Blaster 16 type cards can operate in 16-bit
          half duplex mode through 8-bit DMA channel by disabling their
          16-bit DMA channel.
    
    The power-management is supported.

3) before attempting any alsa....if you prefer alsa....post the output of

Code: [Select]
cat /proc/interrupts
4) I would then guess you can use the module loading "way" in the bootlocal something like (as per the wiki...alsasound not showing here so read that bit of the wiki if interested)

/sbin/modprobe snd_sb16   isapnp=1

if that fails then set the options manually by

/sbin/modprobe sb16 isapnp=0 IRQ=10

where I am guessing irq results for your cat command

5) I have no memory of isa cards but seem to recall that the IRQ can be tricky

some like to be irq=3 or 4 etc....but we need to know what your current ones are and if shared

« Last Edit: October 15, 2010, 06:37:34 PM by aus9 »

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #6 on: October 15, 2010, 11:31:44 PM »
After wading through the depths of alsaconf, and also reading on the experiences of others how any attempt at automation by using the "yes '' | alsaconf" command as well as other means is usually not successful, I saw modifying alsaconf was not a good idea as a myriad of things could go wrong.  But there was an apparently simple solution.

I added a routine to /usr/local/etc/init.d/alsasound script to accommodate ISA PnP cards when no PCI card is found.  Starts and stops flawlessly for me with my snd-es18xx card.   I only have one card so testing and feedback is appreciated.  This change in the script should not affect those with PCI cards in either performance or results.  I can add other cards to support, let me know if your module is not included in the list near the beginning of the script.

Of course, those with legacy non-PnP cards, or multiple sound cards need to use alsaconf or to deal with it manually as there is no way or enough demand to try to safely script that.  
« Last Edit: October 15, 2010, 11:40:50 PM by Jason W »

Offline SamK

  • Hero Member
  • *****
  • Posts: 713
Re: Discrepancies - alsasound script versus alsaconf
« Reply #7 on: October 16, 2010, 05:22:38 AM »
I added a routine to /usr/local/etc/init.d/alsasound script to accommodate ISA PnP cards when no PCI card is found.  Starts and stops flawlessly for me with my snd-es18xx card.   I only have one card so testing and feedback is appreciated.  
Reporting success.  This also works flawlessly here.  Running from /opt/bootlocal.sh:
/usr/local/etc/init.d/alsasound start
A fully operational result is achieved without user intervention.

One minor suggestion, a message is briefly displayed during the boot process:
Extract from dmesg
Quote
sb16 01:01.00: activated
isa sb8.0: please specify irq
This seems superfluous, particularly the reference to sb8 when sb16 has been activated.

I will have a search for any other ISA PnP audio cards and report the results of testing if/as I find any.

Thanks for your help.


@aus9
Thanks for your suggestions.  Just to clarify things a little further...

I was not reporting that a working set-up could not be achieved, rather, that the two configuration methods mentioned in the ALSA info file produced different results.
  • The alsasound script produced a partial, non working, set up without user intervention.
  • The alsaconf method produced a complete, working, set up but required user intervention.
The objective was to obtain a fully operational sound system via an automated process conducted at boot-up.

Before making the original post I had tried and failed with OSS.  This again seems to be attributable to a partial automated set up.
lsmod
Quote
Module                  Size  Used by    Not tainted
oss_usb                90348  0
osscore               542900  1 oss_usb

cifs                  161640  2
squashfs               14728 32
ramzswap               10240  1
loop                    8068 64
scsi_wait_scan           276  0
via_rhine              12704  0

The difference between ALSA and OSS in this instance is that using ALSA I could easily and incrementally demonstrate the diagnostic steps which resulted in a working outcome.

For the particular machine that started this thread there is no preference for either ALSA or OSS.  In view of an automated configuration for ISA PnP cards now being available for ALSA, a similar ability for OSS is, in my view, also desirable.  Perhaps Jason or Curaga (as maintainer of OSS) might offer an opinion.
   

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #8 on: October 16, 2010, 08:00:37 AM »
I am first using the "shotgun" approach in alsasound, which does result in unneeded modules being loaded, though that is likely harmless in all cases.

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.  I will play with it this afternoon.  Dmesg prints "$(drivername) (some numbers): activated" upon loading the correct driver, so testing for a fruitful modprobe should be simple.

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: Discrepancies - alsasound script versus alsaconf
« Reply #9 on: October 16, 2010, 09:17:37 AM »
I was not reporting that a working set-up could not be achieved, rather, that the two configuration methods mentioned in the ALSA info file produced different results.
  • The alsasound script produced a partial, non working, set up without user intervention.
  • The alsaconf method produced a complete, working, set up but required user intervention.

I have observed a similar behaviour with a PCI soundcard, with the difference that alsasound script produced a partially working set up.
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #10 on: October 16, 2010, 09:36:38 AM »
tinypoodle-       Do you remember which PCI card and driver did not get fully set up with alsasound?

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: Discrepancies - alsasound script versus alsaconf
« Reply #11 on: October 16, 2010, 10:01:47 AM »
tinypoodle-       Do you remember which PCI card and driver did not get fully set up with alsasound?

If I would have remembered for 100% sure, I would have stated the model, and what were the exact differences in outcome.
Most likely it was this card:

lspci:
Code: [Select]
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)aplay -l:
Code: [Select]
card 0: Intel [HDA Intel], device 0: ALC888 Analog [ALC888 Analog]alsamixer:
Code: [Select]
Card: HDA Intel; Chip: Realtek ALC888
It appears at this moment to be set up without alsasound only, IIRC there would be several additional modules loaded with alsaconf, e.g. some containing *seq* in name. As I don't have any issues with it at this moment, not keen to fiddle with it  ;)
« Last Edit: October 16, 2010, 10:13:27 AM by tinypoodle »
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: Discrepancies - alsasound script versus alsaconf
« Reply #12 on: October 16, 2010, 10:49:00 AM »
BTW, by reporting what I did about upper card, by no means did i mean to complain or wish for any change of the status quo regarding specific card. To the opposite, I would find it an advantage if there is a choice between a less complete setup which can fulfill some needs while using less resources and a complete all purposes setup. Also I'd prefer more options of manual control by users over automated procedures which are reducing control of users. Such is - at least as I have come to understand - fully compliant with the basic philosophy of TC.

But then of course there is a big difference between what the OP reports as a partial, non working, set up and what I report as partially working set up.
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Discrepancies - alsasound script versus alsaconf
« Reply #13 on: October 16, 2010, 12:54:48 PM »
I did not take your comment as complaining, but if partially working meant no usable sound from a common PCI card (not counting having to adjust the volume) but the hardware was partially setup, then that is worthy of attention to me since alsasound is heavily trimmed of non-needed legacy and other-distro stuff from the upstream original, I could have left out a simple detail or two.  The goal with the changes to alsasound is adding user control, more reliability as standalone with less dependence on alsaconf for a basic functioning setup.  While working with 95% of cards for 95% of folks, as there will always be exotic or finicky cards that will need alsaconf or manual intervention, testing for those cases won't be attempted.

Alsaconf is pretty much deprecated in most distros (last changes seem to be from 2002), as it mainly deals with probing for sound cards and setting up legacy ISA ones, which for old ISA non-PnP stuff it is still useful.  That and setting up two sound cards, but of course, that can just as easily be done by editing /etc/modprobe.conf.   Alsasound is called from alsaconf to actually set up the sound once the sound card config is done, and since that config is now pretty much taken care of by inserting the kernel module, alsaconf should not really be needed for PCI and ISA PnP. 

Adding the option for an ISA driver to be specified will prevent the need for probing for other cards, reducing resources of loaded modules and also adding user control. 


Offline tinypoodle

  • Hero Member
  • *****
  • Posts: 3857
Re: Discrepancies - alsasound script versus alsaconf
« Reply #14 on: October 16, 2010, 06:14:14 PM »
Jason W,
thank you for elaborating, I think the spirit is clear and I could not disagree.

To further clarify about the card I had reported, my uptime on this box is ~6d and I didn't come to a point yet where I saw a need to run alsaconf.
(I saved the current output of lsmod for further reference, should need ever arise)
"Software gets slower faster than hardware gets faster." Niklaus Wirth - A Plea for Lean Software (1995)