How does one get working sound?

It has been suggested that pulseaudio is the problem but that seems impossible to delete

I can not pay sound files from aplay, audacity or csound which are my major tools.

The computer has HDMI and analogue outputs and I need the latter to hear , but audacity does not offer it except as input, aplay says
“ALSA lib pcm_dmix.c:1022:(snd_pcm_dmix_open) unable to open slave
aplay: main:722: audio open error: No such file or directory”

I really need sound!

What do I do?

First off go to Yast - sound and set the configuration perhaps changing the order of the devices. The test sound should work in yast if it does not we need more info like what sound devices you actually have.

Also useful is the pavucontrol program that allows associating application to sound devices.

Also if you try to play proprietary formats you will need the codecs from packman

An did you make the switch to the Packman repository? As explained in the sticky threads at the top of this Multimedia forum?

>> First off go to Yast - sound and set the configuration perhaps changing the order of the devices. The test sound should work in yast if it does not we need
>> more info like what sound devices you actually have.

Tried that days ago. There are two audio devices and what ever order I place them in the first ifs HFMI (which is useless as I have no such devices, and the second is PCM wich I want – just to hear on the laptop speakers. The test sound is silent. I have reset/rrstarted audio to zero effect

>> Also useful is the pavucontrol program that allows associating application to sound devices.

no such command, and anyway it used to work

>> Also if you try to play proprietary formats you will need the codecs from packman

WAV is not proprietary, nor is simple PCM. I am interested in audio not video, almost no mp3s either but some ogg.

>> And did you make the switch to the Packman repository? As explained in the sticky threads at the top of this Multimedia forum?

No change. I have used packman for some things for years. puseaudio is from SuSE, as is audacity (Packman version fails). csound is built from sources – that is what I do.

This started about a week or 10 days ago.

I should perhaps add I am using X11 with fvwm, no gnome or kde or desktop system. xterms with CLI and emacs mainly.
Also timidity works for therare times I use MIDI

Is timidity set as a system process? if so that will lock out all other audio since it captures the sound device before pules starts.

.

As far as I know it is a command like any other. What is a system process? Certainly no daemon associated.
v

Read this thread please it is the same problem and was caused by timidity

https://forums.opensuse.org/showthread.php/513210-Sound-card-greyed-out-in-Kmix-not-visible-in-plasma5-pa-in-Leap-42-1/page2?highlight=timidity

I cannot see how. There is no timidity daemon. This is a fresh reboot from no power and I get

*** Cannot open device ‘default’ for audio output: Device or resource busy
Failed to initialise real time audio output

> ps ax | grep timidity
16726 pts/1 S+ 0:00 grep timidity

The links you posed all refer to some desktop whatever that is. I have not run timidity for days but this persists, but only started about 10 days ago
I could not find anything in those links to say HOW to make changes to timidity

So still no alsa sound

My limited understanding of GNU/Linux is that devices typically have an open file associated with them associated with applications accessing the device … and so if one checks for an appropriate open file, one can sometimes get a clue as to which application(s) are accessing the device.

Under that assumption, could you look to see which applications (if any) have your sound device open ? Try sending the following command from an xterm (as a regular user) :


lsof | grep '/dev/snd/'

there is nothing complex there. I’m just curious to see the list of open files (lsof) associated with your sound device ( /dev/snd ). For example on my 13.2 PC with KDE and pulse audio, I get:


pulseaudi  1606           oldcpu   16u      CHR              116,2       0t0      15818 /dev/snd/controlC0
pulseaudi  1606           oldcpu   23u      CHR              116,2       0t0      15818 /dev/snd/controlC0
pulseaudi  1606           oldcpu   28u      CHR             116,14       0t0      10147 /dev/snd/controlC2
pulseaudi  1606           oldcpu   31u      CHR              116,7       0t0      10678 /dev/snd/controlC1
pulseaudi  1606           oldcpu   38u      CHR              116,7       0t0      10678 /dev/snd/controlC1
pulseaudi  1606           oldcpu   43u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sink  1606  1619     oldcpu   16u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sink  1606  1619     oldcpu   23u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sink  1606  1619     oldcpu   28u      CHR             116,14       0t0      10147 /dev/snd/controlC2
alsa-sink  1606  1619     oldcpu   31u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sink  1606  1619     oldcpu   38u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sink  1606  1619     oldcpu   43u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sour  1606  1622     oldcpu   16u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sour  1606  1622     oldcpu   23u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sour  1606  1622     oldcpu   28u      CHR             116,14       0t0      10147 /dev/snd/controlC2
alsa-sour  1606  1622     oldcpu   31u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sour  1606  1622     oldcpu   38u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sour  1606  1622     oldcpu   43u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sink  1606  1626     oldcpu   16u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sink  1606  1626     oldcpu   23u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sink  1606  1626     oldcpu   28u      CHR             116,14       0t0      10147 /dev/snd/controlC2
alsa-sink  1606  1626     oldcpu   31u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sink  1606  1626     oldcpu   38u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sink  1606  1626     oldcpu   43u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sour  1606  1627     oldcpu   16u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sour  1606  1627     oldcpu   23u      CHR              116,2       0t0      15818 /dev/snd/controlC0
alsa-sour  1606  1627     oldcpu   28u      CHR             116,14       0t0      10147 /dev/snd/controlC2
alsa-sour  1606  1627     oldcpu   31u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sour  1606  1627     oldcpu   38u      CHR              116,7       0t0      10678 /dev/snd/controlC1
alsa-sour  1606  1627     oldcpu   43u      CHR              116,7       0t0      10678 /dev/snd/controlC1

One can also type


lsof | grep snd

but then one gets more than just /dev/snd occurences, but one also then gets sound libraries open … etc … and I find I get flooded with more information that exceeds my limited knowledge on this to even begin to understand.
.

Note that timidity is shown as capturing the sound card and owning it. Thus no other sound program can use that card. it is locked… Main purpose of Pulse is to allow multiple sound channels to share the hardware. I don’t use Timidity but as I understand it the default is to run as a system service. Thus it gets started and captures the sound device before pulse runs which is normally run as a user program. In any case it is timidity that is causing the problem. remove or set it to run as a user process not a system service.

As a follow up, one can come up with a shorter list (and not illustrate the alsa-sinks … ) by instead typing:


lsof /dev/snd/*

If another application has seized your audio device (ie /dev/snd) that list of open files should make it absolutely clear and convince you of that.
.

uRunning lsof | grep ‘.dev/snd/’
pulseaudi 2691 jpff mem CHR 116,8 16695 /dev/snd/pcmC1D0p
pulseaudi 2691 jpff 16u CHR 116,2 0t0 13110 /dev/snd/controlC0
pulseaudi 2691 jpff 22u CHR 116,7 0t0 16694 /dev/snd/controlC1
pulseaudi 2691 jpff 23u CHR 116,2 0t0 13110 /dev/snd/controlC0
pulseaudi 2691 jpff 24u CHR 116,7 0t0 16694 /dev/snd/controlC1
pulseaudi 2691 jpff 29u CHR 116,8 0t0 16695 /dev/snd/pcmC1D0p
pulseaudi 2691 jpff 31u CHR 116,7 0t0 16694 /dev/snd/controlC1
pulseaudi 2691 jpff 36u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2703 jpff mem CHR 116,8 16695 /dev/snd/pcmC1D0p
alsa-sink 2691 2703 jpff 16u CHR 116,2 0t0 13110 /dev/snd/controlC0
alsa-sink 2691 2703 jpff 22u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2703 jpff 23u CHR 116,2 0t0 13110 /dev/snd/controlC0
alsa-sink 2691 2703 jpff 24u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2703 jpff 29u CHR 116,8 0t0 16695 /dev/snd/pcmC1D0p
alsa-sink 2691 2703 jpff 31u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2703 jpff 36u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2704 jpff mem CHR 116,8 16695 /dev/snd/pcmC1D0p
alsa-sink 2691 2704 jpff 16u CHR 116,2 0t0 13110 /dev/snd/controlC0
alsa-sink 2691 2704 jpff 22u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2704 jpff 23u CHR 116,2 0t0 13110 /dev/snd/controlC0
alsa-sink 2691 2704 jpff 24u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2704 jpff 29u CHR 116,8 0t0 16695 /dev/snd/pcmC1D0p
alsa-sink 2691 2704 jpff 31u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sink 2691 2704 jpff 36u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sour 2691 2705 jpff mem CHR 116,8 16695 /dev/snd/pcmC1D0p
alsa-sour 2691 2705 jpff 16u CHR 116,2 0t0 13110 /dev/snd/controlC0
alsa-sour 2691 2705 jpff 22u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sour 2691 2705 jpff 23u CHR 116,2 0t0 13110 /dev/snd/controlC0
alsa-sour 2691 2705 jpff 24u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sour 2691 2705 jpff 29u CHR 116,8 0t0 16695 /dev/snd/pcmC1D0p
alsa-sour 2691 2705 jpff 31u CHR 116,7 0t0 16694 /dev/snd/controlC1
alsa-sour 2691 2705 jpff 36u CHR 116,7 0t0 16694 /dev/snd/controlC1

re timidity, if I do not run it how does it capture the snd card? I have not run timidity for 3 days and the computer is rebooted daily

and I repeat…HOW do I change timidity to a user process? I just ran it as “timidity ForM.midi” from the command line in an xterm.
And why did it change? And how do I get this non-existent timidity prcess to release the device it has been hoarding for days?

PS thre bbc is another casualty of this

> lsof /dev/snd/*
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 2691 jpff mem CHR 116,8 16695 /dev/snd/pcmC1D0p
pulseaudi 2691 jpff 16u CHR 116,2 0t0 13110 /dev/snd/controlC0
pulseaudi 2691 jpff 22u CHR 116,7 0t0 16694 /dev/snd/controlC1
pulseaudi 2691 jpff 23u CHR 116,2 0t0 13110 /dev/snd/controlC0
pulseaudi 2691 jpff 24u CHR 116,7 0t0 16694 /dev/snd/controlC1
pulseaudi 2691 jpff 29u CHR 116,8 0t0 16695 /dev/snd/pcmC1D0p
pulseaudi 2691 jpff 31u CHR 116,7 0t0 16694 /dev/snd/controlC1
pulseaudi 2691 jpff 36u CHR 116,7 0t0 16694 /dev/snd/controlC1
>

It defaults to a system process but that does not mean you see it until you run the shell but parts are running in the background.

Refer to the timidity documentation to see how to run as a user process rather then a system.

/usr/share/doc/packages/timidity/README.SUSE

Might look at fluidsynth instead if you can not figure out the timidity documentation

.

If this is the timidity problem, then unfortunately the bug.freedesktop.org site with the detail that answers some of your questions is not accessible currently. That is: https://bugs.freedesktop.org/show_bug.cgi?id=94165

The openSUSE bug report 965328 – Soundblaster works only in Yast, not in KDE noted for a user with a sound problem that timidity was blocking one of the (32) subdevices of the sound card. That was enough for pulseaudio to mark the whole card as busy; as pulse audio doesn’t support hardware mixing. My understanding is that is what gogalthorp assesses as the problem.

I had thought a list of open files (directly accessing the sound device) would show this but it has not.

Possibly if one also looked at the open libraries for sound via " lsof | grep snd " one would have better visibility - but I don’t know. And as noted, the bug report that had very useful information ( https://bugs.freedesktop.org/show_bug.cgi?id=94165 ) is currently not accessible. I suggest try again to access that site in a day or two for further guidance.

I know I am being thick about that but the file /usr/share/doc/packages/timidity/README.SUSE does not give any clue.

All I want from timidity is to render a midi file and stop; the documentation says "However timidity can be started as a daemon for the user to provide the midi
ports he/she needs for i.e. canorus. On the console of the user give the command
:

timidity -iAq -Oe -s 44100"

I cannot see what this has to do with timidity grabbing a device and keeping it through a power cycle and audio restarts
I do not want to provide a midi port – just play a piece every 5 or 6 months. I read the man page and no option seemed of any relevance.
surely one can remove the lock from a dead process? In effect timidity has bricked my computer!

Remove it it is not the only program that does what it does. And deleting it should get you a working sound system

>Hurrah! That worked. Now all I nee is to identify a working replacement for timidity but at least that is low priority

Thank you