Towards a truely realtime capable FOSS audio distribution | A guide to the Jack Source Code

[micu]

Hello everybody,

my name is micu and I study computer science at the Dresden University of
Technology. During an internship at the operating systems chair of the
university, I ported ALSA to the chairs operating system DROPS aka TUD:OS
[1,2]. To let ALSA talk to the hardware and provide to it the usual linux
kernel environment DDEKit / DDELinux [3] were used. As a kernel-userland
interface I wrote a very small emulation layer, which makes it possible to
link SALSA-lib [4] against the ALSA "kernel" part.

So right now, we have a somewhat stable ALSA server running in userland on top
of DROPS without changing ALSA or the SALSA-lib source code.

I have been continuing this project within my diploma thesis. The remit of the
thesis can be found here [5]. It is the goal of the thesis to take some steps
towards a truly realtime capable (meaning with time constraints to be
guaranteed) FOSS audio distribution. Here [6] you can see a raw version of my
requirements definition.

The architecture we are going to use is --- how could it be different :) ---
Jack or Jackdmp (with a strong bias towards Jackdmp). To get the mess out of
my head, I wrote a short guide [7] to the Jack source code. It is a pretty
raw version and it isn't finished in any way yet; but I won't work on it any
longer. Nevertheless, it might be helpful to other developers new to Jack.
Therefore, if you will, you may get it under any license you wish
(attribution of the author is appreciated :) to publish and improve it.

Of course, the long term goal of the project won't be met to any extent during
my thesis and I have no idea, if this project will be continued here at the
university. Neither do I know, whether I will have time to work on it
afterwards.

To make a long story short: I would like to ask my first three questions....
so far :)

        1.) Do you agree on having a truly real-time capable architecture in the FOSS
audio world would be a really great thing --- and would you say, getting such
a thing maybe could get a (major) goal of the pro audio FOSS community?

        2.) Concerning our Jack vs. Jackdmp decision: http://jackaudio.org/ says,
Jackdmp is going to be Jack 2.0. How likely and how soon do you think is this
going to happen?

        3.) I guess, there is a very minor bug in the lines 236, 237 of
libjack/driver.c, svn revision 2734: The type castings should be switched.


Thanks a lot in advance and please excuse my bad english :(.

Regards,
micu

BTW: I love Jack and I love ardour --- and therefore I love you :).
==========================================
[1]http://www.realtimelinuxfoundation.org/variants/variants.html#VARIANTS_DROPS
[2]http://www.osnews.com/story.php/15814/Introduction-to-TUD-OS/
[3]http://demo.tudos.org/dsweeper_tutorial.html
[4]http://www.alsa-project.org/main/index.php/SALSA-Library
[5]http://www1.inf.tu-dresden.de/~s3418892/task.txt 
[6]http://www1.inf.tu-dresden.de/~s3418892/Require.pdf
[7]http://www1.inf.tu-dresden.de/~s3418892/AgttJSC.txt
--
GnuPG: https://www1.inf.tu-dresden.de/~s3418892/micuintus.asc
Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 24 juil. 08 à 22:23, micu a écrit :

> Hello everybody,
>
> my name is micu and I study computer science at the Dresden  
> University of
> Technology. During an internship at the operating systems chair of the
> university, I ported ALSA to the chairs operating system DROPS aka  
> TUD:OS
> [1,2]. To let ALSA talk to the hardware and provide to it the usual  
> linux
> kernel environment DDEKit / DDELinux [3] were used. As a kernel-
> userland
> interface I wrote a very small emulation layer, which makes it  
> possible to
> link SALSA-lib [4] against the ALSA "kernel" part.
>
> So right now, we have a somewhat stable ALSA server running in  
> userland on top
> of DROPS without changing ALSA or the SALSA-lib source code.
>
> I have been continuing this project within my diploma thesis. The  
> remit of the
> thesis can be found here [5]. It is the goal of the thesis to take  
> some steps
> towards a truly realtime capable (meaning with time constraints to be
> guaranteed) FOSS audio distribution. Here [6] you can see a raw  
> version of my
> requirements definition.
>
> The architecture we are going to use is --- how could it be  
> different :) ---
> Jack or Jackdmp (with a strong bias towards Jackdmp). To get the  
> mess out of
> my head, I wrote a short guide [7] to the Jack source code. It is a  
> pretty
> raw version and it isn't finished in any way yet; but I won't work  
> on it any
> longer. Nevertheless, it might be helpful to other developers new  
> to Jack.
> Therefore, if you will, you may get it under any license you wish
> (attribution of the author is appreciated :) to publish and improve  
> it.
>
> Of course, the long term goal of the project won't be met to any  
> extent during
> my thesis and I have no idea, if this project will be continued  
> here at the
> university. Neither do I know, whether I will have time to work on it
> afterwards.
>
> To make a long story short: I would like to ask my first three  
> questions....
> so far :)
>
> 1.) Do you agree on having a truly real-time capable architecture  
> in the FOSS
> audio world would be a really great thing --- and would you say,  
> getting such
> a thing maybe could get a (major) goal of the pro audio FOSS  
> community?

It is certainly an interesting idea to better caracterize and  
understand how a complex system works regarding real-time  
capabilities. Some new tools are to be developed to understand what  
happens when a complex graph of jack clients works for example. My  
feeling it that it would be a desirable goal.

>
> 2.) Concerning our Jack vs. Jackdmp decision: http://
> jackaudio.org/ says,
> Jackdmp is going to be Jack 2.0. How likely and how soon do you  
> think is this
> going to happen?

Difficult to say, but I stongly suggest to have a look at jack2 SVN  
code ( jackdmp 1.90 version). New code and ideas are now developed on  
this code base.

>
> 3.) I guess, there is a very minor bug in the lines 236, 237 of
> libjack/driver.c, svn revision 2734: The type castings should be  
> switched.

A patch is always better.
>
>
> Thanks a lot in advance and please excuse my bad english :(.
>

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[micu]

Hey Stephane et al.,

thanks a lot for you nice answer!


> It is certainly an interesting idea to [...] My
> feeling it that it would be a desirable goal.

Well, thats an answer I like :)


> > 3.) I guess, there is a very minor bug in the lines 236, 237 of
> > libjack/driver.c, svn revision 2734: The type castings should be
> > switched.
>
> A patch is always better.

Uhh, you are right, of course. I'm sorry:
Index: libjack/driver.c
===================================================================
--- libjack/driver.c (revision 2734)
+++ libjack/driver.c (working copy)
@@ -241,8 +241,8 @@
  driver->attach       = (JackDriverAttachFunction)    jack_driver_nt_attach;
  driver->detach       = (JackDriverDetachFunction)    jack_driver_nt_detach;
  driver->bufsize      = (JackDriverBufSizeFunction)   jack_driver_nt_bufsize;
- driver->stop         = (JackDriverStartFunction)     jack_driver_nt_stop;
- driver->start        = (JackDriverStopFunction)      jack_driver_nt_start;
+ driver->start        = (JackDriverStartFunction)     jack_driver_nt_start;
+ driver->stop         = (JackDriverStopFunction)      jack_driver_nt_stop;
 
  driver->nt_bufsize   = (JackDriverNTBufSizeFunction) dummy_bufsize;
  driver->nt_start     = (JackDriverNTStartFunction)   dummy_start;

Cya,
micu
--
GnuPG: https://www1.inf.tu-dresden.de/~s3418892/micuintus.asc
Fingerprint: 1A15 A480 1F8B 07F6 9D12 3426 CEFE 7455 E4CB 4E80

<<</>>

https://wiki.c3d2.de/Benutzer:Micuintus
https://wiki.vorratsdatenspeicherung.de/Benutzer:Micuintus
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 25 juil. 08 à 12:35, micu a écrit :

> Hey Stephane et al.,
>
> thanks a lot for you nice answer!
>
>
>> It is certainly an interesting idea to [...] My
>> feeling it that it would be a desirable goal.
>
> Well, thats an answer I like :)
>
>
>>> 3.) I guess, there is a very minor bug in the lines 236, 237 of
>>> libjack/driver.c, svn revision 2734: The type castings should be
>>> switched.
>>
>> A patch is always better.
>
> Uhh, you are right, of course. I'm sorry:
> Index: libjack/driver.c
> ===================================================================
> --- libjack/driver.c (revision 2734)
> +++ libjack/driver.c (working copy)
> @@ -241,8 +241,8 @@
> driver->attach       = (JackDriverAttachFunction)    
> jack_driver_nt_attach;
> driver->detach       = (JackDriverDetachFunction)    
> jack_driver_nt_detach;
> driver->bufsize      = (JackDriverBufSizeFunction)    
> jack_driver_nt_bufsize;
> - driver->stop         = (JackDriverStartFunction)      
> jack_driver_nt_stop;
> - driver->start        = (JackDriverStopFunction)      
> jack_driver_nt_start;
> + driver->start        = (JackDriverStartFunction)      
> jack_driver_nt_start;
> + driver->stop         = (JackDriverStopFunction)      
> jack_driver_nt_stop;
>
> driver->nt_bufsize   = (JackDriverNTBufSizeFunction) dummy_bufsize;
> driver->nt_start     = (JackDriverNTStartFunction)   dummy_start;
>

Applied although not critical since both functions have the same  
prototype...

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org