Hello, There's been quite some work on streaming audio and improving mixfs performance lately. I've always had problems with mixfs, but unsure what to do about them. Important note: my main computer is still a t61p, much slower than x220 and higher. There are relatively frequent stutters and underruns, esp. when the system is under heavier load. So far the best "fix" I found was to readjust buffer size and delay. I'm not sure whether this fixes the underlying issue or just a symptom though. The patch below aligns NDELAY and NBUF to the default delay (1764), and significantly improves performance, on intel hda at least, on my machines. What do you think? Does this make sense? Thanks, qwx diff 744053268d196e8c282d20243600fb33d4df0028 uncommitted --- a/sys/src/cmd/audio/mixfs/mixfs.c +++ b/sys/src/cmd/audio/mixfs/mixfs.c @@ -5,10 +5,10 @@ #include <9p.h> enum { - NBUF = 8*1024, - NDELAY = 2048, NCHAN = 2, FREQ = 44100, + NDELAY = FREQ / 25, + NBUF = NDELAY, }; typedef struct Stream Stream;
Have you tried adjusting hda's delay instead?
Oops, replied off-list, sorry.
--
On Tue Dec 6 02:42:40 +0100 2022, sigrid@ftrv.se wrote:
> Have you tried adjusting hda's delay instead?
Yes, I've tried increasing it to 2048, 3528, and higher with latest
unmodified mixfs, while saturating load and having 3-4 concurrent
writers. At 3528 and more, performance seems to drop (but would need
more testing), but latency starts to get high. 2048 improves
performance to similar levels as the patch, but the patch seems to
help slightly more. It's harder to tell, I'm not sure how to test
this in a reproducible manner.
On Tue Dec 6 03:11:51 +0100 2022, sigrid@ftrv.se wrote:
> Maybe setting pri 13 or something on mixfs? NOTE: am just mashing imaginary keys here, obviously.
No, doesn't change anything so far as I can tell. play(1) and my
pplay(1) set pri 13 on themselves, I don't know that that helps here
either.
In any case the difference with and without mixfs on my system are
staggering :/