[linux-audio-dev] 32/96 x 24 playback improvements, I think

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] 32/96 x 24 playback improvements, I think
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke helmi  02 2000 - 00:09:42 EST


re: simultaneous recording of 24 tracks of 32 bit/96kHz audio

well, i did a bunch of experiments and got some helpful mail from
other people. i have a solution that it not totally finished yet, but
feels more "right" than others i have tried or read about. i hope
nobody minds if i describe it briefly here, if only to put in the
public domain if it isn't already there :)

I've stayed with non-interleaved data. Roger Wolff made the
*extremely* important point that its hard to add per-track offsets if
the data is interleaved. Having heard from music friends how important
and useful this can be, it would be crazy to make it hard.

On the face of it, I buffer 1 seconds worth of audio during
playback. However, the big mistake that I was making before was
reading from the disk in the same size chunks as I would write to the
Hammerfall (between 4K and 32K). Thats a mistake because you end up
with a lot more seeks than necessary, and you don't get the benefit of
amortizing the overhead of a disk read over a lot of data. So now, I
read the whole 1s in a single read(2) call. I then use double
buffering, so that I always (well, hopefully always) have (at least) a
full 1sec ready to playback. We refill each buffer "half" whenever the
read ptr cross the division between them (or reaches the end).

In addition, I use 1 thread per track. Why so many threads ? Because
then we can get maximum I/O asynchronicity - we just issue a read(2)
in each thread, then it blocks in the kernel, and doesn't wake up till
the read is done, at which point it touches a couple of variables for
the track, and goes to sleep until we wake it up again. This lets us
work the disk driver as hard as possible - if we use only 1 thread for
all the tracks combined, that thread will block on each read, and we
effectively serialize the disk access even before the disk driver gets
a chance to do this itself (and it will do a better job than us).

there are still some issues to work out, but this certainly works very
nicely with 170ms of h/w buffering. i think i need to check the
granularity of my thread locks, because at 85ms of h/w buffering, i
still get audio underruns during playback. the transport controls work
in a way that is closer to my goals, but there is some work to be done
there too.

basically, i just have a gut feeling that this is a good approach that
can be adjusted and tuned properly. if anyone has any thoughts, please
let me know.

i have also wondered about the wisdom of copying all 32 bits that i
get from the hammerfall when we only need 24 - it adds 33% more
data. however, the coversion cost is not trivial either, so at some
point, i will need to measure this and figure out what makes more sense.

--p


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:27 EST