Re: [proaudio] Real-time for audio

[Gavin Pryke <gavinlee303@xxxxxxxxxxxxxx>]

On Sunday 09 May 2010 15:55:58 Mark Knecht wrote:
> On Sat, May 8, 2010 at 6:31 PM, Grant <emailgrant@xxxxxxxxx> wrote:
> >>>> With a rt kernel, you can setup both the hardware priorities and the
> >>>> software priorities. That mean that tasks accessing some hardware,
> >>>> the sound card, will have the priority over the other tasks, and that
> >>>> tasks executed by a given user or group [the audio group] will have
> >>>> priority over the other. rtirq will dot that for you. Just emerge it
> >>>> and add it into the default run level.
> >>> 
> >>> Is jack necessary for me then?  What I want to do is use my USB DAC
> >>> and mpd (music player app) in real time.  Maybe jack is necessary if I
> >>> want to know *how* real time it is?
> >>> 
> >>>> Be aware that if you don't really need a rt kernel, it is best to not
> >>>> use it, because such a kernel can cause compilation failures with
> >>>> gcc. http://bugs.gentoo.org/show_bug.cgi?id=190462
> >>>> http://bugs.gentoo.org/show_bug.cgi?id=20600
> >>>> For that raeson, if you want to use a rt kernel, it is good practice
> >>>> to have another kernel of the same version, vanilla or gentoo
> >>>> sources, and reboot on this non rt kernel when using emerge.
> >>> 
> >>> I noticed this when trying to emerge nvidia-drivers.
> >>> 
> >>> Thanks,
> >>> Grant
> >> 
> >> Hi Grant,
> >>   I thought we had this discussion maybe 6 months ago? Maybe I'm
> >> wrong about that.
> >> 
> >>   For pure audio playback the real-time kernel and Jack provide
> >> almost NO value. The real-time kernel is able to give more responsive
> >> attention to certain drivers or apps. Jack is one of them and if your
> >> mpd app - whatever that is - is a Jack app then it inherits the
> >> attention. However this only matters when you need to do something in
> >> 'real time'. There is nothing, in my opinion, 'real time' about
> >> reading a stream of pre-recorded data off a disk, buffering it up and
> >> then sending it to a sound card. Why does the sound card need to
> >> receive data in 5mS vs 25mS? The only difference that the buffer time
> >> causes is to delay the start of playback. Once playback starts as long
> >> as there is no time the buffer runs dry there is no difference in the
> >> sound you hear.
> >> 
> >>   I think that for your application using the real-time kernel and
> >> Jack is adding nothing but complication and that's likely to cause
> >> more problems than it's going to solve.
> > 
> > How low of a latency are you able to keep stable?  The output of my
> > jackd calculates 5.8ms.  Here's the command I'm using now:
> > 
> > jackd -R -P85 -c h -d alsa -d hw:1,0 -r44100 -p256 -n3 -S -P
> 
> Again, forcing low latency numbers in Jack will only lead to problems
> in a playback-only system. All Jack is doing is pushing the hardware
> harder for no technical advantage.
> 
> Low latency makes a BIG difference when RECORDING audio.
> 
> 1) A singer is listening to a recording she will sing with. She wants
> to hear her voice with reverb mixed with the audio.
> 2) The PC starts streaming audio from disk and delivering it to the
> sound card. This takes 1 Jack latency time period.
> 3) The time to sing comes so she does. Note that what she is hearing
> is 1 time unit behind what the computer is doing
> 4) Her air-born waveforms are first converted to electricity by the
> mic, digitized by an external ADC and fed to a digital input on a
> sound card. Let's assume this much is instantaneous.
> 5) The computer has to accept this data from the sound card. This
> takes 1 more Jack latency time period. Her digitized voice data is now
> in the computer but is 2 Jack time units behind the data coming off of
> the disk and 1 Jack time unit from when she made the sounds.
> 6) The computer adds reverb. Let's assume this is instantaneous in
> terms of CPU processing. Depending on the reverb unit it may add Jack
> cycles, but let's ignore those as they are not important here.
> 7) The computer sends her voice and the current data back out to her
> headphone mix. The audio going out, consisting of the recorded data
> from disk mixed with live voice with reverb is always out of sync by 2
> Jack time units.
> 
> If the recording engineer wants to then he can take he voice and nudge
> it forward on disk by 2 Jack time units to be 'exactly aligned' or 1
> Jack time unit to be 'aligned like she heard it'. This is optional. I
> seldom ever do it, although for drums recorded late in a session I am
> more sensitive to this.
> 
> Respectfully, I think you are fooling yourself when you say you 'hear'
> a difference when the audio is delivered from your disk to your sound
> card faster. It's the same audio delayed by 5.6 mS. As long as the
> system is set up correctly the data is completely unchanged except for
> the latency of getting it delivered. Since you ___cannot___ hear
> 'delay' except by relative measure - and you have ___no___ relative
> measure when doing only playback, it's impossible to hear whether I'm
> running at 1.2mS, 5.6mS or 25mS.
> 
> I do not subscribe to the 'my numbers are better than your numbers'
> crowd very much. My latency is stable at 1.2mS or lower when using the
> HDSP9652 with external DACs, but again, it's immaterial for a playback
> only system. When I'm purely mixing audio I set latency at 25mS to
> reduce the chances of an xrun to essentially zero. (Although that's
> not true. There's always a statistical chance of something happening.)
> I hear no difference in the mix running 1.2mS or 25mS.
> 
> Cheers,
> Mark

Just an email to say thanks for this concisely written information. I did not 
know that the real-time kernel can cause compilation failures.

To be honest I've not had the need to use a real-time kernel yet as my audio 
workstation at home is stuck on Windows 98 because of a rather special audio 
card that I really don't want to part with. It's a pain to use that OS but I 
can't upgrade past Windows 98 or I will lose use of the card.

I plan to upgrade that ancient machine so I can dual boot and use Linux on it 
as well, and this information will become very useful at that point. I will 
lack the use of the card on Linux because there are no drivers for it at 
present and I doubt there will ever be. At least I will be able to test the 
real-time kernel and know how to set it up and what to expect. Thanks again 
for the help and sorry for the rambling.

Best regards
Gavin