diff options
| author | isaki <isaki@NetBSD.org> | 2022-04-20 06:05:22 +0000 |
|---|---|---|
| committer | isaki <isaki@NetBSD.org> | 2022-04-20 06:05:22 +0000 |
| commit | 3619e2342119c11400be1796503ce6eb927b2ed4 (patch) | |
| tree | 335b7c5df03c49b2e27fd3e3d239cdffbc4fe371 /sys/dev/microcode/typhoon | |
| parent | 6f7c89164d84bbeb60e07c3dae470b6da4c7598b (diff) | |
audio(4): Make recording buffer more robust.
Previously, main buffer in recording track was usrbuf, which is the closest
buffer to the userland. Because, this buffer arrangement was symmetrical
with the playback track, and had affinity with the past implementation.
However, in the current implementation, read(2) (from user application)
takes recorded block out from inputbuf, which is the closest buffer to
rmixer, to usrbuf. So it was not good way to use the usrbuf as main buffer.
Now, usrbuf in recording track holds only fragment bytes in order to
transfer to the userland, and main buffer in recording track is the inputbuf,
the closest to rmixer.
Buffer size of the inputbuf is also modified. Previously, it was less than
64KB or at least 4 blocks. This had affinity with playback track and the
past implementation. But this was not appropriate for both formats with
too large frames or too small frames. In large frames (for example,
192kHz/12ch), 184KB buffer would be allocated but it corresponds to only
40msec. In opposite, in small frames (for example, 8000Hz/1ch), 64KB
buffer would be allocated and it corresponds to 4.1 seconds. But for such
machines that have 8000Hz/1ch device, in-kernel 64KB memory would probably
be expensive.
Now, inputbuf will always be allocated 16(NBLKIN) blocks, regardless of its
hardware format. It corresponds to 160msec on modern archs (if blk_ms=10),
or 640msec on antique archs (if blk_ms=40).
Diffstat (limited to 'sys/dev/microcode/typhoon')
0 files changed, 0 insertions, 0 deletions
