Hi all !
As a christmas present, I though it would be good to have working jack
It all started when I saw the library "bio2jack"  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  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
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 :-)
PS: Will be away from the 30th to the 6th...