OpenBSD 6.7 loses audio

[notooth]

Hello,

The audio is lost after about half an hour usage on OpenBSD 6.7. Sometimes, the audio is back for no reason. Otherwise, I have to reboot the computer to get the audio back. Is there a way to fix it?

[ripe]

Maybe a process use your sound and block it for another program who was using the sound?

[fvgit]

That seems unlikely. OpenBSD's sndiod(8) supports input from various sources. For instance, I can play two audio files simultaneously and hear them both at the same time, they don't cancel each other out.

[ripe]

Ok thanks mate.

[jggimi]

Unfortunately, notooth has not provided us with enough details to do anything more than make some wild guesses.

[flfederation]

I can never get sound except as root. I think I can also get two things to play at once, but again only as root.

What sorts of details would help? This is what mplayer says when I'm not root:

Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 96.0 kbit/3.40% (ratio: 11999->352800)
Selected audio codec: [ffaac] afm: ffmpeg (FFmpeg AAC (MPEG-2/MPEG-4 Audio))
================================================== ========================
ao2: can't open sndio
[AO SDL] Samplerate: 44100Hz Channels: Stereo Format floatle
[AO SDL] Unsupported audio format: 0x1d.
[AO SDL] Unable to open audio: No available audio device
DVB card number must be between 1 and 4
AO: [null] 44100Hz 2ch floatle (4 bytes per sample)
Starting playback...

Nothing is added to dmesg output. Same thing happens whether running it from X or from VT without X running.

[jggimi]

1. Start with the sndio(7) man page. This describes the sound system on OpenBSD.
2. Run $ dmesg | grep audio to find out for yourself what audio hardware your kernel has attached. That way, you'll know enough about your hardware to compare it with others who have the same audio. As an example, here's my attached audio(4) devices at the moment. I have two audio(4) devices, audio0 is my onboard soundcard, and audio1 is a USB-attached headset.

   $ dmesg | grep audio
   audio0 at azalia0
   uaudio0 at uhub2 port 2 configuration 1 interface 1 "Plantronics Plantronics DA80" rev 2.00/1.33 addr 3
   uaudio0: class v1, full-speed, sync, channels: 1 play, 1 rec, 6 ctls
   audio1 at uaudio0
   $

3. Check to ensure sndiod(8) is running. This is required for non-root audio access. e.g.: $ pgrep -lf sndiod
4. Check to see if you've provisioned a non-standard sndiod startup argument string in /etc/rc.conf.local. This can effect how hardware devices are provisioned for use.
5. Check to see if the AUDIODEVICE environment variable is set. If not, the default device will be whatever is attached to audio0 -- known as device snd/0 in the sndio(7) subsystem, assuming you are using sndiod(8) with defaults.

The sndiod(8) daemon will automatically manage any removals or attachments of audio hardware, such as that USB headset of mine. Generally, this is not an issue, but you may need to set the AUDIODEVICE environment variable to use the non-default audio device.

[flfederation]

Originally Posted by jggimi

[*]Check to ensure sndiod(8) is running. This is required for non-root audio access. e.g.: $ pgrep -lf sndiod

It is running, though I didn't know it was necessary for that purpose.

[*]Check to see if the AUDIODEVICE environment variable is set. If not, the default device will be whatever is attached to audio0 -- known as device snd/0 in the sndio(7) subsystem, assuming you are using sndiod(8) with defaults.

I'm using rsnd/1 so I tried setting AUDIODEVICE (it was not set) with:

export AUDIODEVICE=rsnd/1

Since I'm probably not doing that right, I'll look into the proper syntax as well as the other things you mentioned. I DID start with the FAQ, which is why I knew to switch to rsnd/1 in the first place-- Bee ore --at, -ound -as li-- t--s.

But it's very possible I missed a few parts of the FAQ. Thankfully, not everything you mentioned is familiar. That means there are still things to try that I haven't tried yet. Thanks very much. (I'll let you know if there's progress.)

I also hope this encourages the OP to either try something or give more details. Either way, thanks.

UPDATE 1: I think 'export AUDIODEVICE=rsnd/1' is correct actually. rsnd/1 is what I set with rcctl based on the FAQ, and before that sound didn't work properly even as root (no sound as user either).

Since I'm only playing sound as root, I've only used mixerctl as root. When I try as user, it says "mixerctl: /dev/audioctl0: Permission denied" but I assume it's supposed to. I thought I'd mention it if it's not.

I've watched a bunch of videos on Pledge, so I know the point of daemons like sndiod is traditionally to enable privsep and privdrop-- I assume /dev/audioctl0 should only be something sndiod or root can access. Which almost implies users aren't meant to run mixerctl as well. But I figure mplayer ought to (hence why sndiod exists).

I am still learning a lot of things about BSD; I knew that OpenBSD's firefox has keybindings for emacs; what I didn't know until today was that CTRL-/ does what I've been missing (select all).

UPDATE 2:

"The sndioctl(1) utility is used to manipulate audio controls as a regular user. Running it with no arguments will list all the controls and current settings."

$ sndioctl
default: can't open control device

$ sndioctl -f rsnd/1
rsnd/1: can't open control device

Is there a group I should add the user to, perhaps? Maybe I didn't adduser properly. Getting sound to work AT ALL was not a priority at the time.

User is already on wheel, but not: kmem sys tty operator staff guest

[jggimi]

You'll want to keep sndiod with its default provisioning, and use $ export AUDIODEVICE=snd/1. The rsnd/1 device is raw hardware, and requires root access.

[flfederation]

Well this is depressing. Not only have I not gotten sound to work as user, I'm now in the same position as the OP. I've got lots more to try now, but I've fiddled with very little, and yet I can't seem to get back to where it was before...

UPDATE: I did the silly/luser move and rebooted. Very unUNIXy of me, I'll flog myself properly later.

The good news is that I have sound back as root (albeit choppy like it was the first time I ever tried to play anything) and also I have sound as user (albeit choppy like it was the first time I ever tried to play anything as root).

I can probably do what I originally did and fix sound perfectly for root again.

Instead, I'm going to try new stuff to fix sound as user-- I'd prefer not to use mplayer as root, of course.

PROGRESS!

As user I'm using export AUDIODEVICE=snd/0 while as root I'm using export AUDIODEVICE=rsnd/0 -- I was never meant to use rsnd/1. That was my first mistake.

As you said, rsnd/0 is not possible to use except as root. Pity, because right now I get sound from EITHER root or user, but root actually gives me the proper playback like before, whi--ile--sou-ound--fru-om--use-er--so-ounds--li-ike--thi-is.

That's what made me try different devices in the first place-- which worked, so I never questioned it. But it only worked as root.

I can now actually get sound as user. I still need root for the sound to work properly though.

User _sndio is running /usr/bin/sndiod -f rsnd/0 -F rsnd/1 -- I realise the part after -F is probably wrong, I'm not using a USB device-- just the onboard. This was set with rcctl, but not since the reboot.

User _sndiop is running sndiod: helper (sndiod)

[jggimi]

I recommend using the default provisioning for sndiod(8). No options set. This way, you're less likely to drive yourself crazy. See step 4 above. By default, sndiod(8) has no options set, and runs by default. To keep the defaults, you can edit /etc/rc.conf.local and remove anything you've "accidentally" provisioned for sndiod(8).

Review your audio(4) devices in your dmesg(8), as I'd suggested in step 2 above. If you only have an audio0 device, and do not have an audio1 device, you should not need to set the AUDIODEVICE environment variable, because the default sndio(7) device will be used, snd/0.

[flfederation]

Originally Posted by jggimi

If you only have an audio0 device, and do not have an audio1 device, you should not need to set the AUDIODEVICE environment variable, because the default sndio(7) device will be used, snd/0.

This is not a dismissal of the other things you've suggested, which I'm now looking into. But as things are now, as root:

export AUDIODEVICE=
# mplayer has no sound, even as root
export AUDIODEVICE=snd/0
# mplayer has very choppy sound, even as root
export AUDIODEVICE=rsnd/0
# mplayer works properly, but only as root

as for user:
export AUDIODEVICE=
$ mplayer has no sound, video isnt choppy
export AUDIODEVICE=snd/0
$ mplayer has very choppy sound, video struggles along with it
export AUDIODEVICE=rsnd/0
$ mplayer has no sound, but as user we dont expect it to. video works fine.

So I only get good results with rsnd, but snd/0 has never worked properly. (on any machine I've put openbsd on actually).

I will try the other things you suggested. I WOULD also try the latency trick, but I haven't since I expect that to yield lesser results than running as root, which doesnt require changing latency.

I feel (without knowing what I'm talking about) that getting rsnd/0 to work through the daemon is the answer here. I'm not sure thats even possible, based on what you said.

I commented out the sndiod line in /etc/rc.conf.local -- default! rcctl restart sndiod...

Now pgrep -lf sndiod says that sndiod is running without options, but the table above with export AUDIODEVICE still applies-- as root, as user.

I now have a simpler setup, but without rsnd/0 it still really isn't usable. This is acceptable, but it doesn't seem ideal.

[jggimi]

Setting AUDIODEVICE to blank is not the same as removing it. Use unset in a bourne-based shell, unsetenv in a c-based shell.

You might try testing audio-only files, to rule out video playback as a co-conspirator. You might also test with a different player to eliminate your software choice as a possible problem.

Keep in mind -- all we have to go on is what you post, we don't know anything about your audio hardware and therefore can't compare its function on your workstation to our experience or knowledge.

[flfederation]

Having learned how to use ktrace, I found out that /dev/audio0 was the device rsnd/0 uses. Making this world-writable (622 specifically) allows export AUDIODEVICE=rsnd/0 to work, which solves my problem.

I have choices now-- I don't want /dev/audio0 to be world-readable, but I think 622 takes care of that. Now that I don't have to be root to play audio, sound in Firefox may even work (not important to me, though a bonus). EDIT: it does!

My choices now are to run mplayer as root-- which I figure is worse, and to have /dev/audio0 world-writable, at least when I choose to set it that way. I figure that's better, especially when I can change the permissions whenever I like. But if there are suggestions about that, I'm interested. Thanks very much for your help, I'm excited about the things I learned while trying to fix this. If this were my thread, I'd mark it [SOLVED].

[jggimi]

I don't know anything about your hardware, or if you're running -release, -release + patches, or -current. My prior recommendations included trying a different player, and trying an audio-only media file to determine if there are any software or video-related issues. I don't know if you've made these tests.

Meanwhile, I know you've circumvented sndiod(8)'s snd/0 processing with permission changes and are using rsnd/0.

If you've isolated the problem to exclude both the player and exclude the type of media, you have a bug worth reporting, and worth reporting soon, as the next release is currently in beta. You could either report the problem in -release (if applicable), upgrade to -current (if applicable) and report if the problem is still unresolved.

http://www.openbsd.org/report.html

[flfederation]

Originally Posted by jggimi

I don't know anything about your hardware, or if you're running -release, -release + patches, or -current.

Probably -stable. If that's not a thing, probably -release, Not -current.

My prior recommendations included trying a different player

That takes longer than what I've done so far. Relevant because of the steps involved. Have to set a path, find another media player, I'm still about a week or two into all this stuff. Finding packages (which I know how to do) doesn't yield a lot so far.

and trying an audio-only media file to determine if there are any software or video-related issues. I don't know if you've made these tests.

I've tried audio only, it has the same issue. I've also installed the same software on several machines.

What I've learned posting about this on another forum is that the sndio support for mplayer and mpv is experimental-- this could be due to mplayer. However, I wasn't getting sound on Firefox either until I sorted this out the way I did.

I didn't assume it was a bug, I assumed this was a PEBKAC error, even though I'm the P. Quite new at this stuff, which is why I'm spending more time reading and asking questions than filing bug reports.

As for the issue with col segfaulting, I would have filed that except I'm having trouble with email. I don't think that's OS-related. I'm not using sendbug even though they would prefer it. Not going to happen, sorry.

I did some of the more obvious tests (like sound-only) before I jumped into this thread. I know I hadn't mentioned that yet.

This isn't just tinkering with one machine, it's a migration from one operating system to another on various bits of equipment, so if I seem a bit preoccupied, I'm not used to getting this much assistance. I appreciate it, but I'm only just getting situated with this stuff. I may not be the debugger you're looking for. I will try to help where I'm able.

If you've isolated the problem to exclude both the player and exclude the type of media, you have a bug worth reporting, and worth reporting soon, as the next release is currently in beta. You could either report the problem in -release (if applicable), upgrade to -current (if applicable) and report if the problem is still unresolved.

I don't have nearly enough information to file the kind of bug report they want. This is either user error or edge case, I really doubt the quality of 6.8 depends on it. I'm flattered that you think I could affect the outcome of the next release in a significant way, but I'm already gaining new skills a lot faster than I normally do.

If I contribute an important bug, it will probably have to wait for 6.9. This isn't out of lack of gratitude or even laziness, I'm simply doing all I can at the moment. On matters of laziness, this is far more effort than I've ever put into debugging sound. I'm not complaining, I'm thrilled it worked.

But some of this is a bit overwhelming, and it's going to take more time and experience before I'm in a position to do much. I've already got more things to do than I can keep up with, though I'm trying.

The sound is the part I was stumped by the most, though it's not the highest priority on a long list of things to accomplish. I'm also doing teaching, editing wikis, writing articles, helping someone debug the code in an application they're working on-- there's some upheaval going on where I live that's messing with my sleep and making me less productive... I got less than 4 hours last night.

If I knew more, I might be better able to say if this is even a bug or not. But to know more means doing regular tasks that still aren't regular tasks for me.

Imagine building the same car you're driving, while you're on a cross-country road trip. That's what this feels like. Not a complaint! OpenBSD is actually a refreshing change. But on my side this is a work in progress. My skills aren't production ready, and I don't think you're really missing out on much-- honest! Though adding a deadline for a bug report isn't going to help. They're not going to take anything I can send them right now seriously-- nor would I.

[jggimi]

Originally Posted by flfederation

Probably -stable. If that's not a thing, probably -release, Not -current.

The -stable flavor is close to -release + patches, but may include patches not broadly applicable enough or not serious enough to warrant errata publication between releases. You'd know if you were on -stable, because -stable must be built from source, the Project doesn't publish -stable kernels or filesets -- just -stable packages, which can be used with -release.

That takes longer than what I've done so far. Relevant because of the steps involved. Have to set a path, find another media player, I'm still about a week or two into all this stuff. Finding packages (which I know how to do) doesn't yield a lot so far.

There are two built-in audio players: aucat(1), which can play WAV files, and cdio(1), which can play audio CDs.

I've tried audio only, it has the same issue. I've also installed the same software on several machines.

Excellent, you've ruled out video as a problem source.

...However, I wasn't getting sound on Firefox either until I sorted this out the way I did.

Then you've also ruled out mplayer as the problem source, since it occurs with your browser too.

I didn't assume it was a bug, I assumed this was a PEBKAC error, even though I'm the P. Quite new at this stuff, which is why I'm spending more time reading and asking questions than filing bug reports.

You can post an informal bug report to the misc@ mailing list, asking for help as you did here. But you'll need to post information there you haven't yet posted here, like your dmesg(8). That shows not only which specific kernel you are running (architecture, release, flavor, who built it and when), but also what that kernel reports about your hardware.

As for the issue with col segfaulting, I would have filed that except I'm having trouble with email. I don't think that's OS-related. I'm not using sendbug even though they would prefer it. Not going to happen, sorry.

You don't need a working outbound Email on OpenBSD to use sendbug(1).The tool can save your report for further handling without having any Email configured on OpenBSD. Just use a)abort when you're done producing the report, and you can move the bug report file to another OS for sending, copy/paste into a webmail service, etc.

I don't have nearly enough information to file the kind of bug report they want. This is either user error or edge case, I really doubt the quality of 6.8 depends on it. I'm flattered that you think I could affect the outcome of the next release in a significant way, but I'm already gaining new skills a lot faster than I normally do.

Any user at any skill level can make valuable contributions. All you need is to be able to clearly articulate your information about the OS and your hardware, and your exact experience so that someone can replicate the problem. The first part is taken care of for you just by including your dmesg(8). The second is just as you've described here already -- snd/0 produces broken-up sound, rsnd/0 works well, both with mplayer and firefox. If you're able to replicate the problem using a WAV file with aucat(1), you don't even need to mention mplayer/firefox. This can be very informal, as in requesting advice for further help, just like you've done here, but an unreported bug won't get fixed unless a developer happens to discover it through serendipity.

[flfederation]

All good advice jggimi, new problem though. This is like debugging in the Twilight Zone... I mean things work... but when I break them the way they're supposed to be broken, they're breaking differently now.

There are two ways I can set /dev/audio0 that are relevant: 622 (crw--w--w-) and 600 (crw-------). The latter is how I think it was, the former is how I fixed it.

Before, I could get choppy sound if I set AUDIODEVICE to snd/0, now it's all or nothing:

/dev/audio0 set 600:
export AUDIODEVICE=snd/0
# no sound
export AUDIODEVICE=rsnd/0
# works great

export AUDIODEVICE=snd/0
$ no sound
export AUDIODEVICE=rsnd/0
$ no sound

/dev/audio0 set 622
export AUDIODEVICE=snd/0
# works great
export AUDIODEVICE=rsnd/0
# works great

export AUDIODEVICE=snd/0
$ works great
export AUDIODEVICE=rsnd/0
$ works great

You can tell me if I set the "superposition" bit, I won't tell anybody.

It's like when you plug in a USB-2 device? The first way doesn't work, so you flip it 180 and the second way doesn't work, but you flip it again to the superposition, and then it plugs in.

I'll let you know if I can break it properly again. Email's working, naturally.

OpenBSD accepts hardware donations. Maybe I can just go to Canada and say "Here, have fun with it! I can fix it, but I can't break it the way I wanted again. It works fine now."

"What?"

I'm telling you, it's PEBKAC. I've stared at this thing too long for it to make sense. If you want me to do something useful with this, I'm going to have to put it aside for a while. It's the only way.

[jggimi]

The correct file modes, ownership, and major/minor node numbers for /dev/audio* devices, extracted from this laptop:

crw-rw----  1 root  _sndiop   42,   0 Sep 17 10:03 /dev/audio0
crw-rw----  1 root  _sndiop   42,   1 Sep 15 21:22 /dev/audio1
crw-rw----  1 root  _sndiop   42,   2 Sep 15 21:22 /dev/audio2
crw-rw----  1 root  _sndiop   42,   3 Sep 15 21:22 /dev/audio3
crw-rw----  1 root  _sndiop   42, 192 Sep 15 21:22 /dev/audioctl0
crw-rw----  1 root  _sndiop   42, 193 Sep 15 21:22 /dev/audioctl1
crw-rw----  1 root  _sndiop   42, 194 Sep 15 21:22 /dev/audioctl2
crw-rw----  1 root  _sndiop   42, 195 Sep 15 21:22 /dev/audioctl3

You should be able to reset them to their defaults, or if you need to, delete and recreate them, through MAKEDEV(8):

# cd /dev
sh MAKEDEV audio

or perhaps just # sh MAKEDEV audio0. If you'd like to step back and start over, that would be one thing to try. There's not much more I (or anyone, really) can do for you until you figure out how to post your dmesg(8).

[bradley]

As a sidenote I had similar issues with audio like in the OP.

It turned out that the soundcard wasn't plugged in properly. It was a simple hardware issue. After taking it out and using it again everything was all right.