[E17] unusual sound problem on one particular machine

[vc]

Ok, the modules are loading. (they don't give feedback when successful, only if there's an error) Now, does sound work yet? I suspect not, but I'm prepared to be surprised.  

As root, run alsaconf from a terminal. Have it check for legacy cards, when asked, as the es1869 from that long ago probably is an ISA slot card. (Don't know if any were ever PCI slot) It may not be found even with the drivers installed, in which case you'll need to install the isapnptools package from Synaptic. It's been a lot of years since I've had a machine with an ISA slot card, so I'm having to dust some cobwebs remembering this stuff.

Yes - I understand.  I'm not holding too much hope at the moment for this particular project, though - if it's successful, then fine... otherwise, I retrieve my hard disk and memory from this unit and toss its empty carcass back into the scrap bin.

Still no sound, though.  I've ran alsaconf again, and once more directed it to try all possible interrupt and DMA configurations - it goes through the same motions as before, again seemingly without any error... until the very end, as it exits; that's when I notice a very brief flash of a message, reporting something about the sound device being in use by PID(something) and with an ominous taint of [FAIL] at the far right edge of the display screen.  It lasts for less than a fifth of a second only; far too quick to read in any detail - and when I attempt to scroll back up to read it, no trace of it remains.


<Modify>

I have now installed isapnptools 1.26-9pclos2007, via Synaptic, and am currently attempting to learn something of its use.

[Old-Polack]

Ok, the modules are loading. (they don't give feedback when successful, only if there's an error) Now, does sound work yet? I suspect not, but I'm prepared to be surprised.  

As root, run alsaconf from a terminal. Have it check for legacy cards, when asked, as the es1869 from that long ago probably is an ISA slot card. (Don't know if any were ever PCI slot) It may not be found even with the drivers installed, in which case you'll need to install the isapnptools package from Synaptic. It's been a lot of years since I've had a machine with an ISA slot card, so I'm having to dust some cobwebs remembering this stuff.

Yes - I understand.  I'm not holding too much hope at the moment for this particular project, though - if it's successful, then fine... otherwise, I retrieve my hard disk and memory from this unit and toss its empty carcass back into the scrap bin.

Still no sound, though.  I've ran alsaconf again, and once more directed it to try all possible interrupt and DMA configurations - it goes through the same motions as before, again seemingly without any error... until the very end, as it exits; that's when I notice a very brief flash of a message, reporting something about the sound device being in use by PID(something) and with an ominous taint of [FAIL] at the far right edge of the display screen.  It lasts for less than a fifth of a second only; far too quick to read in any detail - and when I attempt to scroll back up to read it, no trace of it remains.


<Modify>

I have now installed isapnptools 1.26-9pclos2007, via Synaptic, and am currently attempting to learn something of its use.

Again as root, from a terminal;

[root@localhost ~]# pnpdump > /etc/isapnp.conf             <Enter>

This will create a configuration file for all ISA cards it finds. One should be your sound card. Depending on the size of the output, either post the contents, or attach a copy of the file to your reply, so I can see what might be needed to set the card up properly. Once we get it working we can add a couple of lines to /etc/modprobe.conf so the card is found and configured with each boot.

[vc]

Again as root, from a terminal;

[root@localhost ~]# pnpdump > /etc/isapnp.conf             <Enter>

This will create a configuration file for all ISA cards it finds. One should be your sound card. Depending on the size of the output, either post the contents, or attach a copy of the file to your reply, so I can see what might be needed to set the card up properly. Once we get it working we can add a couple of lines to /etc/modprobe.conf so the card is found and configured with each boot.

Hmm.  I found an existing file; /etc/isapnp.gone - as both it and the new /etc/isapnp.conf file seem small, it may be as simple to attempt attaching same herewith?

At least one further thought causes me to wonder, though:  if 'legacy' non-PnP ISA sound devices require the use of isapnptools and then subsequent modification of etc/modprobe.conf in order to function at all, then how was the Slax 6.1.2 live boot able to deal with it successfully?  I realise that this 'device' is actually an integrated circuit that is soldered directly onto this laptop's mainboard, rather than being a separate soundcard; yet still, surely it must be a PnP device nevertheless?  For otherwise, its parameters would have to be set manually - which for a live boot seems rather unlikely.

[Old-Polack]

vc:

That didn't help much. Digging through my ancient SuSE 6.4 manual on ISA sound cards I get this for a command to load the module, complete with parameters. If this doesn't work, the sound card is so old it needs to be set by jumpers on the motherboard, if it's built in, or on the card itself if it's a plug in. I would reboot, to be sure the modules are unloaded at first, then load them with this command.

[root@localhost ~]# modprobe snd_es81xx io=0x220, irq=5, dma=1, dma16=5, mpu_io=0x330, midi=0x388            <Enter>

After which, try alsaconf again, to see if it now finds the card and sets it up properly.

[vc]

... I would reboot, to be sure the modules are unloaded at first, then load them with this command.

[root@localhost ~]# modprobe snd_es81xx io=0x220, irq=5, dma=1, dma16=5, mpu_io=0x330, midi=0x388            <Enter>

After which, try alsaconf again, to see if it now finds the card and sets it up properly.

Reboot; modprobe -r; dma=1,dma16=5 or dma1=1,dma2=5... alas; no success yet.  I have been swapping hard drives and comparing operating systems on this machine today, and now have the following to report:

1)  The Slax 6.1.2 live CD seems to make use of OSS for its default sound system.

2)  Slax has sound output only initially - after several minutes of operation, its sound system fails; mplayer/kplayer/vlc all lock up and refuse to either play anything or even exit properly (xkill is required), and YouTube crashes FireFox completely only a second or so after it begins playing.

3)  No sound was obtained from any other modern distro (although I haven't bothered with some of the older ones yet.).

4)  Windows 98SE has been installed successfully onto another hard drive - its soundsystem is functioning properly.

5)  Windows indicates the same IO and DMA port parameters; however, it also indicates one additional port address that does not seem to be mentioned in any of the linux documentation:  an ES1869 Control Interface (WDM), at 0x0250-0257 (in Basic configuration 0000, and with "Use automatic settings" enabled.).


By the way; as a completely-unrelated aside, I found your user icon (of all things!) to be of some interesting use today.  I have the old Armada 1750 machine set up on a coffeetable beside my Acer TravelMate 2203LCi - a more 'modern' 2.80GHz Celeron D unit with 1.25GB of DDR memory, and an ATI Mobility Radeon 9000 IGP chip for video.  Both laptops were running 2010 E17 Final (each fully updated) at the time, and happened to be displaying the same forum page - with your user icon.  I noticed that one seemed to be animating faster, so I timed them by counting sixty 'eyeglass-raises' each against a stopwatch.  The results worry me:

Compaq:  66 seconds;

Acer:  251 seconds.

Something must surely be wrong, somewhere.  This same Acer had performed properly previously, with Minime 2008 installed... why is it so slow now, with 2010?  How could it possibly be, that an 'obsolete' 400MHz P2 machine with only Mach64-based video and a mostly-missing BIOS, actually manages to browse (and behave overall) considerably faster than a machine with more modern video, four times the amount of RAM, and a CPU that is more than seven times speedier?

All the more impetus to restore the older unit to proper service, I think...

[vc]

I have Googled a bit this morning, and have thereby learned that dma2 should perhaps be set to 0, rather than 5.  How may I change it?  I have attempted:

modprobe -r snd_es18xx

which resulted in:

FATAL:  Module snd_es18xx is in use.

I have also attempted:

modprobe snd_es18xx io=0x220 irq=5 dma1=1 dma2=0

however, that did not effect the desired parameter change either, as revealed by:

cat /proc/asound/cards

which still returned a value of 5 for dma2.

cat /etc/modprobe.conf

indicated installs of both the ata_piix and uhci_hcd modules, but no snd_* module at all.

I shall now Google to seek examples of modprobe.conf configuration, to hopefully learn a bit of how it should be edited.  Is this approach correct?  Or, should I be seeking to edit a different file instead?  I am currently examining:

/etc/rc.d/init.d/alsa

and

/etc/rc.d/init.d/sound

however, I do find them rather difficult to understand.

[Old-Polack]

I have Googled a bit this morning, and have thereby learned that dma2 should perhaps be set to 0, rather than 5.  How may I change it?  I have attempted:

modprobe -r snd_es18xx

which resulted in:

FATAL:  Module snd_es18xx is in use.

I have also attempted:

modprobe snd_es18xx io=0x220 irq=5 dma1=1 dma2=0

however, that did not effect the desired parameter change either, as revealed by:

cat /proc/asound/cards

which still returned a value of 5 for dma2.

cat /etc/modprobe.conf

indicated installs of both the ata_piix and uhci_hcd modules, but no snd_* module at all.

I shall now Google to seek examples of modprobe.conf configuration, to hopefully learn a bit of how it should be edited.  Is this approach correct?  Or, should I be seeking to edit a different file instead?

Maybe using the original syntax would help:

[root@localhost ~]# modprobe snd_es81xx io=0x220, irq=5, dma=1, dma16=0

or just leave out the second dma16= part altogether. At this point I'm not so sure it's a good idea to have an entry in /etc/modprobe.conf yet. I like to find the settings that work first, then make the "known to be correct" entries to /etc/modprobe.conf. Anyway, the entries would be in the form;

alias sound-slot-0 snd_es18xx
alias sound-card-0 snd_es18xx
modprobe  snd_es81xx io=0x220, irq=5, dma=1, dma16=5, mpu_io=0x330, midi=0x388  

The 5 could be edited to 0 or the entire dma16= part left out, to see if that helps, or even make a difference. Remember, we're dealing with older equipment, and the kernels that were used when that hardware was new were 2.2.x and 2.4.x, so while there may still be support offered in the 2.6.x kernels for the sound card, the syntax for enabling it might be slightly different. It might not be, but there is that chance, so think of this as strictly experimental. With most experiments, one fails more than one succeeds, but it takes only one success to make it all worthwhile. One continues to fail, until one succeeds, then stops experimenting and just uses what works.  

Trying to change the settings for the card, once the initial modprobe command for its module has been given, is difficult without a reboot, as once in use, the running kernel doesn't give it up easily. Maybe it would be better to make the entries in /etc/modprobe.conf, then reboot to see what affect that has, then make edits there and reboot again, to be sure you have a clean loading of the module each time.

[vc]

Maybe using the original syntax would help:

[root@localhost ~]# modprobe snd_es81xx io=0x220, irq=5, dma=1, dma16=0

<...>

Anyway, the entries would be in the form;

alias sound-slot-0 snd_es18xx
alias sound-card-0 snd_es18xx
modprobe  snd_es81xx io=0x220, irq=5, dma=1, dma16=5, mpu_io=0x330, midi=0x388  

The 5 could be edited to 0 or the entire dma16= part left out, to see if that helps, or even make a difference. Remember, we're dealing with older equipment, and the kernels that were used when that hardware was new were 2.2.x and 2.4.x, so while there may still be support offered in the 2.6.x kernels for the sound card, the syntax for enabling it might be slightly different. It might not be, but there is that chance, so think of this as strictly experimental. With most experiments, one fails more than one succeeds, but it takes only one success to make it all worthwhile. One continues to fail, until one succeeds, then stops experimenting and just uses what works.  

Oh, don't worry, Old-Polack - I'm quite accustomed to failure.  It's 'success' that I have difficulty recognising...  

Anyway; old or new, neither command structure format seems to be affecting the parameters in the slightest.

Trying to change the settings for the card, once the initial modprobe command for its module has been given, is difficult without a reboot, as once in use, the running kernel doesn't give it up easily. Maybe it would be better to make the entries in /etc/modprobe.conf, then reboot to see what affect that has, then make edits there and reboot again, to be sure you have a clean loading of the module each time.

Well, this is merely a basic install - so I've no qualms; if a modification attempt should fail, it is really no loss... nor would it be any great bother to re-install.

So; I have since edited /etc/modprobe.conf several times already, both per your instructions as well as my own guesses - and at every reboot, I now see:

modprobe:  WARNING:  /etc/modprobe.conf line 5:  ignoring bad line starting with 'modprobe'

Hmm... elusive.  Is there any other file in which such parameters may be entered?

[Old-Polack]

Well, this is merely a basic install - so I've no qualms; if a modification attempt should fail, it is really no loss... nor would it be any great bother to re-install.

So; I have since edited /etc/modprobe.conf several times already, both per your instructions as well as my own guesses - and at every reboot, I now see:

modprobe:  WARNING:  /etc/modprobe.conf line 5:  ignoring bad line starting with 'modprobe'

Hmm... elusive.  Is there any other file in which such parameters may be entered?

Might try /sbin/modprobe ...

Her's a cutie I just found on a list of possible commands;

install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && { /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1; /bin/true;  }

I'm not sure how to get the various parameters it that case, but maybe they are automatic these days. 

[vc]

Might try /sbin/modprobe ...

Done - no luck there, either:

modprobe:  WARNING:  /etc/modprobe.conf line 5:  ignoring bad line starting with '/sbin/modprobe'

Her's a cutie I just found on a list of possible commands;

install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && { /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1; /bin/true;  }

I'm not sure how to get the various parameters it that case, but maybe they are automatic these days.  

Well, that command gave this result:

install:  unrecognized option '--ignore-install'

Sigh.  I wonder what was ever so 'wrong' with initialising hardware from plain-language parameters stored in a single, ordinary, editable textfile... how did such things ever become so obfuscated and convoluted, instead?  Frustrating... and, it also indicates that my previous localisation efforts were unsuccessful as well, for I see the word "unrecognized" instead of "unrecognised"...

Argh.


<Modify>

Returning towards the sound issue - I am wondering; when one performs:

modprobe snd_es18xx

where does modprobe expect to read the configuration parameters from?  It seems to me that there may be a default configuration file for the module, that would be read upon execution of modprobe in a 'parameter-less' mode such as above - and therefore, that any such parameters being passed from that commandline execution may actually be appended to the existing default string of parameters, rather than replacing them entirely.  Is that line of reasoning valid?  Or is my thinking missing the mark, on that point?

[Old-Polack]

Might try /sbin/modprobe ...

Done - no luck there, either:

modprobe:  WARNING:  /etc/modprobe.conf line 5:  ignoring bad line starting with '/sbin/modprobe'

Her's a cutie I just found on a list of possible commands;

install sound-slot-0 /sbin/modprobe --ignore-install sound-slot-0 && { /bin/aumix-minimal -f /etc/.aumixrc -L >/dev/null 2>&1; /bin/true;  }

I'm not sure how to get the various parameters it that case, but maybe they are automatic these days.  

Well, that command gave this result:

install:  unrecognized option '--ignore-install'

Sigh.  I wonder what was ever so 'wrong' with initialising hardware from plain-language parameters stored in a single, ordinary, editable textfile... how did such things ever become so obfuscated and convoluted, instead?  Frustrating... and, it also indicates that my previous localisation efforts were unsuccessful as well, for I see the word "unrecognized" instead of "unrecognised"...

Argh.


<Modify>

Returning towards the sound issue - I am wondering; when one performs:

modprobe snd_es18xx

where does modprobe expect to read the configuration parameters from?  It seems to me that there may be a default configuration file for the module, that would be read upon execution of modprobe in a 'parameter-less' mode such as above - and therefore, that any such parameters being passed from that commandline execution may actually be appended to the existing default string of parameters, rather than replacing them entirely.  Is that line of reasoning valid?  Or is my thinking missing the mark, on that point?

Well, if that didn't drive you over the edge, how about this, which is actually from this machine, from a pre 2010 installation;

alias snd-0 snd-hda-intel
remove snd_hda_intel /sbin/modprobe --first-time -r --ignore-remove snd_hda_intel
install snd_hda_intel /sbin/modprobe --first-time --ignore-install snd_hda_intel
options snd_hda_intel model=6stack-dig

and another that used a different sound card module;

alias snd-0 snd-intel8x0
remove snd_intel8x0 /sbin/modprobe --first-time -r --ignore-remove snd_intel8x0
install snd_intel8x0 /sbin/modprobe --first-time --ignore-install snd_intel8x0


Obviously the 2.6.27 kernel understood --ignore-install. My sound card was recognized and worked very well.

In my 2010 installation, the entire modprobe.conf is this;

[root@littleboy ~]# cat /etc/modprobe.conf
install ide-controller /sbin/modprobe ide_generic; /bin/true
install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ohci_hcd; /bin/true

No mention of the sound card at all, yet all works fine. Nothing is mentioned in /etc/modprobe.preload either. Do note the lines start with;

install <whatever> /sbin/modprobe <module>;

Maybe you need the install <whatever> part before the /sbin/modprobe <module>; part.   

Also note the options snd_hda_intel model=6stack-dig line, from the first example above, which would seem to be the place for all the parameters from the original modprobe line, if one could get the rest to work.

Back when, you needed to do this sort of thing with every installation, but once you had your hardware running on one, you could just copy the config file to the new installation, and everything worked. Once you knew your hardware, it wasn't that much effort to remember the lines and just write them from scratch. If you replaced a piece of hardware, the pattern was the same, just replace the name of a module, and you were good to go. I was installing every distro I could get my hands on then, and was struck by how much this part remained constant, no matter the distribution. At the time SuSE had the best video detection with an application called SAX. I put copies of my SAX derived XF86config file in every installation, and always got perfect video without having the hassle of trying to use the mostly inadequate configuration tools that came with the distribution.

Things have gotten so automated these days, one gets spoiled, until trying to resurrect old hardware, that had no self identification built in. Then it's panic city, trying to remember all that stuff that hasn't been needed for many years. 

[vc]

Well, if that didn't drive you over the edge,

??

<...>
Also note the options snd_hda_intel model=6stack-dig line, from the first example above, which would seem to be the place for all the parameters from the original modprobe line, if one could get the rest to work.

With the "model=6stack-dig" portion representing what, exactly?  An actual file named "6stack-dig" somewhere, or an internal lookup table record entry in the kernel itself, or perhaps embedded into modules directly?

Back when, you needed to do this sort of thing with every installation, but once you had your hardware running on one, you could just copy the config file to the new installation, and everything worked. Once you knew your hardware, it wasn't that much effort to remember the lines and just write them from scratch. If you replaced a piece of hardware, the pattern was the same, just replace the name of a module, and you were good to go. I was installing every distro I could get my hands on then, and was struck by how much this part remained constant, no matter the distribution. At the time SuSE had the best video detection with an application called SAX. I put copies of my SAX derived XF86config file in every installation, and always got perfect video without having the hassle of trying to use the mostly inadequate configuration tools that came with the distribution.

Yes, I remember that as well.  I first encountered linux in the form of Slackware, back during the mid-Nineties, and dabbled a bit with it then - it was as you say.  In one sense I do miss those days, for things were more straightforward and understandable then - but; on the other hand I also don't, because there were no interesting applications at that time either.  My focus has always been in traditionally non-linux areas such as CAD, graphics, and multimedia editing - yet it is only within the past half-decade or so that linux apps for such have truly become either available or readily-usable, it seems.

Things have gotten so automated these days, one gets spoiled, until trying to resurrect old hardware, that had no self identification built in. Then it's panic city, trying to remember all that stuff that hasn't been needed for many years.

Things are indeed "automated" these days, and yet at the same time only incompletely - for every hardware manufacturer just has to have their own proprietary notions of how it should all be, and of course their 'standard' also just has to be different from everyone else's, and incompatible.  The resultant situation has by now become somewhat of a nightmare, and all linux developers could ever hope to do is to continue playing the 'catch-up' game.  The manufacturers suddenly change the hardware yet again, and then someone has to develop an appropriate work-around or fix.  The kernel changes accordingly, and during the process some things have to be dropped from it, lest it become too large and bloated.

This is why I believe that linux is an OS with no functional history.  I'm clinging desperately onto the falling edge of technology, and the manufacturers and developers are making things increasingly difficult for people like me.  Nevertheless, I struggle onward... however, I find I must give it a rest for the moment, as it seems that my Googling and readings throughout the day have induced a throbbing headache.  I do thank you, Old-Polack; your kind assistances have given me much to think about, and have provided me with directions to proceed towards.  I respect your experience, greatly appreciate your patience, and shall resume my experimentations tomorrow.

[Old-Polack]

<...>
Also note the options snd_hda_intel model=6stack-dig line, from the first example above, which would seem to be the place for all the parameters from the original modprobe line, if one could get the rest to work.

With the "model=6stack-dig" portion representing what, exactly?  An actual file named "6stack-dig" somewhere, or an internal lookup table record entry in the kernel itself, or perhaps embedded into modules directly?

The particular embedded sound chip had about 20 different settings that could be made in various combinations, depending on the motherboard manufacturer, so rather than make a long list, the various combinations were each named as an alias. I could have added all the options, as set on my motherboard, individually, or use the shorthand, "model=6stack-dig" which told the kernel/module the same thing, but with less typing.

The last MB I had with an actual ISA slot, had an ISA SCSI card in it, for my scanner. On that MB, I had to go into the BIOS and reserve the IRQ, and such, for legacy use only, to prevent the settings from being grabbed by a PCI device that wanted to use any of those resources. After that the card was recognized and used the settings specified in the config files. Until I found that BIOS setting, nothing in the config files worked, even though I was absolutely sure they were correct. As soon as I rebooted, after making the BIOS settings, everything that had previously failed in the config files kicked in and the scanner was found immediately. Could it be possible that you have such a BIOS setting also, that needs to be set before the information in the config files can be applied?

[vc]

The particular embedded sound chip had about 20 different settings that could be made in various combinations, depending on the motherboard manufacturer, so rather than make a long list, the various combinations were each named as an alias. I could have added all the options, as set on my motherboard, individually, or use the shorthand, "model=6stack-dig" which told the kernel/module the same thing, but with less typing.

Ahh; I see... it makes sense, now.

The last MB I had with an actual ISA slot, had an ISA SCSI card in it, for my scanner. On that MB, I had to go into the BIOS and reserve the IRQ, and such, for legacy use only, to prevent the settings from being grabbed by a PCI device that wanted to use any of those resources. After that the card was recognized and used the settings specified in the config files. Until I found that BIOS setting, nothing in the config files worked, even though I was absolutely sure they were correct. As soon as I rebooted, after making the BIOS settings, everything that had previously failed in the config files kicked in and the scanner was found immediately. Could it be possible that you have such a BIOS setting also, that needs to be set before the information in the config files can be applied?

Well, this machine doesn't have any BIOS settings in silicon; there's no boot-time key-combination sequence to access the BIOS at all - do you remember the early days of the 286 era, when a boot floppy with a setup utility was required in order to access the BIOS settings?  It's the same situation with this one.  I've already downloaded the files that are needed to generate the applicable floppies, and have also created a Win98SE install on another hard drive for this machine (because the floppy-generation files are unfortunately in Win-only executable format and therefore won't run in DOS); my remaining issue now is to spend a day in going through my boxes of old floppies, in order to test them and hopefully come up with five good ones.  I suppose I should do so today, and thereby resolve the BIOS issues once and for all.

In one sense I do see a considerable advantage with the method, as it is more flexible than placing the entire BIOS code completely into a FlashRAM chip on the motherboard - perhaps safer too, as it then becomes significantly more difficult for someone to 'brick' a machine by inadvertently flashing it with an improper BIOS version... although in another sense this method is also greatly disadvantageous, due to the fact that hard drives do fail, or may be replaced during an upgrade; and, it also makes a typical shop OS re-install more time-consuming and slightly more difficult as well.  Still, though; it is certainly easier for most to rebuild a missing BIOS partition, rather than attempting to replace a FlashRAM chip on the motherboard...

Oh well.  Time to begin the floppy testing.