[mod-users] Requesting overview of the software stack
Harry van Haaren
harryhaaren at gmail.com
Fri Apr 8 09:44:26 UTC 2016
On Fri, Apr 8, 2016 at 5:15 AM, Ytai Ben-Tsvi <ytaibt at gmail.com> wrote:
> Hey guys,
I'll answer some of this, just the parts I'm familiar with.
> Any chance one of you can provide (or refer me to) a high-level
> description of the entire software stack of the MOD, starting at the OS all
> the way to the application? This shouldn't be longer than a simple diagram,
> perhaps with links to where the source code can be found in the MOD github
OS -> ALSA (Sound drivers) -> JACKd ("sound server") -> MOD host.
MOD Host -> Web Socket -> HTML/CSS/JS -> Browser
Perhaps one of the MOD team will jump in here with details on the UI side
of things - I'm not quite a web-developer ;)
> And a specific question: are you using vanilla Linux or did you apply any
> realtime patch to the kernel?
I think the MOD runs on the sunxi kernel - this is common with ARM embedded
platforms that are not (yet) upstreamed to the mainline linux kernel.
> If the former, how do you guarantee realtime performance?
We must discuss details first, between hard realtime and soft-realtime.
Hard realtime systems (RTOS-es, for use in robotics, automotive, etc) need
verifiable proof of RT-safety.
Soft realtime systems (audio use-case, and others) involves that the
systems should be optimized for RT safety, but it is not gauranteed. No
"High level" audio software manufacturer gaurantees RT safety - its not
possible without an RTOS (or Xen, or Xenomai... etc). The point i'm trying
to make is that no standard Windows, OsX or Linux system is hard real-time
safe. Apologies if you knew this already :)
> I get the feeling that the XRUN problems are likely a result of improper
> task scheduling and will never go away completely unless the entire device
> is treated as realtime system. The fact that those XRUNs are sporadic makes
> me suspect that there might be something wrong with the scheduling, if it
> ever allows anything significant (as opposed to quick interrupts) other
> than the audio to preempt the audio.
Yes you're right - scheduling performance, preemption and rtprio are the
first points to investigate. I know the MOD team are aware of this - and
have done work in that area already. I'm not sure of the current status of
I've documented (some|all) of my knowledge on the topic of tuning systems
for RT audio performance here, and will be in Berlin for the miniLAC this
week, so hopefully can spend some time with the folks at MOD to investigate
> I have some experience in this field and would be happy to look over some
> code or consult, if you feel that this could help.
Great - I will keep that in mind, and keep you in the loop :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users