[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: audio panic
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:
> 116 u_int usrbuf_usedhigh;/* high water mark in bytes */
> but usrbuf_usedhigh is used as if it is measured in frames?
> 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.
> 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.
Tetsuya Isaki <isaki%pastel-flower.jp@localhost / isaki%NetBSD.org@localhost>
Main Index |
Thread Index |