[email protected] wrote: >> 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.
Sorry, I wrote that in a somewhat intimidating manner, didn't I? What I mean is this: if we all agree to *not* support Ardour's bug, then I'm OK with taking it out. However, I don't agree to doing any buffer offsets -- unless we can turn them off. > 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. The problem is that adding or subtracting any offset violates the principles of using the transport in the first place. The only Right reason for doing it is for latency compensation. There should be ZERO latency between H2 and Ardour. Transport frame 0 in H2 is transport frame 0 in Ardour. If not -- somone is cheating. The buffer offset says that frame 1024 in Ardour is frame 0 in H2. This is wrong. (That is, if you start jack with 1024 frames/period.) > sorry but what mean all the output? and when you get it? after tempochange? > or after start? It "records" the transport state whenever it is rolling. It doesn't care about tempo changes or anything. When someone presses PLAY, it records. When someone pressed STOP, it waits. > 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. Samplerate has nothing to do with it. You probably know that whenever JACK does the process() callback, all we care about is the next nFrames samples. We don't care about the oscillators in the hardware, or what the time on the wall clock says... we just care about reading or writing the next nFrames samples. The only reason why we care about the sample rate is so that we can resample our waveforms. Usecs is simply provided by the JACK server in the jack_position_t.usecs field. All my little test program does is record what that value was. I included it because there may be cases it helps to understand what's happening in the data (but none of these cases really benefits from usecs). > 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. No, this is handled by the transport controls. Whoever calls jack_transport_locate() decides what the start frame is. Hydrogen and Ardour are supposed to play whatever happens at frame # jack_position_t.frame. (In other words, H2 and Ardour should have perfectly synchronized frames: 0, 1024, 2048, etc...) > 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 Did you know: There is *no* callback whenever the transport master CHANGES? If H2 is the transport master... but Ardour takes over -- there is *no* notification of the change. So, if Ardour takes over as master... but H2 still *thinks* he's the master --- we're screwed. Right? We're making decisions based on who's controlling the transport. (I discovered this in the last few days.) We're not supposed to care who the transport master is. We're not supposed to make decisions based on who's controlling the transport. >> 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. Hydrogen was the transport master for this test. The BBT given is whatever Hydrogen wrote to the jack_position_t struct. Hydrogen wrote bpm, bar, beat, and tick. (H2 doesn't supply bbt_offset, so it's assumed 0, per the Jack docs.) One would expect that BBT changes at an even pace if the tempo is not changing. Hydrogen does not do this at startup. > i am wrong if your displayed frames are not the jack transport frames. also > all usec values differ around +/- 300 usec. usecs is supplied by the JACK server. >> Peace, >> Gabriel > > also peace wolke :-) :-) -gabriel ------------------------------------------------------------------------------ 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
