Re: [Mustux-devel] lac 2005 summary

[Remon Sijrier]

Hello Reinhard,

> it's again a great pity that we cannot managed it to meet us at lac ...

Yes indeed :-(

> hopefully we can manage this next year, because 99% are talking about jack
> stuff and __much too less__ people talking about mustux related stuff
> although people are very impressed when I talked with them about jmb and
> show them the benefit when they __would__ use it, but finally they
> want/need to use more jack apps in addition to protux!
>
> so I consider that protux would attract much more interest when it could be
> talk to jack!!

I've been thinking on this for some time now, perhaps it's a good idea to have 
jack support, but it's not trivial to implement....


>
> protux could be used then to add the soundtrack to a movie using xjadeo,
> for example. http://sourceforge.net/projects/xjadeo/
>
> I don't know how much work this will cost, but I think this would be an
> important issue to bring protux more to the public.

A lot of work!
But indeed, Protux would become more useable for the people who only use jack.

>
> also the hardware detection problem would be solved then (correct me when
> I'm totally wrong!!) since I heard again problems when multiple soundboards
> are installed (for example: if an soundblaster live AND another
> pro-audio-multi-track-board are installed only the sb live will be detected
> by MADM)

Hardware detection is rather complete now, really. Only a few bugs needs to be 
solved, which is problematic when you don't have a multichannel card.
Both Martin and I have one now (yes I finally have one!) so we can work on 
that issue.
I did some little investigation and it's not to hard to get it working, 
although to make it work the right way, thats another story but not 
impossible :-)

>
> so, please guys, I would suggest to resume the jack-or-not discussion
> again! this should not mean that you should drop your idea of having an own
> sound server, but rather this should be kept for the future!!

The bigest problem is that in the current implementation Protux/mustux "feeds" 
the soundcard buses.
Jack "asks" the program to process a chunk of audio, collects it and then 
"feeds" it to the hardware.

I myself see some big advantages in the latter approach. Point is that jack is 
not forgiving when a buffer underrun occurs. Since both capture and playback 
are handled in one thread, excesive cpu usage in the playback thread can 
cause a buffer underrun in the capture thread.

The sound server I have in mind (bases on the work of Mustux) has at least 2 
threads. One with a very short code path which handles the capture stream 
only and fires a thread which handles the playback stuff. This adds one extra 
context switch, but I don't think this is after all such a big deal  ;-)
Big advantage is that capture stream has very short code path and most likely 
will _always_ finish in time, and whatever the playback stream does in terms 
of CPU consumption, causing for example buffer underruns or "hanging", the 
capture stream will always be valid :-)

So this idea has much in common with the jack server, in that they are both 
callback based, so we can make an abstraction layer in mustux and attach both 
our own alsa based backend to it or jack, I think thats possible, but a lot 
of work :-(
On the other hand, our soundserver would have some additions / different 
approach in handling sound streams which can be very valuable hehe...


Thank a lot for promoting mustux on lac Reinhard, I hope we / I can be there 
next year!


Remon