Messages in this thread | | | Subject | Re: Reason for sound dropouts found | Date | Fri, 12 Mar 1999 11:42:01 -0500 | From | Paul Barton-Davis <> |
| |
>From: Richard Gooch <rgooch@atnf.csiro.au> >Date: Fri, 12 Mar 1999 20:48:36 +1100 >Subject: Re: Reason for sound dropouts found > >T. Mertes writes: >> 2. Every program to play sound should have two threads >> for reading and writing and an internal buffer which never >> gets empty so that after finishing one write() to the >> sound device the next write() can start immidiate without >> delay. --> no dropout >> This could be done also by a sound demon used by all >> sound programms. When this user buffer swaps out, >> you get your dropouts aggain. >I think (2) is the only reasonable solution. It's really easy to solve >this in user space. No reason to allocate huge kernel buffers (3) >which consume RAM. The alternative of (1) has the disadvantage that >you can end up reading stuff that isn't needed, which just delays when >important (required) data can be read. > >Check out bplay: it allocates a SHM segment and uses two >processes. It's a bit ugly, as it doesn't use threads, but it >works. There is a variant called tplay which uses threads instead >which is probably better.
Sorry, wrong answer. This works only for applications which are playing pre-generated sound or have no latency concerns.
If you want low latency for real-time events that will alter the sound output in some way, this prevents you from writing ahead more than a small number of samples. A user-level software synth that wants to handle MIDI input wants at most 2ms of latency. At a 48KHz sample rate, thats only a few thousand samples.
Most disk I/O based dropouts are significantly longer than 2ms.
The only working solution to this problem right now is to use an SMP machine. It would be nice if Linux could solve it more generally, but as many people, including myself, have pointed out, a multi-user, multi-tasking operating system and real-time sound synthesis are not the most obvious bedfellows, and its a testament to Linux that one can do as much with it as we currently can.
--p (currently doing a *lot* with it)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |