Re: azalia audio works, then stutters until reboot
[I see I sent with too-long lines by mistake; sorry; resending with that corrected.] On 11/23/15 05:11, Alexandre Ratchov wrote: On Fri, Nov 20, 2015 at 10:31:34AM -0700, luke...@onemodel.org wrote: Could the root umask of 0077 be a problem? my /tmp/aucat directory has different permissions than yours. The problem is in sndiod; it's supposed create a world readable directory regardless the user umask. I just commited the fix; you could either start it with the 022 umask now or rebuild sndiod with sndiod.c rev 1.14 or newer. Let me know if things work better. Thanks. Now sndiod -ddd log output is more like what you were looking for. Would it be good for sndiod to complain more verbosely when that problem occurs (ie, in a way that's easier to diagnose such an issue in the future)? I set that umask for all users to avoid forgetfully bleeding information between accounts. Another option is to create the home directories with mode 0700 and leave the default umask. This doesn't protect files outside their home dir, but I'm not sure this would be a problem. Would the 0077 umask simply be a better default for the OS? I haven't checked historical discussions behind that yet, but on the surface it seems better to me. Some issues would have to be addressed in packages. Or is that a question I should ask in a separate thread? Now, having changed that permission, and restarted sndiod to get the log output, I duplicated your earlier diagnostic tips with aucat, then played part of a .mid file with timidity, no problems to there, all showing in the log, then started a video in smplayer (now under a different account, via ssh -X), jumping forward/backward with L/R arrow keys, and then adjusting the volume using the xfce applet, which finally duplicated the stuttering sound problem. /tmp#la aucat/ total 24 srw-rw-rw- 1 root wheel 0 Nov 23 08:26 aucat0 drwxr-xr-x 2 root wheel 512 Nov 23 08:26 . drwxrwxrwt 30 root wheel 7168 Nov 23 08:46 .. Does the log show anything useful about what might cause the stuttering or what I could do for more info? I posted the new log at: ftp://onemodel.org/sndiod2.log Thanks again. -- Luke A. Call -- Things I'd like to say to more people: http://www.onemodel.org/1/e-9223372036854618449.html
Re: azalia audio works, then stutters until reboot
On Fri, Nov 20, 2015 at 10:31:34AM -0700, luke...@onemodel.org wrote: > > $ls -ltrd /tmp/aucat > drwx-- 2 root wheel 512B Nov 20 09:39 /tmp/aucat/ > $ls -ltr /tmp/aucat > ls: aucat: Permission denied > [and timidity playing a .mid file was working] > [then i killed sndiod with ^C.] > > Could the root umask of 0077 be a problem? my /tmp/aucat directory > has different permissions than yours. The problem is in sndiod; it's supposed create a world readable directory regardless the user umask. I just commited the fix; you could either start it with the 022 umask now or rebuild sndiod with sndiod.c rev 1.14 or newer. Let me know if things work better. > I set that umask for all > users to avoid forgetfully > bleeding information between accounts. Another option is to create the home directories with mode 0700 and leave the default umask. This doesn't protect files outside their home dir, but I'm not sure this would be a problem.
Re: azalia audio works, then stutters until reboot
On 11/23/15 05:11, Alexandre Ratchov wrote: On Fri, Nov 20, 2015 at 10:31:34AM -0700, luke...@onemodel.org wrote: Could the root umask of 0077 be a problem? my /tmp/aucat directory has different permissions than yours. The problem is in sndiod; it's supposed create a world readable directory regardless the user umask. I just commited the fix; you could either start it with the 022 umask now or rebuild sndiod with sndiod.c rev 1.14 or newer. Let me know if things work better. Thanks. Now sndiod -ddd log output is more like what you were looking for. Would it be good for sndiod to complain more verbosely when that problem occurs (ie, in a way that's easier to diagnose such an issue in the future)? I set that umask for all users to avoid forgetfully bleeding information between accounts. Another option is to create the home directories with mode 0700 and leave the default umask. This doesn't protect files outside their home dir, but I'm not sure this would be a problem. Would the 0077 umask simply be a better default for the OS? I haven't checked historical discussions behind that yet, but on the surface it seems better to me. Some issues would have to be addressed in packages. Or is that a question I should ask in a separate thread? Now, having changed that permission, and restarted sndiod to get the log output, I duplicated your earlier diagnostic tips with aucat, then played part of a .mid file with timidity, no problems to there, all showing in the log, then started a video in smplayer (now under a different account, via ssh -X), jumping forward/backward with L/R arrow keys, and then adjusting the volume using the xfce applet, which finally duplicated the stuttering sound problem. /tmp#la aucat/ total 24 srw-rw-rw- 1 root wheel 0 Nov 23 08:26 aucat0 drwxr-xr-x 2 root wheel 512 Nov 23 08:26 . drwxrwxrwt 30 root wheel 7168 Nov 23 08:46 .. Does the log show anything useful about what might cause the stuttering or what I could do for more info? I posted the new log at: ftp://onemodel.org/sndiod2.log Thanks again, Luke
Re: azalia audio works, then stutters until reboot
On 11/20/15 02:12, Alexandre Ratchov wrote: On Thu, Nov 19, 2015 at 12:48:08PM -0700, luke call wrote: $cat sndiod-log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created this is very strange, sndiod would have logged all the audio traffic. Could you check that this is the right file or that programs are not bypassing sndiod for any reason ? It's the right file, or at least it was created at that time, evidently as a direct result of the -ddd switch. I'm not aware of what else could have created it. Could sndiod have got into a state where it quits logging (maybe somehow related to the audio looping w/ the same beep for a long time)? Or, needs a poke to flush a log buffer to disk? or more -d's? Is the error message from timidity (midi-playing client) relevant?: io_open() failed Couldn't open sndio mode (`s') How would I determine if something bypasses sndiod? E.g., would some other client program give more helpful info, at least about what it's trying to do and how it's trying it, like aucat or something? Should I be running something akin to linux's strace to really dig at some angle? (I'm not remembering the openbsd equivalent.) the surprising part is the length of the sndiod-log file. You could try to start sndiod in one window: doas pkill sndiod doas sndiod -ddd then play silence with aucat in another window: aucat -i /dev/zero you should see a lot of messages output by sndiod: snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created ignored huge clock delta sock(sock|ini): created sock,rmsg,widl: AUTH message sock,rmsg,widl: HELLO message sock,rmsg,widl: hello from , mode = 1, ver 7 sock,rmsg,widl: using snd0 pst=cfg.default, mode = 1 aucat0: overwritten slot 0 snd0 pst=cfg: device requested sio(rsnd/0|ini): created snd0 pst=ini: 48000Hz, s16le, play 0:1, rec 0:1, 8 blocks of 960 frames ... ... they indicate whan aucat is doing with the sound device. If I run timidity, I get similar messages. I'll look at what timidity does; meanwhile could you try to make programs not bypass sndiod? This could be caused by, an AUDIODEVICE environment variable, or deleted /tmp/aucat/ directory (or bad permissions) or multiple sndiod processes running on my machine: $ pgrep -x sndiod 7941 $ /bin/ls -al /tmp/aucat/ total 8 drwxr-xr-x 2 root wheel 512 Nov 20 10:08 . drwxrwxrwt 8 root wheel 512 Nov 20 10:03 .. srw-rw-rw- 1 root wheel0 Nov 20 10:08 aucat0 and I've no AUDIODEVICE environment variable. Could there some timidity configuration files or environment variables that force tell it to bypass sndiod. Here's what I get. This output shows the switching between the two users (root and a regular user) who are running the commands: #pkill sndiod #sndiod -ddd 2>&1 | tee /tmp/sndiod.log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created [and that's all until i killed it after doing the next audio cmds as other user] $aucat -i /dev/zero [wait several seconds] ^C $echo $AUDIODEVICE $ls -ltrd /tmp/aucat drwx-- 2 root wheel 512B Nov 20 09:39 /tmp/aucat/ $ls -ltr /tmp/aucat ls: aucat: Permission denied [and timidity playing a .mid file was working] [then i killed sndiod with ^C.] #ls -ltr /tmp/aucat total 0 srw-rw-rw- 1 root wheel 0 Nov 20 09:39 aucat0 #ls -ltrd /tmp/aucat drwx-- 2 root wheel 512 Nov 20 09:39 /tmp/aucat #ps aux|grep -i sndiod root 22835 0.0 0.0 304 704 p1 R+ 9:47AM0:00.00 grep -i sndiod #umask 0077 #sndiod -ddd 2>&1 | tee /tmp/sndiod.log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created ^Z [1]+ Stopped sndiod -ddd 2>&1 | tee /tmp/sndiod.log #bg [1]+ sndiod -ddd 2>&1 | tee /tmp/sndiod.log & #ps aux|grep -i sndiod _sndio 30197 0.0 0.0 416 1368 p1 S< 9:52AM0:00.00 sndiod -ddd #ktrace -aid -p 30197 #echo $? 0 #l *out -rw--- 1 root wheel 63.1K Nov 20 09:53 ktrace.out $aucat -i /dev/zero [wait several seconds.] ^C $timidity *mid Playing aislean.mid MIDI file: aislean.mid Format: 1 Tracks: 3 Divisions: 240 ^CTerminated sig=0x02 [the above cmd did play music] #ktrace -C #l *out -rw--- 1 root wheel 63.1K Nov 20 09:53 ktrace.out #l /tmp/*log -rw--- 1 root wheel92B Nov 20 09:53 /tmp/sndiod.log #cat /tmp/*log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created # Could the root umask of 0077 be a problem? my /tmp/aucat directory has different permissions than yours. I set that umask for all users to avoid forgetfully bleeding information between accounts. (I've found that the umask cannot have that restrictive setting for reliably running pkg_add, so I have a script that sets it back to the default for that purpose when needed, though it seems like it would be better for packages to reliably set the permissions they need and not depend on the root
Re: azalia audio works, then stutters until reboot
$cat sndiod-log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created this is very strange, sndiod would have logged all the audio traffic. Could you check that this is the right file or that programs are not bypassing sndiod for any reason ? It's the right file, or at least it was created at that time, evidently as a direct result of the -ddd switch. I'm not aware of what else could have created it. Could sndiod have got into a state where it quits logging (maybe somehow related to the audio looping w/ the same beep for a long time)? Or, needs a poke to flush a log buffer to disk? or more -d's? Is the error message from timidity (midi-playing client) relevant?: io_open() failed Couldn't open sndio mode (`s') How would I determine if something bypasses sndiod? E.g., would some other client program give more helpful info, at least about what it's trying to do and how it's trying it, like aucat or something? Should I be running something akin to linux's strace to really dig at some angle? (I'm not remembering the openbsd equivalent.) It is highly possible that I'm doing something stupid, and just not seeing it or something else obvious, yet. Thanks much for the help. -Luke
Re: azalia audio works, then stutters until reboot
[sorry for the dupe; correcting the 'from' address.] On 11/07/15 04:20, Alexandre Ratchov wrote: On Fri, Nov 06, 2015 at 05:00:13PM -0700, luke...@onemodel.org wrote: On 09/11/15 11:55, luke...@onemodel.org wrote: [...details are found in original thread at: http://marc.info/?l=openbsd-misc=144199440202788=2 ] Is there other info I can provide, or something I should try? you could try to kill sndiod and run as root: sndiod -ddd 2>/tmp/sndiod-log ... (audioctl ; sleep 1 ; audioctl) >/tmp/audioctl-log and send me both files. Or at least last few megs if the file is huge. Since the problem was already occurring I can provide that now. I killed/restareted sndiod as described, attempted to run "timidity *.mid", but instead of the error output I described earlier it just produced repeated chimes (ie, the audible symptoms of the problem). Then doing this as root: (audioctl ; sleep 1 ; audioctl) >/tmp/audioctl-log ...yields the 2nd of the 2 logs pasted below. (But I wonder if I did things in a way that makes them informative enough, or if the problem needs to be absent when I start the "sndiod..." command, and begin while that is in debug mode, or anything.) -Luke $cat sndiod-log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created $cat audioctl-log name=HD-Audio encodings=slinear_le:16:2:1,slinear_le:20:4:1,slinear_le:24:4:1 properties=full_duplex,independent hiwat=2 lowat=2 mode= play.rate=44100 play.channels=2 play.precision=16 play.bps=2 play.msb=1 play.encoding=slinear_le play.pause=0 play.active=0 play.block_size=17664 play.bytes=0 play.errors=0 record.rate=44100 record.channels=2 record.precision=16 record.bps=2 record.msb=1 record.encoding=slinear_le record.pause=0 record.active=0 record.block_size=17664 record.bytes=0 record.errors=0 name=HD-Audio encodings=slinear_le:16:2:1,slinear_le:20:4:1,slinear_le:24:4:1 properties=full_duplex,independent hiwat=2 lowat=2 mode= play.rate=44100 play.channels=2 play.precision=16 play.bps=2 play.msb=1 play.encoding=slinear_le play.pause=0 play.active=0 play.block_size=17664 play.bytes=0 play.errors=0 record.rate=44100 record.channels=2 record.precision=16 record.bps=2 record.msb=1 record.encoding=slinear_le record.pause=0 record.active=0 record.block_size=17664 record.bytes=0 record.errors=0 -- Luke A. Call -- Things I'd like to say to more people: http://www.onemodel.org/1/e-9223372036854618449.html
Re: azalia audio works, then stutters until reboot
On Fri, Nov 06, 2015 at 05:00:13PM -0700, luke...@onemodel.org wrote: > On 09/11/15 11:55, luke...@onemodel.org wrote: > >Short version: In OpenBSD 5.7 (with all the latest security > >patches), after some video playing, it > >starts to stutter, and doesn't recover until I reboot. Is there > >a way to "reset all the audio" back so it works, short of rebooting? > >I haven't found that in anything I've read so far, including from > >faq 13 and manpages for audioctl and mixerctl etc. > > > >The details: > [...are found in original thread at: > http://marc.info/?l=openbsd-misc=144199440202788=2 > ] > > > I upgraded to 5.8 as advised in the earlier thread, and the > problem is definitely much reduced, but still happens occasionally. The 5.8 audio driver was rewritten from scratch so the behavior may be slightly different > It seems to be mostly after I use the xfce volume control slider > (ie the audio mixer panel plugin). It usually doesn't have any > problem if I move around in the video, change the volume via the > slider inside the video area in the browser, or if I use the computer > for something else, but did fail just now when I tried to watch a 2nd > video via a link. > > I confirmed that, as described before IIRC, when the problem > occurs with symptoms in chrome, and I try to use timidity to > play a .mid file, I get this output from timidity: > io_open() failed > Couldn't open sndio mode (`s') > > Is there other info I can provide, or something I should try? > you could try to kill sndiod and run as root: sndiod -ddd 2>/tmp/sndiod-log Possibly use tmux to avoid closing the window by mistake. Then, do your usual stuff and whenever you see the failure, run: (audioctl ; sleep 1 ; audioctl) >/tmp/audioctl-log and send me both files. Or at least last few megs if the file is huge. This may reveal what's the state of the audio subsystem during the failure. thanks -- Alexandre
Re: azalia audio works, then stutters until reboot
On Sat, Nov 07, 2015 at 06:27:17AM -0700, luke...@onemodel.org wrote: > [sorry for the dupe; correcting the 'from' address.] > > On 11/07/15 04:20, Alexandre Ratchov wrote: > >On Fri, Nov 06, 2015 at 05:00:13PM -0700, luke...@onemodel.org wrote: > >>On 09/11/15 11:55, luke...@onemodel.org wrote: > >>[...details are found in original thread at: > >> http://marc.info/?l=openbsd-misc=144199440202788=2 > >>] > >>Is there other info I can provide, or something I should try? > >> > >you could try to kill sndiod and run as root: > > > >sndiod -ddd 2>/tmp/sndiod-log > >... > >(audioctl ; sleep 1 ; audioctl) >/tmp/audioctl-log > > > >and send me both files. Or at least last few megs if the file is > >huge. > > Since the problem was already occurring I can provide that now. I > killed/restareted sndiod as described, attempted to run "timidity > *.mid", but instead of the error output I described earlier it just > produced repeated chimes (ie, the audible symptoms of the problem). > > Then doing this as root: > (audioctl ; sleep 1 ; audioctl) >/tmp/audioctl-log > ...yields the 2nd of the 2 logs pasted below. (But I wonder > if I did things in a way > that makes them informative enough, or if the problem needs > to be absent when I start the "sndiod..." command, and begin > while that is in debug mode, or anything.) sorry, forgot to mention it; please restart sndiod first; this way all the operations that lead to the bug are logged. Then, right after the failure, run the audioctl commands. thanks
Re: azalia audio works, then stutters until reboot
On 11/07/15 12:21, Alexandre Ratchov wrote: sorry, forgot to mention it; please restart sndiod first; this way all the operations that lead to the bug are logged. Then, right after the failure, run the audioctl commands. I rebooted, restarted sndiod -ddd..., sound working with timidity, volume changes caused no problem, started a video in chrome, sound working, stopped it, changed volume (cycled that a few times until) sound not working in chrome (nor timidity: "...Couldn't open sndio..." as before), ran the audioctl line, and the below logs resulted. Is there anything more informative I should do? would sndiod necessarily have flushed its logs after several minutes? I double-checked that there were 3 "d"'s in the sndiod command. Also, do I understand correctly that the only way to return to a working state (currently known) is to reboot? (Cue Fats Domino, "ain't that a shame..." :) but i understand and am grateful it works at all, and for the help.) Thanks! $cat sndiod-log snd0 pst=cfg.default: rec=0:1 play=0:1 vol=23170 dup listen(/tmp/aucat/aucat0|ini): created $cat audioctl-log name=HD-Audio encodings=slinear_le:16:2:1,slinear_le:20:4:1,slinear_le:24:4:1 properties=full_duplex,independent hiwat=2 lowat=2 mode=play play.rate=48000 play.channels=2 play.precision=16 play.bps=2 play.msb=1 play.encoding=slinear_le play.pause=0 play.active=1 play.block_size=4096 play.bytes=2998272 play.errors=0 record.rate=48000 record.channels=2 record.precision=16 record.bps=2 record.msb=1 record.encoding=slinear_le record.pause=0 record.active=1 record.block_size=4096 record.bytes=0 record.errors=0 name=HD-Audio encodings=slinear_le:16:2:1,slinear_le:20:4:1,slinear_le:24:4:1 properties=full_duplex,independent hiwat=2 lowat=2 mode=play play.rate=48000 play.channels=2 play.precision=16 play.bps=2 play.msb=1 play.encoding=slinear_le play.pause=0 play.active=1 play.block_size=4096 play.bytes=2998272 play.errors=0 record.rate=48000 record.channels=2 record.precision=16 record.bps=2 record.msb=1 record.encoding=slinear_le record.pause=0 record.active=1 record.block_size=4096 record.bytes=0 record.errors=0
Re: azalia audio works, then stutters until reboot
On 09/11/15 11:55, luke...@onemodel.org wrote: Short version: In OpenBSD 5.7 (with all the latest security patches), after some video playing, it starts to stutter, and doesn't recover until I reboot. Is there a way to "reset all the audio" back so it works, short of rebooting? I haven't found that in anything I've read so far, including from faq 13 and manpages for audioctl and mixerctl etc. The details: [...are found in original thread at: http://marc.info/?l=openbsd-misc=144199440202788=2 ] I upgraded to 5.8 as advised in the earlier thread, and the problem is definitely much reduced, but still happens occasionally. It seems to be mostly after I use the xfce volume control slider (ie the audio mixer panel plugin). It usually doesn't have any problem if I move around in the video, change the volume via the slider inside the video area in the browser, or if I use the computer for something else, but did fail just now when I tried to watch a 2nd video via a link. I confirmed that, as described before IIRC, when the problem occurs with symptoms in chrome, and I try to use timidity to play a .mid file, I get this output from timidity: io_open() failed Couldn't open sndio mode (`s') Is there other info I can provide, or something I should try? Thanks! -- Luke A. Call -- Things I'd like to say to more people: http://www.onemodel.org/1/e-9223372036854618449.html
Re: azalia audio works, then stutters until reboot
On 09/12/15 05:25, Alexandre Ratchov wrote: Audio didn't properly recover after missed interrupts (which happens on MP systems). The new audio driver (in 5.8 and -current) is supposed to recover, at least with your hardware. ... I'd suggest trying -current; there's a new audio driver and many audio-related fixes. Furthermore we're not interested in debugging the old code that we already deleted :) Thanks, good to know. I think I'm better suited for "-stable" than for "-current", currently. So I might wait for 5.8's release then upgrade, or I'd have to figure out if it's a supported configuration to be on -current now then switch back to -stable just when 5.8 is released. But is there an easy way to force my audio in 5.7 to stay on a single core or such, if that would help in the meantime? Or any good way to "reset" it at any time, short of rebooting? I'm guessing not on both questions, just confirming... Thanks again, -Luke
Re: azalia audio works, then stutters until reboot
On 09/12/15 17:56, luke...@onemodel.org wrote: Thanks, good to know. I think I'm better suited for "-stable" than for "-current", currently. So I might wait for 5.8's release then upgrade, or I'd have to figure out if it's a supported configuration to be on -current now then switch back to -stable just when 5.8 is released. -current is probably heading towards 5.9 at the moment. Switching back from current to stable isn't a supported option, so you are probably better off waiting for 5.8 release on the 18 Oct 2015 - but if you pre-order from https://www.openbsdstore.com you might get it before the 18 Oct! Cheers Fred
Re: azalia audio works, then stutters until reboot
On Fri, Sep 11, 2015 at 11:55:29AM -0600, luke...@onemodel.org wrote: > Short version: In OpenBSD 5.7 (with all the latest security > patches), after some video playing, it > starts to stutter, and doesn't recover until I reboot. Is there > a way to "reset all the audio" back so it works, short of rebooting? > I haven't found that in anything I've read so far, including from > faq 13 and manpages for audioctl and mixerctl etc. Audio didn't properly recover after missed interrupts (which happens on MP systems). The new audio driver (in 5.8 and -current) is supposed to recover, at least with your hardware. > The only other things other than from the above-linked > thread that I've thought of to try are: > - upgrading to CURRENT to see if it's any different > - debugging (I'd have to learn a lot, best with some guidance) > - discuss & learn more here... I'd suggest trying -current; there's a new audio driver and many audio-related fixes. Furthermore we're not interested in debugging the old code that we already deleted :)
azalia audio works, then stutters until reboot
Short version: In OpenBSD 5.7 (with all the latest security patches), after some video playing, it starts to stutter, and doesn't recover until I reboot. Is there a way to "reset all the audio" back so it works, short of rebooting? I haven't found that in anything I've read so far, including from faq 13 and manpages for audioctl and mixerctl etc. The details: After playing a video in chromium at youtube.com for a while, or an .ogv file in smplayer, the video starts to replay the same ~.3 sec. of audio repeatedly, and the video stops moving forward. If I stop the video, then sometimes after several hours it stops, but the last one didn't stop stuttering even though I let it sit overnight. This then affects all audio, I've tried, even trying to play a beep. Turning mute on/off using the laptop keyboard or jumping around in the video stream (backing up to replay part, for example) seems to usually be when the problem starts. While it is stuttering, running 'audioctl -f /dev/audio0' or trying a .mid file gets output like this: $timidity aislean.mid sio_open() failed Couldn't open sndio mode (`s') ...but after enough time goes by the screen (but not sound) output from those commands is normal again. They work fully before the audio stuttering starts. The related lines from lspci seem to be: 00:01.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Device 1308 00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller (*rev 01) The problems seem similar to those described in this thread: http://marc.info/?l=openbsd-misc=134463946801823=2 ...but a similar (though naive) change to azalia.c didn't fix things for me (basically, instead of adding another case option, I added a "default:" line just after the ones with various ...SERIES constants suggested in the thread; don't laugh too hard: it was just an attempt anyway... :). I haven't tried all the suggestions here in this thread: http://marc.info/?l=openbsd-misc=143160717501387=2 ...partly because I didn't see "-mplay" as an option in the manpage for sndiod, but maybe I missed it or should just try that anyway. If I should also try the debug etc suggestions there for this case, let me know. I did look for audio-related options in the BIOS but there was only one whose name I forget but which is enabled (or "UNLOCK"ed). The only other things other than from the above-linked thread that I've thought of to try are: - upgrading to CURRENT to see if it's any different - debugging (I'd have to learn a lot, best with some guidance) - discuss & learn more here... /var/run/dmesg.boot follows (as the last thing in this msg). (Ps: i don't expect that wifi will work on this laptop hardware--input welcome on that though I realize it's a separate question: I'm curious only if you notice something, but not focused on it now). Thanks! OpenBSD 5.7-stable (GENERIC.MP) #3: Tue Aug 18 16:23:25 MDT 2015 r...@asusbsd.home:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 7443599360 (7098MB) avail mem = 7241527296 (6906MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf90 (49 entries) bios0: vendor American Megatrends Inc. version "204" date 11/20/2014 bios0: ASUSTeK COMPUTER INC. X550ZA acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT ECDT MCFG MSDM HPET UEFI SSDT SSDT CRAT SSDT SSDT SSDT SSDT acpi0: wakeup devices LOM_(S4) SBAZ(S4) ECIR(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) ODD8(S3) GLAN(S4) LID_(S5) SLPB(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.65 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,ITSC,FSGSBASE,BMI1 cpu0: 96KB 64b/line 3-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.0.0.0.0, IBE cpu1 at mainbus0: apid 17 (application processor) cpu1: AMD A10-7400P Radeon R6, 10 Compute Cores 4C+6G, 2495.34 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,NODEID,TBM,ITSC,FSGSBASE,BMI1 cpu1: 96KB
