Re: [proaudio] Real-Time for audio playback? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/proaudio Archives
]
- To: proaudio@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [proaudio] Real-Time for audio playback?
- From: Grant <emailgrant@xxxxxxxxx>
- Date: Sun, 24 Jan 2010 07:14:41 -0800
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=DsZ8CIP+B0eTX4T+PKO9PLX6dwOSo3pcd6vJN2Pwp2M=; b=qfLN60Uxx5z4i7PMRTEqe8i0bpR6dMwsmEl0O3mZ8OwibNyddbwf8w81MKsU1wRVSU cgNRpx7gR79MGArXbBg9wvXHYzjhjykGtZ4Zk6U14TnT4CCBjHYUErdl2fQtHJsvPMyF HF6rxHqE2v9FYeo3h5v6v6tdwB6DAnVLoWPm0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=AD6fewIG3AkKWJyKnhLV1V85YBn5mFndIyvaVnMj8CIIotkzhIF6Fn5HvzH+DSdfrO gmdvAUCY5mEns6Hvu/jEvG7CmaQ0QN4L1E2Ew7Xxj6i+/JG5QsOlg2S0JZk8B8NkxDA7 3TL2i4sIIGAQG1uTcBd3mQVWUvYjKhd4H026E=
> <SNIP>
>>
>> But in the end, there's really no way to know, right? From what I
>> gather, jack can add another buffer and report on it, but it's the
>> sound card buffer that determines whether there are problems or not,
>> right?
>
> No, I think Jack does know.
>
> In non-Jack apps the application pumps out data. If the buffers
> overflow or run empty it's just a 'system problem' and the system has
> failed.
>
> In Jack apps all audio is moved by Jack. All Jack apps are callback
> based. Jack itself issues a demand for data from the application, then
> if the application supplies it then everything works correctly. If the
> app doesn't supply the data then we know where the problem is and we
> can fix it.
Here's how I understand it. In a system without jack, there is
communication between the system and the sound card. With jack, there
is communication between the system and jack, and also between jack
and the sound card. It sounds like jack can report on problems with
communication between the system and jack, but we are still left in
the dark as far as communication problems between jack and the sound
card.
> Note that the above description says nothing about real-time. It works
> whether we are doing real-time audio or not. Without a real-time
> kernel we just increase our latency to cover the extra latency in the
> non-rt kernel, drivers and other apps. None the less it works and if
> it fails then we still know where the problem lies.
>
>>
>> I suppose using jack and real-time gives you extra assurance that the
>> sound card buffer is being served as necessary. Using jack without
>> real-time wouldn't provide any more assurance than a setup without
>> jack, would it?
>
> No more assurance (as I understand it) but much more knowledge about
> where the problem lies...
>
> You may not feel a need to use Jack but I wonder if you've had a
> chance to look over the Jack website as it has better info than I can
> provide. Paul's original slides are a good place to start:
>
> http://jackaudio.org/documentation
>
> You may not have considered this yet but using a non-rt kernel and
> doing things like context switches, dropping out of and coming back
> into Xorg, working with Wine, and other things, can cause huge 1-time
> latencies. In the old days these were huge. Today they are not so bad,
> and our machines are faster, so you don't see as many problems, but
> technically they still exist.
>
> In case there's any question there are more than enough Jack
> applications to satisfy most any need:
>
> http://jackaudio.org/applications
>
> And one last point - Jack won't save you from a total system hardware
> failure. My main AMD64 Gentoo machine that has run rt-kernels and
> sub-1mS latency for over 5 years went up in smoke last week. I wish
> Jack could have told me that problem was coming... ;-)
Was it the Asus motherboard? Did it take anything else out with it?
- Grant