hiho
> [email protected] wrote:
> > h2 as slave
> > (song mode)
> > + no double hit at start. (start impulse from h2 or ardour)
> > + follow correct tempo changes from master (ardour)
>
> Actually, I'm getting double-hits at start after a few +/- button tempo
> changes.
>
> > (song mode)
> > h2 as master
> > + no double hit at start. (start impulse from h2 or ardour)
> > + no jumping in timeline on tempochanging during playback.
>
> Yes, but...
>
> >
> > so imoh,
> > we can remove the whole getArdourTransportAdjustment function. because
> > ardour 2.7.1
> > and 3 , qjackctl(transport buttons), and seq24 produce no double hit
> > anymore.
>
> If everyone else agrees that our users only plan to use the H2 transport with
> Ardour 2.7.1 and 3.x... then yes, let's take out the transport adjustment.
yes, imo people who build and use actually versions of h2 also do this also
with other software.
also, ardour 2.7.x is in this moment standard in most distribution's. so i
think it's ok when h2 0.9.4 maybe in 1 - 9 month work stable with this and
newer versions.
> > only time master will need on two places - getBufferSize() what is the same
> > than
> > getArdourTransportAdjustment.
>
> No. This is wrong.
>
> There should be no buffersize correction. Frame=0 should be 1:1:0... not
> Frame=getBufferSize(). Any sort of buffersize correction like this is *not*
> conforming to the transport and is working around some other bug.
>
if you interpret the code you will see that bbt 110 will set on 0 - buffersize.
that produce a negative value.
hmm?. the function getArdourTransportAdjustment() returns getBufferSize().
so what is wrong if i say it's the same. i write "-" get buffersize and not =
get
buffersize. i only relpace getArdourTransportAdjustment() with getBufferSize().
because imo, this pref. option is deprecated and what do exactly the same thing
but without test the pref. settings!!
and i remove this buffersize offset in slave function. so frame 0 = 0 and not 0
- buffer offset. what works correct for the moment.
> I did some transport auditing, and find that Hydrogen (as transport master)
> isn't working right at all -- independent of audio. I wrote a JACK Client
> that
> just observes the jack_position_t that is being fed to all the JACK Clients
> (see
> attached). Here's what we get with your patch:
>
sorry but what mean all the output? and when you get it? after tempochange? or
after start?
also sound card samplerate is never exact. what means samplerate is a product
from any divider
from sound card quartz oscillator (if they have already one). so what can i do
with usecs and fps which are not exact? and also sampler.cpp compute all output
stream in the buffer size time.
did your simple client incorporate this? don't misunderstand me but i try to
learn how the timing function works.
in moment i think to get a sync start h2 and other clients or masters always
need (or have to use) this given buffersize to compute the output.
so if h2 plans to start the transport it must send a correct startframe. e.g to
ardour. and that ardour can begin transport exactly h2 have to wait one
buffersize. because ardour need and use this time to compute the right output.
so if h2 is master hydrogen have to correct the "internal" transport to
startframe - buffersize. if h2 is slave and you start also transport from h2
all exact information will compute in master this includes also the buffersize
offset. so imo, this will work correct in all ardour >2.7.x. i don't know the
sample function in ardour. but i think this function s really complex. to
compute all the things you can do in ardour.
the other way to handle a exact sync is to send only a whatever control signal
to
all clients and than after one period buffersize all clients and master start
or do whatever control signal
will send. but this method will cost 2 periods of buffersize. one period for
sending the signal from any client or master to any clients or master. and a
second period to sync the output of all the client and master sample engine. so
imo, this is not the way how jack transport work. imo, in moment to sync all
apps will only cost 1 periode buffersize from the trigger moment. what
implement to compute the offset in one of the apps. mostly master app.
my patch use buffersize offset as master and "no offset" as salve
i test with ardour, qjackctl, seq24 and my ears...? (to hear this offset i use
big buffer size values >= 1024 and 4 periods.)
and there it works perfect! what means....
* no double hits at start slave and master
* no segafault
* working tempochange
> usecs=179033476580 fps=48000 frame=0 bpm=110.4 B:B:T=1:1:0 bbt_offset=0
> usecs=179033497885 fps=48000 frame=1024 bpm=110.4 B:B:T=1:1:0 bbt_offset=0
> usecs=179033519235 fps=48000 frame=2048 bpm=110.4 B:B:T=1:1:40 bbt_offset=0
> usecs=179033540554 fps=48000 frame=3072 bpm=110.4 B:B:T=1:1:48 bbt_offset=0
> usecs=179033561939 fps=48000 frame=4096 bpm=110.4 B:B:T=1:1:56 bbt_offset=0
>
> Notice that ticks 0 and 1024 are both 1:1:0, and that 2048 jumps to 1:1:40.
> I
> would expect the ticks to go 0, 8, 16, etc.
>
> Here's rev 858:
>
> usecs=179454108209 fps=48000 frame=0 bpm=120 B:B:T=1:1:0 bbt_offset=0
> usecs=179454129526 fps=48000 frame=1024 bpm=120 B:B:T=1:1:0 bbt_offset=0
> usecs=179454150858 fps=48000 frame=2048 bpm=120 B:B:T=1:1:52 bbt_offset=0
> usecs=179454172379 fps=48000 frame=3072 bpm=120 B:B:T=1:1:60 bbt_offset=0
> usecs=179454193586 fps=48000 frame=4096 bpm=120 B:B:T=1:1:68 bbt_offset=0
>
> ...not much better.
>
> What's more... the tick count is usually 8 ticks per period. But, with your
> patch we sometimes get a period with only 4 ticks (1:2:76 -> 1:2:80):
do you read the jack transport bbt and jack transport frames. because h2 ticks
from jack time master are not the same than h2 internal transport ticks.
so maybe the ticks are not correct. if ardour is master the ticks sometimes
bigger than
1800 betwen 1 beat to the next beat. i think the ticks have no effect for
transport
localisation. only correct frames and bars and beats. and the frames are
correct. 33792-32786 = 1024 in a nearly same delta usec than before and after
this tick error. of course
i am wrong if your displayed frames are not the jack transport frames. also all
usec values differ around +/- 300 usec.
>
> usecs=179034095196 fps=48000 frame=29696 bpm=110.4 B:B:T=1:2:52 bbt_offset=0
> usecs=179034118910 fps=48000 frame=30720 bpm=110.4 B:B:T=1:2:60 bbt_offset=0
> usecs=179034138749 fps=48000 frame=31744 bpm=110.4 B:B:T=1:2:68 bbt_offset=0
> usecs=179034160514 fps=48000 frame=32768 bpm=110.4 B:B:T=1:2:76 bbt_offset=0
> usecs=179034181174 fps=48000 frame=33792 bpm=110.4 B:B:T=1:2:80 bbt_offset=0
> usecs=179034201904 fps=48000 frame=34816 bpm=110.4 B:B:T=1:2:88 bbt_offset=0
> usecs=179034223196 fps=48000 frame=35840 bpm=110.4 B:B:T=1:2:96 bbt_offset=0
>
> This happens regularly. Some other patches may do this, but I didn't see it
> with rev 858.
>
> In contrast, I get this from InConcert:
>
> usecs=180994287332 fps=48000 frame=0 bpm=120 B:B:T=1:1:0 bbt_offset=0
> usecs=180994308692 fps=48000 frame=1024 bpm=120 B:B:T=1:1:15 bbt_offset=23
> usecs=180994330006 fps=48000 frame=2048 bpm=120 B:B:T=1:1:30 bbt_offset=47
> usecs=180994351333 fps=48000 frame=3072 bpm=120 B:B:T=1:1:46 bbt_offset=5
> usecs=180994372664 fps=48000 frame=4096 bpm=120 B:B:T=1:1:61 bbt_offset=29
>
> (...not that InConcert is a pillar of stability and reliability... but... you
> get the point.)
>
> *sigh* I'm not sure what to do. :-/
>
> I'm backing out rev 851 to find a better solution.
> Peace,
> Gabriel
also peace wolke :-)
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Hydrogen-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
