__/ [ Larry Qualig ] on Saturday 11 March 2006 03:52 \__
> TheLetterK wrote:
>> Well, since t would be best to avoid feeding the troll... Would anyone
>> like to have an intelligent discussion about Linux's low-latency audio
>> capabilities, as they relate to that available on Windows?
> My computing audio needs are fairly simple but I'm no slouch when it
> comes to audio equipment. In computers latency is like a "big balloon"
> in that if you take your finger and poke somewhere, the rest of the
> balloon needs to take up the difference. Same with latency, if you
> decrease the latency (ie. response time) of audio then the response
> time (latency) of something else is going to increase.
But why miss the point that latency was too high in previous (and current)
versions of Windows? While Microsoft boast a 'feature' in Vista, I call it a
bugfix. Small things matter.
> The goal isn't to get latency to zero because that simply will never
> happen. Most people can't hear or perceive latency that's less than
> 1/8th of a second anyway. (Many claim they detect <1/8th second latency
> can but most simply can't. It's like the guy who can claims to hear
> 16khz tones.)
I think you are justifying to self here. You can't get 0 latency (duh!), but
approaching it while not entailing a performance penalty is more than
> When it comes to latency buffers are the double-edged sword. A large
> buffer makes CPU usage more efficient in that the CPU writes a whole
> bunch of data to the buffer than goes away. The problem with a large
> buffer is that all this buffered data is what's creating the latency in
> the first place. Minimum latency is achieved when there is no (or
> absolutely minimal) buffering. The CPU would write the audio data as
> soon as it was available. Problem here is that it takes many, many,
> many interrupts in order to do this and the OS would have to do it
> pretty darn fast. If the OS doesn't respond fast enough you get
> momentary pauses and clicks in the audio and neither Windows or Linux
> was ever intended to be a real-time OS.
A good start would be to trim the bloat off the operating system. Windows is
always busy doing *something.* My system monitor in Linux indicates that the
CPU is purely idle (memory is static too) unless I do something particular.
I am very well-aware of this because all my panels are automatically hidden
while the only thing visible (apart from the Desktop/wallpaper, which has no
items on it) is the system monitor and the pager. 'Tune in' to your system
and you will notice the same thing. Fan burnouts are more of a Windows
issue, for a reason.
> The best solution IMO is to make extremely smart audio cards. Throw a
> dedicated processor on these audio cards and perhaps some DSP
> capabilities. The micro-OS that runs on these cards would be capable of
> real-time interrupt handling so it could work with small buffer
> (==short latency). The software running on the main OS (Linux, Windows,
> OSX, <whatever>) would essentially 'program' the processor/DSP on the
> audio card as needed. Once programmed, the card would handle nearly all
> of the audio with minimal intervention from the host computer.
That's already being done. Ethernet takes a similar approach.
> Bottom line is that I don't believe a general purpose OS like
> Linux/Win/OSX is ever going to get latency down to a level that serious
> musicians need. The best alternative is to offload this onto
> specialized hardware that is built specifically for this. Then use the
> host computer to program/configure this hardware as needed but have all
> of the actual processing done on the dedicated card.
While we're on the subject of media latency in Linux, check out this shiny
new Linux-based device, which has just been unveiled:
[ Linux PMP boasts impressive playback times ]
Makes you wonder why they picked Linux, doesn't it?
Roy S. Schestowitz | Windows XP: Dude, where's my RAM?
http://Schestowitz.com | SuSE Linux | PGP-Key: 0x74572E8E
4:20am up 2 days 20:57, 7 users, load average: 0.27, 0.61, 0.67
http://iuron.com - Open Source knowledge engine project