Hi all, hi Rui and a special hi to the 64 Studio developers :) it seems to be that we have figured out a temporary solution to handle timing issues. It's far away of being perfect, but it might be good enough to make music with Linux, when using external and internal sources together on my machine and perhaps on some other machines too.
The only problem is, that for Qtractor this only can be done with the latest CVS version. But I can't compile it with the needed DSSI support, because of the missing libjack0.100.0-dev package for the actual JACK2 of 64 Studio, that's needed for dssi-dev. It's not sure if it really will be fine, but likely it is fine. I hope for 64 Studio 3.0-beta3 the missing JACK packages will be available again as soon as possible. A package for Qtractor's CVS version would be a solution for me. Be that as it may, even for a 'bad machine' like mine Linux seems to become usable for rt-audio plus rt-MIDI, at the least when 3.0 is released, assumed that there will be no new issues that will make it incompatible again, e.g. the try to bring together rt-Linux and bread-and-butter-Linux. I'm in cheerful spirits :). Hopefully more coders will take care of machines that aren't perfect for Linux. Here's the answer to your mail Rui, I answered without reading the whole mail before ;), maybe you can prioritize an 'offset' option when you program, I guess this is a lack not only for Linux: Rui Nuno Capela wrote: > On Tue, June 23, 2009 05:22, Ralf Mardorf wrote: > >> Hi all, hi Rui :) >> >> >> the details are for those who wanted a less vague report from me, I guess >> you Rui can skip most of the text. >> >> I'll start with the résumé. After editing the rtirq configuration and >> using PCM playback as timer source for the sequencer, jitter might be no >> longer a problem, but the compensation of the latency is bad. I can't say >> this for sure, because I didn't finished the test, by checking the wave >> files using Audacity and because there were no DSSIs as reference. >> >> > > awe. > > glad you found that using a pcm slave timer keeps midi jitter to sane limits. > > but let me remember that it might be just so in your particular setup > only. for instance, on my opensuse boxes, one quad-core desktop and one > dual-core laptop, both low-range intel based, 32bit and 64bit > respectively, i just happen to get best results with the default system > timer (1000hz) using latest 2.6.29.5-rt21 than with any pcm timer. having > hrtimer is even better but not that it makes any big difference when peak > jitter is already under 100us, which is pretty good enough to all midi > things around here ;) > Among other distros I still have a Suse 11.0 and a Suse 11.1 release candidate installation. Rt-audio seems to be better with 64 Studio, but the latest Suse I tested with rt was 11.0 and I guess without rtirq. Maybe it's because of my hardware. I didn't practise enough with my Windows installation that I installed to check if my hardware is fine for this OS, so I can't say if it's a problem when using Linux or if it's a problem in general. Less usage of Windows let me suppose that on my machine it's a problem caused by Linux. I know many people having the same trouble when using Linux, but they have no trouble when using Windows. I know one woman who has delay when using Windows. I asked her to test Linux, but unfortunately she won't install Linux. Assumed that the troubles are caused because my mobo isn't fine with Linux for rt-audio, what can I ask ASUS to do. Are there any outputs I can hand in as a bug report to ASUS? > what we have now is a steady, constant delay or absolute latency. sorry to > tell, you cannot escape that. it will be always present and it is > obviously predictable to be worse when dealing with external equipment. > I asked to include an offset option for tracks to sequencers, e.g. to Rosegarden. Can you add an offset option to Qtractor? Just drag'n'drop clips to the grid doesn't fit the delay issue, because it's too inaccurate and even if it would be accurate it's not handy to do this. Using clips that starts and ends at bars is better for the work. It would be good to have an option to set offsets in w.xyz ms steps to compensate the latency optimized to the used hardware, as long an automatically compensation isn't fine with every hardware. > now the bomb drops: qtractor has no latency compensation of any genre. > :D This isn't a disadvantage. Latency compensation can be bad for any OS. The better way seems to include offset options for tracks. Old versions of Cubase had this function, while latest versions don't support this any more, but those versions at least have the option to set an offset to clips (parts) and for VSTs. It would be good to include an offset function to Qtractor. > that is to say that if you're bouncing or recording two audio tracks > simultaneously from two distinct triggered sources, take the example of > one human guitarist playing and following the drums bounced from a midi > track, the resulting recorded material will be out-of-sync when played > back in qtractor. the recorded drums will certainly be in delay relative > to the guitar track. > > the only way to workaround or compensate this effect is about to adjust > the audio clip position or offset manually. I'm reading your mail and answer it step by step, I should have read the whole mail before ;). Yes, an offsets would be good. > actually this is what should > be done automatically if we do know the precise and absolute delay in > advance. but i have a hard time to figure it out for every possible case. > one could add a custom track property for just that, might be an idea i > guess and i know that sort of solution has been mentioned before. > :) It's not only good to compensate latency, but also to stress the rhythm group. In the 80ies it was a standard to give drums a negative delay, although the drums were in time without giving negative delay. It will give stress to the groove, comparable to syncopation. > please, don't confuse this kind of delay compensation with automatic > plug-in delay/latency compensation, which qtractor doesn't have either but > can be found in ardour to some extent and in the comercial sequencers out > there. qtractor is slowly evolving though ;) > As I have written before, for Cubase e.g. they have taken away the option to do this for tracks, even if it's still possible to set an offset to clips (parts). It would be great if you can add it some day to Qtractor. For the moment I'll try to fix it by drag'n'drop. This was a PITA for Qtractor, when I made my 'real' test song (where I not only gave 4 to the floor), because when I copied regions of clips the relative distance between the clips snapped unwanted to the grid. I din'd test it with the CVS version, but you said that you fixed that, so I only need to get the CVS version with DSSI support :) to have a temporarily solution to handle the delay. > now back to subject at hand: the good thing with all this, is that midi > jitter minimization seems to have been addressed with the new timer > options and that's really the good news. > > ain't that so? > It is :)))))))))))))))))))))))))))))))! > cheers > For the time being I have a last question to you Rui. Is there a special source from where I should get the VST dependencies? Sometime ago I included VST to a Linux application without using it and as far as I remember I had troubles to find the needed header(s) and when I found it, there was still the question which version to use. I guess the VST stuff needs to be added to the source directory of Qractor? I didn't take a look right now, but last time I did it, the VST stuff wasn't available on the Cubase homepage any more, I got it from somewhere else. Thank you for your effort. I'll inform you if I should have made a song by Qtractor and if I should hit upon bugs. For now I guess there's nothing more you can do. Cheers, Ralf PS 1: More information about IRQs might be something that's still missing. Would it be a help to disable the network, PPPoE when making music? What about issues by a shared memory for framebuffer for on-board graphics? Etc.. PS 2: Load is another problem on my machine (and my old machine too, that's why I bought the new board and CPU) and this definitive only with Linux. How can load be avoided? E.g., will there be a higher amount of data within JACK and ALSA for 96KHz than there will be for 48KHz or for 16Bit than there will be for 24Bit, or is it within JACK and ALSA handled by the same data flow? -- Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg "Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg _______________________________________________ 64studio-devel mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-devel
