I don't understand audio but I am increasingly obliged to use audio software to help with the online operations of my parish church. I have alsa-utils and I have recently installed sox on the advice of someone here; I must say I am greatly impressed with what it can apparently do.

I am trying to use alsamixer to improve my sound recording quality, but I don't understand audio terminology, so the man pages and display captions are about as informative for me as if they were written in a foreign language. So I decided to just try modifying one alsamixer column at a time to see what the effect would be on a test recording. That way, I hoped, I could find out what the captions actually mean.

Then suddenly alsa went on strike. Every attempt to record produced this:
I ran top and that didn't suggest any great demands on memory. All the same, I shut down everything else and tried again. Nothing doing!

Googling the error produced only references to an occasional bug that had been cleared up, and to someone using Fedora who got that error only when he used audio as an unprivileged user. Just to check, I did it again as root and got the same result. So I shut down in disgust.

This morning everything works normally, but for how long? What did I do to create that error? And what should I do to stop it happening again?

I'd move alsa out of the way, & reinstall from scratch, esp. the configs. Then start over

The ones I'd concern myself with are Main; The one beside it(=analog) &pcm(=digital).I wuldn't use mic_boost unless absolutely needed, & most do nothing. I imagine it's the config screwing up your system.

It hasn't happened again (so far).

The attached is the capture interface for my card. If someone could just explain to me what the captions along the bottom mean, that would be a good start. They don't seem to correspond to the ones business_kid mentions.

I'm using it to record my cello and I need to boost the mic, otherwise it is just too quiet.

Attached Thumbnails

 

The ones I mentioned were playback options. You're showing a screen of (Input) mixer options - have you a mixer installed.

If that's the case, I'd give them all 30%, start playing with stuff trying to get sound out and turning up as necessary. If you only get silence, try 50%. But it's easy to get feedback. Give no volume to any mic boost. Capture is stereo in and line is some mixer point where the inputs are summed, typically 0-200mV, before amplification.

Whoa! That's all Greek to me, especially the last sentence.

What I am trying to do is record the sound of my cello. That's why I attached alsamixer's input interface. At present the recorded sound is very quiet and I would like to make it louder. Having the microphone very close doesn't seem to have a good effect; it picks up the small reverberations that the strings make when I take my finger off them (which is something you don't usually hear and certainly don't want to hear). So placing it further away and using some kind of gain or boost seems to be the way to go.

I have two input sockets, one at the front and one at the back. I gather that they can accept either a microphone lead or a line in from an external device such as a CD player, and that alsa needs to know which it is because a mic gives a very weak signal which needs an automatic boost. So the two columns labelled Source and Source1 have three values each: front mic, rear mic and line. I also assume that the two Capture columns are to boost these two sources. So if I am using the front socket only and plugging a mic into it, Source should be set to "Front mic" and Capture1 should be switched off because Source1 is not in use. Am I right so far?

The Front mic, Line and Rear Mic columns are obviously for boosting; I assume that in my setup only Front mic is active so there is no point in setting the others. But what is the practical difference between increasing Front mic and increasing Capture? That is the most important thing I need to know right now.

I often wonder if people would be (more) happy with an expected crash.

Maybe it's just my propensity for cryptic crosswords surfacing ...

Yes, of course they would! If you know that a program reliably crashes when you do a certain thing, you just don't do it. Problem solved!

It happened again today! Just as I was about to make my final recording. Grr!

It affects only recording. I can play files back, and I can use sox to convert a file into a different format. That must mean that the shared memory which is not being allocated was requested by the device on the sound card that does input processing. But why is it not being allocated and what am I supposed to do about it (apart from rebooting)?

Something else weird which must surely be connected. When I look at the alsamixer capture controls, there is a column labelled "Digital". I remember that it was there when this problem first appeared. But yesterday when the sound card was behaving quite normally, that column was absent. What does the column represent and why is its appearance such a bad omen?

PS This seems to be Alsa's description of it:

Attached Thumbnails

   

Have you tried removing control 39 from the config? Also, there's some sound-editing thing (Audacious?) that might tidy things up for you. Have a look at it.

I made a new version of /etc/asound.state without that section in it and stored it in my home directory. Then I ran alsactl restore -f .asound.state. But alsamixer still shows a "Digital" column and recording still doesn't work.
I don't want any extra sound software until I have discovered a way to make my existing software work. alsa is absolutely basic; every other package sits on top of it.

Red herring alert!

Today recording works. When I first put up alsamixer this morning, there was no digital capture column displayed. Now there is one. It seems that it takes time to come up. But recording still works (so far!)

I used alsactl to save the current state. We'll see if restoring to that state solves any future problems.

I solved my recording problem by reversing the method: I recorded my cello part on the laptop while playing the backing track on the desktop machine. So at least I have that off my to-do list. But I don't like being dependent on software that fails in ways I don't understand. After all, that was one reason why I left Windows all those years ago.

Ah yes, I remember it well. There's a song that uses those words but doesn't mean it.

Back then the only way to understand windows was to join M$.

Glad you're going.

Today it happened again, and in a way that shows it is definitely an intermittent thing. I was again recording for my church, a reading this time. The first two attempts ran OK more or less but little things went wrong (as they do), so I was just doing it over again. And the third time I tried, I got this same error. It just popped up out of the blue and I hadn't made any changes that might have caused it. I tried two or three times and got the same error each time.

So I got out the laptop, recorded on that and copied it over with scp. Then I thought I'd try to play it over as a final check before mailing it. And it played normally. All in a space of 10 minutes or so. So it's a thing which just happens sometimes but once it happens it goes on happening. Then you let it rest and it stops again, without a reboot.

Does that give anyone a better idea of what might be causing it? Because it's a bloody nuisance when your audio packs up sometimes for no apparent reason just when you want to use it.

All hardware errors like that are timing issues. But I don't suspect hardware.

Could thermal throttling or latency cause it, e.g. your system starts in turbo mode, and then slows down as the cpu heats, or some such? Maybe a caching issue?

What's turbo mode and how can I find out if I'm using it? I remember that one of the first computers I ever used had a button on the case labelled turbo but I never used it and I've never seen that button on another machine.