W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: Resolution to republish MSP as a note

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Wed, 8 Aug 2012 21:21:09 +0300
Message-ID: <CAJhzemU3OAH5AV=5NtubwnKJgk+i1NeiTN3wmg6C6ZRUjfUYTA@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Stéphane Letz <letz@grame.fr>, public-audio@w3.org
On Wed, Aug 8, 2012 at 8:21 PM, Chris Rogers <crogers@google.com> wrote:

> On Wed, Aug 8, 2012 at 7:35 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>> On Wed, Aug 8, 2012 at 4:25 PM, Stéphane Letz <letz@grame.fr> wrote:
>>>  >
>>> > I'm probably badly misinformed, but the value of high priority threads
>>> seems a bit vague to me, since I'm not sure about what's the OS support
>>> level for high-priority threads, I think for example in Linux you still
>>> have to compile your own kernel to get real high priority thread support.
>>> No. You would possibly need a special kernel for very ¨*low latency*
>>> thread scheduling, but not for RT scheduling and thread priority
>>> management. A regular Linux kernel is now quite usable, assuming the audio
>>> thread can take RT scheduling capability, which is given using Realtime Kit
>>> in PulseAudio AFAICS or correctly setting a special "realtime" group with
>>> appropriate values (see here for JACK:
>>> http://jackaudio.org/realtime_vs_realtime_kernel and
>>> http://jackaudio.org/linux_rt_config)
>> Thought I'd be misinformed! Thanks for the clarification, and sorry for
>> the mixup.
>>> On OSX real-time threads are actually "time constraints" threads, that
>>> are going to preempt any other non RT thread and are "interleaved" with
>>> other RT threads. The CoreAudio callback will run in a real-time
>>> constraints started and configurated by the CoreAudio frameworks for the
>>> audio application.
>>> > And using high-priority threads might not always even be desirable,
>>> for example in low-end devices it'd be horrible if the UI became completely
>>> unusable because an audio thread was occupying the whole thread.
>>> But if not RT, then the audio will "glitch"... Do we want reliable
>>> audio? or not?
>> I think you mean to ask "do we want audio in RT threads", because even
>> that doesn't always warrant reliable audio nor does not having it exclude
>> reliable audio. The answer to that question would be sometimes yes,
>> sometimes not. Glitchless audio isn't worth much if the application becomes
>> otherwise completely unusable. Is high-priority audio threads a feature
>> that warrants for the complexity that comes with the native nodes?
>> Especially given that we still have the possibility of RT thread workers
>> open.
>> I'm pretty sure that for example my Android phone doesn't run it's audio
>> in a real-time thread, even networking connections can sometimes glitch the
>> audio. But it's never bothered me, I'd actually rather have the UI in an RT
>> thread like iOS does and have that always go before the audio and anything
>> else for that matter. I'm pretty sure I'm not the only one.
> But many people have asked for improvements to the Android audio
> performance and do not appreciate high-latency and glitches.  I know that
> iOS *does* use high-priority threads and it works great for them, so your
> argument seems to be rather weak.  Believe it or not, I think there will
> actually be many people who are interested to process live audio in
> real-time in web applications, or to play synthesizers using the MIDI API.
>  Just because we've had terrible performance on the web with Flash, etc.
> doesn't mean we have to stay in the stone age, lagging so far behind the
> desktop audio applications abilities.

It wasn't really an argument, it was just my personal opinion. And I'm not
suggesting we have bad performance, I'm suggesting a different approach at
tackling performance issues. I agree that RT threads offer benefits in some
cases, but some cases they don't and it should be up to the developer to
decide what takes priority in his/her application. Hence I'd rather we try
to get RT thread support for workers so that one can just decide whether to
use a real-time thread or not by choosing the type of worker to use. If we
had that, what on earth would be lagging behind desktop audio applications'

Received on Wednesday, 8 August 2012 18:21:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC