I had been doing that. . . it was a mess, but I think I've got a reasonable setting with no echo.

asound.state from slamd was apparently incompatible with asound.state from Slackware - I gather they may have changed something else. It seemed to cause the chip to be set up differently. Hence the echo. Also, reboots are necessary to clear extraneous settings that a luser seems to have no control over, and alsa seems to do what it likes with the chip setting it up.

EDIT: Forgot to add a big thank you for the help and constructive ideas.

I think the configs may be incompatible because of different alsa versions, they certainly look different from one another.

I have the echo back this morning. Switch off, pull the battery, and it will probably go :-/.

Yes, the 2 asound.state files do look different.. The thing that bugged me was that apart from the ordering of the comment instruction, all the keywords were identical. Slamd started each control with

comment.access <blah>
comment.type <blah>
comment.count <blah>
etc

whereas slackware had at the end of each control section
comment {
access <blah>
type <blah>
count <blah>
}

but comments are comments, and ignored. Take that out, and there's very little difference. What irritated me hugely is that this led to parallel paths through the device for sound, indicating a significantly different setup for sound. I couldn't really adjust those paths. Slamd sounds sweeter, btw, but it's incorrigibly knackered because I tried to update for radeon drivers, but installing updated stuff broke other stuff, and the compiles went down in flames over versions and crazy things, and the end result didn't work.

Now I get whenever I open something in X. Openoffice & firefox autostart and work, console opens with no bash prompt (and the above error) and you generally go down in flames.

I found that ptys error as a bug around kernel 2.6.7, but I'm on 2.6.33!