[ANN] jack_diplomat (alpha software)

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] jack_diplomat (alpha software)

Dave Cunningham
Hi

This is a little program I've been working on recently, it sort
of works for me, but could use a lot of improvement, and I'm not
sure if its design is fundementally broken.  Here's the first
couple of paragraphs from its README file:

jack_diplomat is a jack client application that connects to a
pair of jack servers running simultaneously on a host system,
and streams audio from each to the other.  This can be useful
for e.g. implementing the infamous el-cheapo multichannel
recording workstation using several pci soundcards, since you
can access all soundcards from a single jack session.

There is a tradeoff between stability  and latency, but a few ms
without data corruption can be achieved.  There is some noise
due to the variable ratio resampling performed on the stream.

http://xdev.net/~spark/jack_diplomat-0.70.tar.bz2

Feel free to contact me on irc, i'm Spark on freenode, in #lad
etc.

I'm not sure if the jack_server_dir patch is in CVS yet, I think
it is not so obviously you'll need to apply it if you want to
test this.  The patch is in the source tarball.

Have fun!


-Dave Cunningham


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Dave Cunningham
On Tue, Nov 01, 2005 at 05:22:13PM +0000, Dave Cunningham wrote:
>I'm not sure if the jack_server_dir patch is in CVS yet, I think
>it is not so obviously you'll need to apply it if you want to
>test this.  The patch is in the source tarball.

What would it take to get this added to CVS?


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Jack O'Quin-2
Dave Cunningham <[hidden email]> writes:

> What would it take to get this added to CVS?

Not much.   I took a look at it already.

I'm not too happy with the size of that patch, but that's my fault not
yours.  I did not design the original interface very well.  It's a
pain returning strings from C functions.

I want to think about it some more and see if I can come up with a
cleaner fix.  The reentrancy problem is only on the client side, and
most of the code changes are on the server side (IIRC).  I'm
considering using different functions for the two.  

Your solution may be best, but I have to convince myself.

Thanks,
--
  joq


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Stéphane Letz
Hi,

I don't really understand the reason to develop a jack_diplomat kind  
of tool. I was thinking the alsa layer already had something allowing  
to synchronize several cards and possibly see several physical  
devices as a kind of unique logical one to be use by one jack server.  
Is is not the case?

Thanks

Stephane


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Florian Paul Schmidt-2
On Fri, 4 Nov 2005 09:22:12 +0100
Stéphane Letz <[hidden email]> wrote:

> Hi,
>
> I don't really understand the reason to develop a jack_diplomat kind  
> of tool. I was thinking the alsa layer already had something allowing  
> to synchronize several cards and possibly see several physical  
> devices as a kind of unique logical one to be use by one jack server.  
> Is is not the case?

Two words:

clock drift [and unstableness]

Umm, that was more than two :) Anyways, have fun,

Flo

--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Stéphane Letz

Le 4 nov. 05 à 10:34, Florian Schmidt a écrit :

> On Fri, 4 Nov 2005 09:22:12 +0100
> Stéphane Letz <[hidden email]> wrote:
>
>> Hi,
>>
>> I don't really understand the reason to develop a jack_diplomat kind
>> of tool. I was thinking the alsa layer already had something allowing
>> to synchronize several cards and possibly see several physical
>> devices as a kind of unique logical one to be use by one jack server.
>> Is is not the case?
>
> Two words:
>
> clock drift [and unstableness]

But I think this should be managed at the driver level  and become  
transparent for jackd ... and not by adding another level of  
complexity on top of the jack server itself.

Linux developers, you should look at the "dark side" (Apple in this  
case) where a concept to "aggregate" different devices have been  
introduced in OS 10.4 Tiger. This allow to see several physical audio  
devices as a unique logical device. Of course the synch problem is  
generally better solved by "physically" synchronizing the audio  
cards, but a software base synch could be interesting to have also.

Stephane



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

LGTrader
In reply to this post by Stéphane Letz
On 11/4/05, Stéphane Letz <[hidden email]> wrote:

> Hi,
>
> I don't really understand the reason to develop a jack_diplomat kind
> of tool. I was thinking the alsa layer already had something allowing
> to synchronize several cards and possibly see several physical
> devices as a kind of unique logical one to be use by one jack server.
> Is is not the case?
>
> Thanks
>
> Stephane
>

What if for some reason you *want* to run two card at different
frequencies? Say one runs at 44.1K and the other at 48K. What do you
do?

I find this program conceptually very interesting, although I admit I
don't know what I'd use it for. I also do not have a clue about how it
actually manages to do it's work, being that both cocks are drifting
and their sample rates are unknown. Seems like magic. (I like magic!)

- Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Dave Cunningham
In reply to this post by Stéphane Letz
>But I think this should be managed at the driver level  and become  
>transparent for jackd ...

Me too, but:

1) I wanted a proof of concept implementation, to show that it
could actually work.  The algorithm could be transferred into
some other context at a later date.  At any rate, I know the
jack API, but not the internals of libasound.

2) I assume you mean at the libasound level, since alsa wont
even include the far more useful software mixing into the
drivers themselves...

3) This is actually more general than what you suggest, since it
can synchronise jack daemons with backends other than alsa sound
cards, e.g. netjack.  Although going through libasound you could
create an alsa device around a jack server so maybe that's not
true after all.

On the other hand, handling it at a lower level would presumably
remove a lot of the weird timing issues i'm seeing at the
minute, because we don't have to worry about the ordering of the
jack graph and context switching and so on.  But the code to
deal with this would still need to be there, since alsa devices
are not necessarily low level.


>and not by adding another level of  complexity on top of the
>jack server itself.

Its not part of the jack server.  The patch is just to fix a bug
that prevents applications connecting to more than one server.



>Linux developers, you should look at the "dark side" (Apple in this  
>case) where a concept to "aggregate" different devices have been  
>introduced in OS 10.4 Tiger. This allow to see several physical audio  
>devices as a unique logical device. Of course the synch problem is  
>generally better solved by "physically" synchronizing the audio  
>cards, but a software base synch could be interesting to have also.

They certainly should evaluate other people's effort, this is
how academia works anyway :)  It's entirely in the spirit of OSS
to steal ideas...  As long as apple don't get a patent on
"composing multiple asynchronous sound devices with software
synchronisation" or something :)

Unfortunately I don't have a mac and will not be able to afford
one since i'm living on a pittance as a phd student, but I'm
still interested in hearing what else is going on.  Naturally
noone says anything until someone has already written some
code...   There were many posts to this lists saying "can
someone write xyz, it can't be that hard..." and noone saying
"no that would be a bad idea, it should be done at the driver
level like OSX does it".


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Glynn Clements
In reply to this post by LGTrader

Mark Knecht wrote:

> On 11/4/05, Stéphane Letz <[hidden email]> wrote:
> > Hi,
> >
> > I don't really understand the reason to develop a jack_diplomat kind
> > of tool. I was thinking the alsa layer already had something allowing
> > to synchronize several cards and possibly see several physical
> > devices as a kind of unique logical one to be use by one jack server.
> > Is is not the case?
> >
> > Thanks
> >
> > Stephane
> >
>
> What if for some reason you *want* to run two card at different
> frequencies? Say one runs at 44.1K and the other at 48K. What do you
> do?
>
> I find this program conceptually very interesting, although I admit I
> don't know what I'd use it for. I also do not have a clue about how it
> actually manages to do it's work, being that both cocks are drifting
> and their sample rates are unknown. Seems like magic. (I like magic!)

FWIW, there was some previous discussion of this back in mid-June:

http://sourceforge.net/mailarchive/forum.php?thread_id=7524221&forum_id=3040

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

LGTrader
On 11/5/05, Glynn Clements <[hidden email]> wrote:

>
> Mark Knecht wrote:
>
> > On 11/4/05, Stéphane Letz <[hidden email]> wrote:
> > > Hi,
> > >
> > > I don't really understand the reason to develop a jack_diplomat kind
> > > of tool. I was thinking the alsa layer already had something allowing
> > > to synchronize several cards and possibly see several physical
> > > devices as a kind of unique logical one to be use by one jack server.
> > > Is is not the case?
> > >
> > > Thanks
> > >
> > > Stephane
> > >
> >
> > What if for some reason you *want* to run two card at different
> > frequencies? Say one runs at 44.1K and the other at 48K. What do you
> > do?
> >
> > I find this program conceptually very interesting, although I admit I
> > don't know what I'd use it for. I also do not have a clue about how it
> > actually manages to do it's work, being that both cocks are drifting
> > and their sample rates are unknown. Seems like magic. (I like magic!)
>
> FWIW, there was some previous discussion of this back in mid-June:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=7524221&forum_id=3040
>
> --
> Glynn Clements <[hidden email]>
>
Hi Glynn,
   Interesting stuff, and I am interested in the overall topic. I
think making it work 100% reliably might require a bit of black magic
as I do not see how anyone is ever going to know the exact sample rate
of any card. As you note in the last response 48000 might be 47999 or
48001, but beyond that it might be changing between 47999 and 48001 at
unknown times.

   Anyway, I'll just sit on the sidelines and see how this all works out.

Cheers,
Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Florian Paul Schmidt-2
On Sat, 5 Nov 2005 09:36:02 -0800
Mark Knecht <[hidden email]> wrote:

> > > What if for some reason you *want* to run two card at different
> > > frequencies? Say one runs at 44.1K and the other at 48K. What do you
> > > do?
> > >
> > > I find this program conceptually very interesting, although I admit I
> > > don't know what I'd use it for. I also do not have a clue about how it
> > > actually manages to do it's work, being that both cocks are drifting
> > > and their sample rates are unknown. Seems like magic. (I like magic!)
> >
> > FWIW, there was some previous discussion of this back in mid-June:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_id=7524221&forum_id=3040
> >
> > --
> > Glynn Clements <[hidden email]>
> >
> Hi Glynn,
>    Interesting stuff, and I am interested in the overall topic. I
> think making it work 100% reliably might require a bit of black magic
> as I do not see how anyone is ever going to know the exact sample rate
> of any card. As you note in the last response 48000 might be 47999 or
> 48001, but beyond that it might be changing between 47999 and 48001 at
> unknown times.
>
>    Anyway, I'll just sit on the sidelines and see how this all works out.

Well,

basically the system needs to adapt over time.

First we take a look at the "simple case": Both soundcards run at the
same nominal samplerate (let's call it SR). We all know the clocks on
soundcards are not running exactly at the nominal frequency, plus they
are not stable and change over time depending on all kinds of factors.
So we have to adjust for that unstableness and unexactness.

jack_diplomat (let's only look at one direction, the other is handled
exactly the same) now works the following way:

There's two jack servers running. jack_diplomat opens a writable port in
the graph belonging to server 1 and a readable port in the graph
belonging to server 2. jack_diplomat then transfers audio from its
writable port to its readable port.

From now on we refer to the writable port as the producer (by being
written into it produces audio that needs to be passed to the readable
port) of audio and the readable port as the consumer (as it consumes the
audio it is being passed to from the writable port).

The producer and consumer each work with an unknown real samplerate, uSR1
and uSR2, which also changes over time. Let's assume SR1 > SR2 for now.
This means the producer produces audio too fast. For simplicity's sake
let's also assume both work with the same period size of N samples
(there's just a small bit of adjusting of the mechanism nessecary when
the periodsizes differ).

The first thing to do for both the producer and the consumer is to
determine their real samplerate with respect to the same clock (i.e. the
TSC). As audio is provided in chunks, we have to measure the time
between the arrival of two chunks. In the ideal case this time would be:

    time_between_chunks = period_size / samplerate
 
<=> samplerate = period_size / time_between_chunks

The time of chunk arrival is again suspect to jitter (in this case even
pretty largish ones as both jack servers compete for the same cpu, thus
one is often holding up the other). So we need to use an average over
many samplerate measurements to get a good estimate of the real
samplerate. So we use something very similar to a running average:

avg_samplerate += (sample_rate - avg_samplerate) * rate

where rate is very small (like 0.0001). we start out with the nominal
samplerate as guess and that guess gets improved over time.

So by this way both the producer and the consumer generate an estimate
of their real unknown samplerates uSR1 and uSR2. We said uSR1 > uSR2. So
we produce audio too fast. Thus the samples need to be resampled with a
ratio of

ratio = uSR2 / uSR1

before being passed to the consumer. The samples are being passed via a
ringbuffer from the producer to the consumer. The producer puts the
resampled samples into the buffer and the consumer reads them from it
(The consumer might do the resampling, too, but this are minor details).

Ok, a simple example to ilustrate this up to here. Let's assume the uSR1
is 4/3 * uSR2. So in the time where the producer runs 4 times (each time
it gets N samples from its jack graph), the consumer runs 3 times
(eachtime giving N samples away into its jack graph). So the producer
puts 4*N samples, resampled to 3/4 * 4*N = 3*N samples, into the
ringbuffer and the consumer consumes 3*N samples from the ringbuffer in
this time.

Sounds like it might work. But in the real world, the ratios are not
these nifty rational numbers. Plus everything changes over time. So
there's the danger of the buffer running empty or full, cause we don't
get it exactly right.

So we introduce another measure which is buffer fillness. As we always
want to have at least 1 period of samples in the buffer left for the
consumer to consume and at least 1 period of samples space in the buffer
for the producer, i kinda makes sense to make the buffer 3 periods big
(here's a little caveat: the effective period size is different for
consumer and producer, so let's conservatively choose the maximum of the
two) and to try to keep the buffer filled exactly in the middle at 1.5
periods worth of samples (so we have some leeway to react when it
empties or fills).

So one of the two (or both, but it doesn't really make a difference)
keeps an eye on the fill status of the buffer. As the buffer fill state
doesn't change smoothly, but rather hops in sizes of N samples, we again
have to keep an average over many periods quite similar to above.

Now, when we detect the buffer runs full (when the avg_buffer fill
deviates form the nominal buffer fill), we simply adjust the samplerate
ratio a little bit, so this gets compensated. Same for running empty.

ratio_adjust = -(avg_buffer_fill - nominal_buffer_fill) * rate

(Double check signs, and when your brain melts, just code it and correct
then ;) Also this rate is a different one from above. Tweak it to make
the code react less or more drastically to buffer fill state deviation).

So when the buffer runs full, the ratio is made a bit smaller, so that
less audio is put into the buffer.

And that's about it. jack_diplomat implements it a bit differently, but
imho it should work this way, too. Too lazy to hack example code
though..

Have fun..
Flo

--
Palimm Palimm!
http://tapas.affenbande.org


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

torbenh
On Sat, Nov 05, 2005 at 07:37:44PM +0100, Florian Schmidt wrote:
>
> ratio_adjust = -(avg_buffer_fill - nominal_buffer_fill) * rate

ok... and then we can have a second order control loop which controls
nominal_buffer_fill.
(though it should be constant ;)

what would would you try for rate ?
something like 0.0001 or even 1e-6 ?


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Dave Cunningham
On Sun, Nov 06, 2005 at 01:58:03PM +0100, [hidden email] wrote:

>On Sat, Nov 05, 2005 at 07:37:44PM +0100, Florian Schmidt wrote:
>>
>> ratio_adjust = -(avg_buffer_fill - nominal_buffer_fill) * rate
>
>ok... and then we can have a second order control loop which controls
>nominal_buffer_fill.
>(though it should be constant ;)
>
>what would would you try for rate ?
>something like 0.0001 or even 1e-6 ?

the default is 0.0005 at the minute, but...

This is the stuff that needs working out and implementing
properly, because at the moment the system oscillates quite a
lot.


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

LGTrader
In reply to this post by Florian Paul Schmidt-2
On 11/5/05, Florian Schmidt <[hidden email]> wrote:
> On Sat, 5 Nov 2005 09:36:02 -0800
> Mark Knecht <[hidden email]> wrote:
> >
> >    Anyway, I'll just sit on the sidelines and see how this all works out.
>
> Well,
>
> basically the system needs to adapt over time.

Florian,
   Nice description. Thanks.

   So the semi-interesting test (to me anyway) of this technology
would be to send a known signal through jack_diplomat, over the
'off-time' interface, route it back externally, receive it on the
off-time interface and retime it back to the original time source. How
much distortion occurs?

Thanks,
Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software) (on distortion)

Dave Cunningham
On Mon, Nov 07, 2005 at 08:12:32AM -0800, Mark Knecht wrote:

>On 11/5/05, Florian Schmidt <[hidden email]> wrote:
>> On Sat, 5 Nov 2005 09:36:02 -0800
>> Mark Knecht <[hidden email]> wrote:
>> >
>> >    Anyway, I'll just sit on the sidelines and see how this all works out.
>>
>> Well,
>>
>> basically the system needs to adapt over time.
>
>Florian,
>   Nice description. Thanks.
>
>   So the semi-interesting test (to me anyway) of this technology
>would be to send a known signal through jack_diplomat, over the
>'off-time' interface, route it back externally, receive it on the
>off-time interface and retime it back to the original time source. How
>much distortion occurs?

I wanted to try that but never got round to it for some reason.
I am perhaps more interested in knowing what amount of latency
difference we get when recording from the same source through
two different sound cards, and then routing one soundcard into
the jackd of the other.

guitar ----+----- hw:0 --- jackd --jack_diplomat -\
            \---- hw:1 --- jackd ------------------===== ardour

Attempting to actually mix the two channels would probably
result in a nice phasing effect because the latency introduced
by jack_diplomat currently oscillates (see below).

If you want to see if noise is added by jack_diplomat, theres no
reason why you couldnt go forwards and backwards through
jack_diplomat, since it supports arbitrary channels in both
directions, and compare the returning signal to the original.
This would obviously double the magnitude of any averse effect
on the signal.

I have tested various generated waves, e.g. sin, saw tooth,
square, generated on one jackd and sent to another jackd, and
heard/recorded from there, and also closely looked at the
resultant waveform with a wave editor.  The distortion due to
the resampling is audible only with a very discontinuous wave,
i.e.  saw or square, and would probably be tolerable if the
amount of distortion wasnt oscillating due to the behaviour of
jack_diplomat's dynamic compensation algorithm (which supplies
the 'ratio' parameter to the resampler).

If you're interested about how it works, check the README in the
source package as I wrote in a bit more detail about how it
works at the minute (which is a bit different to how Florian
described, but in some ways his method is better).  This would
explain *why* it oscillates at the moment.


Things that might need to be done to fix the (barely audible)
distortion:

1) Do something better than just linear interpolation when
resampling.  This would remove any distortion, but I don't know
how to do it.  (I had problems with SRC consuming / producing
audio at erratic intervals, which was causing problems with the
flow of audio in realtime.)  This would presumably be done by
providing a drop-in replacement for the simple_src.c code.

2) Redesign the dynamic compensation algorithm (that corrects
for drift / jitter) so that it does not oscillate, i.e. it is
critically damped.  Ideally (as someone mentioned) the ratio
should be pretty constant, up to strange timing problems like
re-ordering of the jack graph and scheduling phenomena on a
loaded system.  This would make whatever distortion was caused
by the sampling constant, and would also mean the latency
introduced by jack_diplomat would be constant.


I spoke with Florian for some time on IRC about this and we had
many ideas, but ideally it would be nice if other people can
actually try jack_diplomat out, *as it stands*, because there
may well be more serious problems than the distortion.  This
needs the jack_server_dir bug fix though.

It seems people are more interested in talking about than
running it :)  Maybe I should make more effort at explaining in
more detail how it work ands what problems there are, if that is
the case.


thanks

-Dave Cunningham


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software) (on distortion)

LGTrader
On 11/7/05, Dave Cunningham <[hidden email]> wrote:

>
> It seems people are more interested in talking about than
> running it :)  Maybe I should make more effort at explaining in
> more detail how it work ands what problems there are, if that is
> the case.
>
>
> thanks
>
> -Dave Cunningham

Well, in my case I plead ignorance (a common plea with me) until just
a few days ago when I heard about it. There seem to be two issues on
my end:

1) Finding a real use for it. Right now it seems a bit of a curiousity to me.

2) Understading how run two Jack servers at the same time. I run
Jack-0.100.5. Probably this supports multiple servers but I've never
had the need.

Than said I probably have good hardware to try it out. If I ran the
on-time server using my on-board sound chip and the off-time server
using my HDSP9652 then I could just loop an ADAT cable and the outputs
come right back in.

So, a little more info on how to actually fire it up would help, but
I've got a lot of other things on my plate at the moment. The easier
you can make it the quicker someone will likely start working with it.

-Mark


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software)

Glynn Clements
In reply to this post by LGTrader

Mark Knecht wrote:

> > > What if for some reason you *want* to run two card at different
> > > frequencies? Say one runs at 44.1K and the other at 48K. What do you
> > > do?
> > >
> > > I find this program conceptually very interesting, although I admit I
> > > don't know what I'd use it for. I also do not have a clue about how it
> > > actually manages to do it's work, being that both cocks are drifting
> > > and their sample rates are unknown. Seems like magic. (I like magic!)
> >
> > FWIW, there was some previous discussion of this back in mid-June:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_id=7524221&forum_id=3040
>
>    Interesting stuff, and I am interested in the overall topic. I
> think making it work 100% reliably might require a bit of black magic
> as I do not see how anyone is ever going to know the exact sample rate
> of any card. As you note in the last response 48000 might be 47999 or
> 48001, but beyond that it might be changing between 47999 and 48001 at
> unknown times.

Essentially, you measure how fast the hardware produces or consumes
data relative to the system clock over a period of time. Dealing with
jitter would involve some kind of filtering, e.g. a least-squares fit
or similar, but there are standard techniques for that sort of thing.

Ultimately, the best solution will require some experimentation, but
Florian seems to be on the case (although I've only briefly skimmed
over his reply).

The general idea will be useful for other things; e.g. network audio,
where you will be receiving data at a rate based upon the sender's
clock, which may differ slightly from your own.

--
Glynn Clements <[hidden email]>


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (alpha software) (on distortion)

Dave Cunningham
In reply to this post by LGTrader
On Mon, Nov 07, 2005 at 11:00:39AM -0800, Mark Knecht wrote:

>On 11/7/05, Dave Cunningham <[hidden email]> wrote:
>
>>
>> It seems people are more interested in talking about than
>> running it :)  Maybe I should make more effort at explaining in
>> more detail how it work ands what problems there are, if that is
>> the case.
>>
>>
>> thanks
>>
>> -Dave Cunningham
>
>Well, in my case I plead ignorance (a common plea with me) until just
>a few days ago when I heard about it. There seem to be two issues on
>my end:
>
>1) Finding a real use for it. Right now it seems a bit of a curiousity to me.

Theres the multiple sound-card potential, and also distributed
jack servers that run on a different clock.

>2) Understading how run two Jack servers at the same time. I run
>Jack-0.100.5. Probably this supports multiple servers but I've never
>had the need.

Certainly noone has written a jack client app (until now) that
connects to two simultaneous jack daemons, because there was a
bug in jackd that prevented this :)

Essentially you give each server a name and go from there, apps
without the ability of choosing a server name can have the
default name of "default" overrided with the environment
variable

JACK_DEFAULT_SERVER=moose qjackctl

There are instructions for all of that in the README file in the
source tree, in fact patching and installing cvs jack is the
only hard part in getting it running...


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (also some weird jack timings)

Dave Cunningham
In reply to this post by Glynn Clements
On Mon, Nov 07, 2005 at 08:45:07PM +0000, Glynn Clements wrote:

>
>Mark Knecht wrote:
>
>> > > What if for some reason you *want* to run two card at different
>> > > frequencies? Say one runs at 44.1K and the other at 48K. What do you
>> > > do?
>> > >
>> > > I find this program conceptually very interesting, although I admit I
>> > > don't know what I'd use it for. I also do not have a clue about how it
>> > > actually manages to do it's work, being that both cocks are drifting
>> > > and their sample rates are unknown. Seems like magic. (I like magic!)
>> >
>> > FWIW, there was some previous discussion of this back in mid-June:
>> >
>> > http://sourceforge.net/mailarchive/forum.php?thread_id=7524221&forum_id=3040
>>
>>    Interesting stuff, and I am interested in the overall topic. I
>> think making it work 100% reliably might require a bit of black magic
>> as I do not see how anyone is ever going to know the exact sample rate
>> of any card. As you note in the last response 48000 might be 47999 or
>> 48001, but beyond that it might be changing between 47999 and 48001 at
>> unknown times.
>
>Essentially, you measure how fast the hardware produces or consumes
>data relative to the system clock over a period of time. Dealing with
>jitter would involve some kind of filtering, e.g. a least-squares fit
>or similar, but there are standard techniques for that sort of thing.

I was initially using the tsc but the noise in the measurements
are such that that degree of accuracy wasnt actually bringing
any benefit, so i switched to clock_gettime which is supposedly
more portable anyway :)  (could there be a problem if the clock
is changed e.g. a cron job using ntp, while using this?)

At the moment it doesnt filter the measurements at all, and
calibrates for a short while before beginning (using a seperate
algorithm for dynamic correction after this point).   You get a
very different average result though, and running it for any
longer is a nuisance, so i'm interested in any statistical
technique that could filter the outliers from the dataset, if
someone can suggest something i can read up on, that would be
ace :)  

>Ultimately, the best solution will require some experimentation, but
>Florian seems to be on the case (although I've only briefly skimmed
>over his reply).

yeah we spoke on irc about this but neither of us knew precisely
how to get a quick and reliable calibration.

>The general idea will be useful for other things; e.g. network audio,
>where you will be receiving data at a rate based upon the sender's
>clock, which may differ slightly from your own.

Apparently the alsa_client from netjack does something very
similar, bridging alsa and jack (rather than jack and jack) but
I haven't looked at the source yet.  The impression I got from
talking to someone (who's nick ive forgotten) on IRC about it,
was that its approach would result in a more erratic resampling
ratio and thus more noise, as it was making one buffer fit into
another, so the best resampling ratio would be about +-3% with a
period size of 32, which must be a noticable pitch shift.
jack_diplomat can deal with partial samples so gets a much
smoother ratio.  On the other hand it would not be as
susceptible to some weird timing problems i've seen, that i
havent found a cause for yet.

Am I right in thinking that in *NO* circumstances should there
be several process() callbacks of one jack server, without there
being any from the other jack server (assuming same period size,
sample rate) without any xruns being reported by the latent jack?

I can imagine that graph re-ordering and other jack_clients
taking more or less time in their callbacks would cause some
irregularity in the compared timings of the two sides of the
connection, but this surely this should only appear as e.g.

"-" is one server, "." is the other

-.-.-.--.-..-.-.-.-.-.

rather than

-.-.-.-.-------------------.-.-.-..................-.-.-.-

but this latter case is exactly what i'm seeing, even with a
simple client where one process() callback (from one jackd)
increments a char, and the other process() callback (from the
other jackd) decrements it.  This *only* occurs while redrawing
qjackctl's "connections" window , e.g. rapidly maximising /
minimising it, or resizing it.  Particularly disturbing is that
florian didn't seem to have this problem at all!  (i'm using ion
(the window manger) which may stress x apps more since its a
rather bizarre keyboard-driven window manager)


thanks

-Dave Cunningham


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: [ANN] jack_diplomat (also some weird jack timings)

torbenh
On Tue, Nov 08, 2005 at 01:20:26AM +0000, Dave Cunningham wrote:

> On Mon, Nov 07, 2005 at 08:45:07PM +0000, Glynn Clements wrote:
> >
> >Mark Knecht wrote:
> >The general idea will be useful for other things; e.g. network audio,
> >where you will be receiving data at a rate based upon the sender's
> >clock, which may differ slightly from your own.
>
> Apparently the alsa_client from netjack does something very
> similar, bridging alsa and jack (rather than jack and jack) but
> I haven't looked at the source yet.  The impression I got from
> talking to someone (who's nick ive forgotten) on IRC about it,
> was that its approach would result in a more erratic resampling
> ratio and thus more noise, as it was making one buffer fit into
> another, so the best resampling ratio would be about +-3% with a
> period size of 32, which must be a noticable pitch shift.
> jack_diplomat can deal with partial samples so gets a much
> smoother ratio.  On the other hand it would not be as
> susceptible to some weird timing problems i've seen, that i
> havent found a cause for yet.

well it was me :)
and i dont consider the current implementation in netjack better.
i only think that the alsa_client has more information to its avail.
so if the alsa_client was using a first or even second order control
loop it should be able to achieve way better results.


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel