lkml.org 
[lkml]   [1999]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Reason for sound dropouts found
Date
From
>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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.401 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site