Re: [proaudio] Real-time for audio

[Grant <emailgrant@xxxxxxxxx>]

>>> 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.

No, you're right on.  It was right around the time your desktop crapped out..

>   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

Very nicely explained.  Would any alsa app be able to "inherit the
attention" via the alsa jack plugin?

> 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.

Audio is so weird.  I just got real-time up and running this morning
and it makes a very noticeable difference.  It sounds great!  I became
suspicious when I realized my FLAC files didn't sound quite as good as
they did after being decoded to WAV.  Of course, the only difference
between the two formats during playback should be the time involved
for the system to turn them into an audio signal.  That may not be a
related issue, but it's what made me want to try real-time.

>   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.

I urge you to give it a try.  I'll be very surprised if you don't hear
a difference.  Here is the /etc/mpd.conf audio_output block for jack:

audio_output {
   type "jack"
   name "Jack or whatever"
}

If you aren't familiar with mpd I'd be more than happy to help you set
it up.  gmpc is my client of choice.

- Grant