<> ## ## ## ## ## Note for original author: ## ## The Ubuntu wiki is a community documentation site, and personalization ## of pages is highly frowned upon. While copyrighting under the GFDL is ## a noble gesture, the contents of this wiki are actually copyrighted to ## Canonical, (at lest as far as I know, see the bottom of the page) and ## is so far incompatible with the GFDL, as Canonical does not really ## specify licensing terms. ## ## Additionally, the purpose of this wiki is to help other users of ## Ubuntu learn how to use their operating system to it's fullest ## potential. It is a not a place to evangelize about free software, e.g. ## promoting donations, and as much as I wholeheartedly agree with you, ## if it doesn't fulfil that primary objective of helping the users use ## Ubuntu, then it doesn't belong here. ## ## Finally this page should be named RecordNowWithFireWire as per the ## wiki styling rules, keep that in mind for future articles. ## Thanks for your contribution, keep up the good work. ## ## Note: I'm thinking this also can apply to USB audio interfaces... ## Firewire devices are not the only ones that get XRuns. ## ## Reply to the editor: ## ## Thank you for making my guide more Ubuntu Wiki compatible. I have ## absolely no problems with the changes you made, on the contrary: I'm new ## here doing my best to fit in, you made my guide work better for the ## Community, and the feedback you gave is very valuable. ## ## About the GFDL, this is an Ubuntufied version of a guide that already ## exists and is released under the GFDL; do you agree there would be ## no problems with the Ubuntufied guide being Copyright Canonical while ## the original guide remains (C) by me and released under the GFDL? ## ## Finally, as for USB interfaces, the problem with the FireWire interfaces ## is that the current drivers don't properly route latency data to Ardour. ## USB drivers do this right to my knowledge, so ardour compensates automatically ## and the steps in this guide aren't necessary. Also, USB drivers don't have ## the bug that changes the latency each time there is an XRUN. ## ## Of course, the real-time related parts of this guide could be made into a ## seperate page along the lines of 'Latency Tuning' or so and linked here. ## = The Linux FireWire Record-Now Mini-HowTo for UbuntuStudio = ''Note:'' This guide makes use of a measurement tool called JDelay that generates a quite unpleasant test signal that might damage your speakers or even ears if you're not careful. Pay close attention to disable hardware monitoring whenever using the tool. There are reminders in these steps below, but ensuring the test signal never reaches your speakers or headphones is still your own responsibility, and I don't offer any warranties. Please make sure you understand this; when you do, please continue. == Introduction == If you already have a Linux digital audio workstation with a Fire``Wire interface set up, it is likely that recording works for you, while the sound might be a bit jittery and out of rhythm. This is because the current Linux FireWire drivers work very well, but have an issue when it comes to their latency being predictable; in other words, your recording software never knows how long it took the sound it is receiving from the microphone membranes to the hard drive, so it can't really align it properly. While you wait for this to be fixed, you can align your sound by hand and start recording now. ''NOTE: This guide has been tested using HARDWARE MONITORING. There is a theoretical suggestion on how to use software monitoring in the appendix, but it is currently not clear how well it works in practice.'' == Preconditions == This guide assumes you already have a Linux-based digital audio workstation set up, and are using the Jack audio server to connect to your FireWire device. Recording already works, but is jittery or out of sync. Ardour 2 works particularly well and is used as an example in this guide, but the guide may apply to other recording software as well, as long as you are using the Jack audio server and a FireWire audio interface. You also need an audio cable to loop an output of your Audio Interface back into an input. === I. Measure your Latency === 1. Connect an output of your audio interface directly back to an input with an audio cable. 2. Get JDelay, a Jack latency measurement tool, with your distribution's package management system. 3. Start the Jack audio server. 4. Start JDelay in a terminal. It will start spewing out a message telling you that it can't hear its test signal yet. 5. Connect the output of JDelay to your audio interfaces output channel you connected the cable with in step 1. Connect the input channel you connected to the input of JDelay. 6. Now that you have a complete loop (JDelay -> audio out -> cable -> audio in -> JDelay) it will start giving you the delay ("Round trip latency") of your audio interface, as measured in audio frames. == II. Stabilize the Latency == At this point, it is likely that the latency will fluctuate quite a bit, which is the jitter you were hearing in your recordings presented to you in numbers. You now have proof that you're not rhythmically challenged after all :) While it's ok that you will get a different latency every time you start up Jack, this latency cannot suddenly change while you are recording. The current Linux FireWire changed their latency every time you start up Jack, and every time there is a Jack XRun (even those that are so slight they are not normally reported by Jack). You will see these when you get a latency change in JDelay. In order to get usable results, you need to be able to stay XRun-Free for at least 15 minutes to get good odds of getting a reasonable take. The first step to take is to get a realtime-kernel. Not a low-latency kernel, and not a pre-emption kernel, but a ''Realtime''-kernel. The most common one features patches by Ingo Molnar and is of the 2.6 series. In Ubuntu Studio, you can do this by adding the following repository to your installation:{{{ deb http://www.texware.it/ubuntu feisty }}} adding the GPG key, and updating the local APT cache,{{{ wget -q http://www.texware.it/ubuntu/feisty/BBA3222D.gpg -O- | sudo apt-key add - sudo apt-get update }}} and install the package {{{ sudo apt-get install linux-realtime }}} One way to do this is with Synaptic; Go to the ''System'' menu in the top left corner, then select ''Administration'' and then ''Synaptic''. Enter your user password. When Synaptic has started, select ''Software Sources'' in the menu. Go to the ''Third Party Software'' tab and select ''Add..''. You will be prompted for a 'deb' line, where you can enter the above. Then click the ''Reload'' button in the main Synaptic window and search for and install the package ''linux-realtime''. Its dependencies will be installed automatically. As a final step, restart your machine; it will automatically boot into the new realtime kernel. To find out more information about the Realtime kernel take a look [[Ubuntu:RealTime/Feisty|here]]. Even so, to stay without the slightest of XRuns it is likely you will have to increase your buffer size as much as you can; 64ms nominal latency is usually a good value. Finally, Florian Schmidt has a list of excellent latency tips you can try if you are technically minded. http://tapas.affenbande.org/wordpress/?page_id=40 == III. Align your Audio Tracks == Now that you have virtually xrun-free operation, all you need to do is record. Here's how to do it, compensating latency by hand: 1. Shut down hardware monitoring on your card, and start up and connect JDelay. Make a note of the latency. Turn hardware monitoring back on again. 2. Record your track. Keep plugins disabled while you're recording. 3. Turn hardware monitoring back off, and start up and connect JDelay again. If the latency is still the same, you've got a winner. Congratulations! If you don't, you will have to re-record the track. Sorry about that... if this happens too often, improve the performance of your system until it doesn't any more. 4. Use your digital audio workstation's 'nudge' feature to nudge your recording backward by the amount of frames JDelay reported. (Backward means your track will play earlier.) In 'Ardour', you do this with the nudge clock: it's a small box with green numbers on the right hand side of the tool bar, with two small arrow buttons to the left of it. First you right click it, and select 'Frames' in the 'Mode' menu. Then you enter the value reported by JDelay here, and click the '<' (left arrow) button. 5. Play your track and see if it sounds as rhythmic as it did playing it. If it does, congratulations, you have a correctly aligned take of your recording. ''-- biased content --'' ''If your digital audio workstation doesn't support nudging tracks, this is your opportunity to start using Ardour 2. Not only will you have a quick solution to your current problem, you will also join an amazing community of wonderful people, and be able to witness true dedication and passion, which is as precious as life experience can get. So head over to ardour.org and download your copy of the brand new and polished Ardour 2 for your distribution!'' ''-- end of biased content --'' == Technical Explanation == Normally, when you record something with a Digital Audio Workstation (DAW), it automagically aligns your tracks according to how long it took you to hear the accompaniment signal (a click sound, what's already recorded, or both), and how long it takes to reach. If you are using hardware monitoring, your sound card feeds you the signal instanteniously (for practical purposes), while your DAW gets it after the one way latency (theoretically 50% of the round trip latency you measured, or the time the signal takes from your Microphone to to the hard drive). The accompaniment signal also takes a one way latency, from the hard drive through your output to your headphones. While recording, your DAW needs to wait a full round trip latency until it gets a signal: Out to your headphones, in through you and your microphone. Since the latency information given out by current firewire drivers is zero, you will get a correctly aligned audio track if you compensate by a full round trip latency, which is the same thing measured by JDelay. (In this case, the connection cable takes the place of your headphones, you, and the Mic). Theoretically, using software monitoring, you should compensate by 50% of the round trip latency; however, you would have to get quite low latency values that still produce no changes in JDelay in order to be able to use it at all. Also, it is not known whether the one-way latency on the way in is the same size as on the way out, or how large the difference is. It is currently not clear if this is practical or not.