Re: Resolution to republish MSP as a note

On Wed, Aug 8, 2012 at 5:47 PM, Stéphane Letz <letz@grame.fr> wrote:

>
> Le 8 août 2012 à 16:35, Jussi Kalliokoski a écrit :
>
> > 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.
>
> RT audio threads is not an absolute guaranty of "glitchless" audio..., but
> audio in non RT threads certainly helps.... ((-;
>
> In any case if the CPU use of the audio part causes the application to
> become unusable, then you have a problem for sure....The choice is : what
> is supposed to be the priority?
>

>From a UX point of view, the priority is getting to the application
settings and disabling the audio or at least exiting the application.


> > 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,
>
> OK, matter of choice...
>
> > I'd actually rather have the UI in an RT thread like iOS does
>
> Sorry? Where to do get this info from?  (I would say audio certainly runs
> in an RT thread on iOS, since it is using CoreAudio framework..)
>

Sorry, I was only referring to the fact that iOS has the UI in an RT thread
unlike Android, not saying the audio isn't. :)


>
> > and have that always go before the audio and anything else for that
> matter. I'm pretty sure I'm not the only one.
> >
> > Cheers,
> > Jussi
>
> Maybe, maybe not. As an audio developer, I would better want my audio
> always run reliably...


Unfortunately in the current state of technology the sounds usually don't
help as much with using an application as the GUI does. As an audio
developer I'd also prefer my audio ran reliably, but not at the expense of
things that are critical to the use of the application. Therefore for
example I'd prefer that a virtual instrument would have a RT thread for
audio, whereas in a game it would depend on the constraints (e.g. is it a
low-end device, how big a part do the sounds play, how heavy the sound
processing is...)

Cheers,
Jussi