Hi all !

As a christmas present, I though it would be good to have working jack 
support !

It all started when I saw the library "bio2jack" [0] waiting for entering 
debian archive.. Its goal is to give a blocking API to jack server, that is 
to say precisely the kind of API we already used for ao, alsa and co..

So I gave it a try, and wrote a basic binding, which is very easy since the 
API is very simple.

Then I added input and output derived from ao and alsa, with the possibility 
to run "unbuffered", i.e. in the main thread.

So far so good... 

But I noticed that the input got corrupted after some times, which was exactly 
the kind of issues I'd encountered with previous jack support...

Digging in the library code, I found it was a pointer corruption when the 
ringbuffer didn't have enough room for new data, the rational was to drop old 
data and put new instead.. 
But, and as this was already noticed in the comments, this is not thread safe, 
since another thread might be using the ringbuffer at the same sime.. 
So they had a lock for this case, and it was not enough..

My proposal [1] was, on the contrary to avoid race conditions and locks, and 
simply drop new data... I tried to patch for writing only available room, but 
still had the corruption, so ended up simply writing nothing in this case..

I then noticed that ices-kh does exactly this in this case..
And then that we were using the same function in out input jack..

So I did the same change to our original input.jack.. 
So far, so good, I didn't noticed any corruption. 

But liquidsoap's usage is much higher with original jack, and it slows the 
main thread into which it runs... 
I tried to put it under a reader/writen paradigm as for ao and co., but the 
speed is definitly not matching, the main thread ends up with half blank 
frames...

So here are my conclusions:
* The read_advance function in jack's ringbuffer is hasardous, the  
strategy "drop new samples when no available room" is far safer..
* I have a light and working support using bio2jack. However, we don't control 
the library developpement, and there are, beside the big corruption bugs, few 
annoying details that I can't directly fix there, unless I can get in touch 
directly with the author.
* Current jack support can be fixed. However, it might be difficult to lower 
its usage, and/or put it in a seperate thread. 
* There is still the possibility to write a quick implementation, using ices' 
one for instance, directly in liquidsoap.

My ideal plan would be to get in touch with bio2jack's maintainer and fix 
minor things as well as the big corruption bug, and switch to it.

But, as Sam spent a lot of time on the original bindings and implementations, 
I'd like to have his opinion about all of this.

And a happy new year in advance for all of you :-)

Romain
PS: Will be away from the 30th to the 6th...

[0]: http://bio2jack.sourceforge.net/
[1]: 
http://sourceforge.net/tracker/index.php?func=detail&aid=1858093&group_id=70382&atid=527604

Répondre à