On Thu, Feb 27, 2014 at 09:31:03AM +0100, Jan Stary wrote: > On current/amd64 (dmesg below) > when playing mp3 audio with mplayer, > I am getting > > Audio device got stuck! > > when I simultaneously run a TeX compilation > in another window of a console tmux session. > Or when running a pkg_add. > > I don't know if it's the TeX compilation itself > (as a burden on the system as a whole?) > or the console activity associated with it. > > Similar thing happens with sox playing: > it either dies or stutters terribly > (even after the TeX compilation and its > console output are finished). > > I am sending this to ports@ but I think > it is something in the audio subsystem itself > rather than with any particular port. > > Googling around, I see that this is probably > the same problem I had a year ago > http://marc.info/?l=openbsd-ports&m=136412452920733&w=2 > when it was suggested I run a SP kernel. > Indeed, that makes the problem disappear. > > I still wonder what the root cause is: > - the console slowing things down?
Are you using X? If not, I recommend using it (sorry), because the console uses CPU intensive kernel code, while X runs mostly in user mode. > - proper audio MP lock latency missing in the kernel? Last time I checked interrupts are still not reliable on MP systems, I recommend using the SP kernel if reliable audio is required. > - a bug in uaudio (as suggested by ratchov)? > > People are seeing this on other systems too > http://marc.info/?l=mplayer-users&m=132924198807532&w=2 You could start sndiod with -dd and see if complains -- Alexandre
