Re: PortAudio ALSA Realtime Patch
AudioMulch Sales (Ross Bencina <sales <at> audiomulch.com>
2008-03-01 00:15:00 GMT
wrt the real-time scheduling thing my suggestion would be to investigate
what is considered standard policy. Arve has already noted that rt
scheduling is an option for Jack, not a default, but what about other apps?
We had a related situation on Windows a few years back and ended up removing
the option for RT priorities altogether because it caused too many system
conflicts, not sure if that would happen on Linux though.
In any case, it seems to me that end-users would want to have the option to
make a choice (whether or not it's the default within PA) so the PA default
is less important than providing a method to enable it or disable it, which
I understand we already have. MIXXX can always choose to default to having
it switched on.
I think the availability of host-api-specific extensions is a separate issue
and should be treated as such. Isn't there a standard way to _try_ to load a
specific function from a shared library at runtime on Linux?
----- Original Message -----
From: "Albert Santoni" <asantoni <at> uwo.ca>
To: "Arve Knudsen" <aknuds-1 <at> broadpark.no>
Cc: "mixxx-devel" <mixxx-devel <at> lists.sourceforge.net>; "portaudio"
<portaudio <at> techweb.rfa.org>
Sent: Saturday, March 01, 2008 7:24 AM
Subject: Re: [Portaudio] PortAudio ALSA Realtime Patch
> Hi Arve,
> Thanks for your attention on this, replies inline below:
> On 28-Feb-08, at 4:17 PM, Arve Knudsen wrote:
>> Hello Albert
>> On Fri, 22 Feb 2008 05:32:01 +0100, Albert Santoni <asantoni <at> uwo.ca>
>>> Hi all,
>>> A while ago I mentioned that the host-api specific extensions in
>>> PortAudio aren't usable on Linux because applications will fail to link
>>> against the extensions' symbols (they're not exported for some reason).
>>> Specifically, I was interested in using the
>>> PaAlsa_EnableRealtimeScheduling() extension to improve Mixxx's
>>> performance with ALSA, which is noticeably worse than when using OSS
>>> (higher latency needed with ALSA).
>>> Rather than sort out the exporting-symbols-properly mess (it's beyond
>>> capacity at the moment), I'd like to propose just enabling realtime
>>> scheduling by default in the StartStream implementation for ALSA.
>>> Attached is a simple patch to do so.
>>> Two questions to go along with the patch:
>>> - Is there a good reason not to enable RT by default?
>> It is for conservative reasons. The PA thread will attain RT privileges,
>> at the expense of other threads/processes. I'm not sure it's a good idea
>> to always enable this. I don't think it's common practice, for instance
>> the JACK server has an option to turn on realtime scheduling.
> I'm on the other side of the fence with this one. Of the developers using
> the non-blocking API, I think the vast majority of them want realtime
> operation. There's no point in getting underruns in your audio. And when
> our users run RT kernels, they expect applications to take advantage of
>>> - I'm just assuming that this will fail gracefully/silently if RT
>>> scheduling is not available. Can anyone confirm this?
>> Depends what you mean by not available? If it's not permitted, the
>> operation will fail gracefully. Otherwise, paInternalError is returned.
> Ok, so I don't think there's any problem then. RT kernel users will get
> lower latencies, and it won't make a difference for everyone else. If
> you've got a realtime audio API, you might as well make the defaults
> "realtime". :)
> Anyone else have any thoughts?
> Portaudio mailing list
> Portaudio <at> techweb.rfa.org