Re: [Protux-devel] JACK or NOT JACK, thats the question..

[Remon Sijrier]

> When we talk about Jack or not Jack, we are actually talking about threaded
> architeture or pooled architeture.

JACK is a threaded application. ALSA internally uses polling. Depending on the 
way you talk to ALSA, you make use of the ALSA polling mechanism or not. (In 
some degree)

We do not make use of the ALSA polling mechanism.

> I personal think that making  pooled streaming is an antique approach. Most
> of modern applications need thread stuff, so Jack should have been
> implement as a threaded server. Think : You do not download a piece of html
> each 20 ms from a http server!!! you just create a thread and get the
> entire html !

Hm, as far as I know, JACK is heavily threaded, especially in regard to the 
ALSA driver. The ALSA driver thread is the only one which is running 
realtime, and its running VERY realtime (70 out of 100, 50 will do for a 
normal audio app)


> Alsa is thread safe, they say. So why jack didnt take benefit of it ? I
> really dont agree to make MADM pooled JUST to talk to Jack. We can think
> about a layer of compatibility someday, but, honestly guys, I dont plan to
> make MADM pooled,not at all!

The linux kernel has high resolution timers. In combination with RTC, this is 
a robust use of polling. The main reason (as far as I know) for ALSA to use 
(this kind of) polling is to let the client know that its (ALSA's) internal 
ringbuffer has exceeded a threshold. This threshold can be set, and depending 
on the frame sizes you use and the set threshold (you have to calculate the 
best mix) ALSA let the client know that it can handle another peace of data.
MADM doesn't make use of this approach but continues feeding the ALSA 
ringbuffer in a blocked way. So it doesn't return of feeding the ringbuffer 
until ALSA excepts the peace of data. That means that the ringbuffer is empty 
enough to hold the new peace of data. And then ALSA is using polling 
internally to handle this situation as well :-P

> This is an old discussion, we always endup in this point. 

Yes and no. The problem with JACK (or we have with JACK) is that it's client - 
server interface uses the so ***** callback mechanism, and as far as I know, 
this is not threaded, and so NOT a realtime priority for the kernel. Under 
heavy load, this can cause glitches, whereas MADM uses a direct calling 
method, within the realtime thread, and thats the point where MADM is more 
robust then JACK !!
(I think this is what you mean Luciano by  pooled streaming. Jack IS a 
threaded architecture, its it callback interface (pooled streaming) that 
causes the problems)

But since we don't have mixing capabilities in MADM, and MADM isn't a 
standalone program, we can't use it (now) as a server to serve more audio 
applications at once. This would require a big change, and hence give the 
same problem in connecting the sound application to the MADM server, because 
we would also have the callback thingie (Correct me if I'm wrong please)


> Maybe we should 
> consider work only with native alsa, and make MADM an ALTERNATIVE to JAck.
> Jack is intended to offer ALSA abstraction, MADM too.. MADM API is FAR MORE
> SIMPLE to use than Jack. So why we should behave like client when we can be
> server ?? We should be searching ways to make MADM more robust, not less
> robust, and dependent of another engine.

Although I really would love this, .....

JACK is doing a great deal of work allready, and it's pushed to be the 
"defacto" sound server for linux. As soon as applications go to support JACK, 
they are probably not so willing to support MADM as well, also because it 
will take years (or a handfull of experienced developers gives as a hand) to 
accomplish this.

People (also me) want transparency. When you're new to linux, you're 
overwhelmed by a lot of application who claim they do all the same!?
If MADM becomes the second JACK (but better ;-) and 100% of all sound 
applications are using JACK, but only 1 or 2 powerfull one's are using MADM 
the users decision is an obvious one.
You can't use MADM and JACK at the same time. I have the feeling JACK is 
implemented to much by the vision of one person, and the resulting problems 
aren't acknowledged.

So this is how it is now IMHO, and we can't do much about it. It's unlikely 
JACK changes the way it talks to its clients. How sad it can be :-(

And to be honest, there is still only one application like JACK, so 
programmers have to stick with it. If we can prove MADM is a better 
alternative......

Best wishes,

Remon