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 <[EMAIL PROTECTED]>  
> wrote:
>
>> 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 my
>> 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 that.


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

Thanks,
Albert



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to