Re: audio panic

[Tetsuya Isaki <isaki%pastel-flower.jp@localhost>]

At Wed, 6 Nov 2019 10:17:12 +0200,
Yorick Hardy wrote:
> > I should be able to try get it to happen again tomorrow (I managed
> > to trigger the panic on my work computer only so far). The offending
> > command is:
> > 
> >  ffplay4 -hide_banner -showmode waves -f oss /dev/audio
:
> I have not been able to reproduce this yet (I am using the fixed libossaudio;
> I will have to try go back to see if I can trigger the crash with the unfixed
> version -- I tried to write a small program to reproduce the problem but it
> works without fail).
> 
> I have been reading the code around the crash a bit, and I have a question:
> 
>  https://nxr.netbsd.org/xref/src/sys/dev/audio/audiodef.h#116
> 
>  116         u_int           usrbuf_usedhigh;/* high water mark in bytes */
> 
> but usrbuf_usedhigh is used as if it is measured in frames?
> 
>  https://nxr.netbsd.org/xref/src/sys/dev/audio/audio.c#4501
> 
>  4500         count = uimin(count,
>  4501             (track->usrbuf_usedhigh - usrbuf->used) / framesize);
>  4502         bytes = count * framesize;

I think it's no problem.
track->usrbuf_usedhigh and usrbuf->used are counted as byte.
So (track->usrbuf_usedhigh - usrbuf->used) is also byte.  Then
((track->usrbuf_usedhigh - usrbuf->used) / framesize) is frame.

>  https://nxr.netbsd.org/xref/src/sys/dev/audio/audio.c#4521
>  https://nxr.netbsd.org/xref/src/sys/dev/audio/audio.c#4525
> 
>  4521                 bytes2 = bytes - bytes1;
>  4525                 auring_push(usrbuf, bytes2);
>  
> does not check whether bytes2 is small enough? (The panic happened when
> the software was consuming audio at a much lower rate than it asked for.)

Unfortunately this assumption is not correct, but your comment gave
me a hint! (thank you).  Please test sys/dev/audio/audio.c,v 1.33.

lib/54667 problem makes confusing situation between userland and the
kernel.  That is, the kernel reads with 48000Hz from HW but userland
app reads with 8000Hz from the kernel in this case.  It causes
recording buffer to stuck.  But normally it should not panic.  Because
it's just a stuck.

audio.c < 1.33 mis-calculated the ring buffer.  It panics when the ring
buffer is stuck.  This is what you saw.

Thanks,
---
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>