I’m running Ubuntu Studio 9.10 64 bit & things seem to be working but I’m unsure about the latency settings.
In Ardour the settings for latency are like 64 128 256 512 1024 etc… in Jack the latency is 5.8 ms.
What am I missing ? Is the latency setting in Ardour supposed to be the same as the “Frames/Period” setting in Jack?
I ask this because because if I set latency in Ardour any lower than 512 I get pos & clicks when I record.
I just upgraded from U-studio 7.10 & didn’t have this problem with lower latency settings on the same computer.
Latency Question
Ardour just connects to jack, jack is the one with the latency. Jack is the audio backend. You can setup jack with ardour though. Lower frames/persiod numbers in the jack setup window result in lower latencies. A calculation of these numbers is made, so you can read it in ms.
I think you may be confusing the buffer size with the latency in milliseconds. For instance, when you’re running jack with a buffer size of 512, your latency is probably around 10-20 milliseconds. When you change the latency in the menu of Ardour, it sets the buffer size, and you’ll see the corresponding latency change in the main window of Ardour when the operation is done. The pops and clicks you’re hearing are xruns, which you can avoid several ways:
1)use a realtime kernel with realtime permissions for your user (do a quick search of this forum for a howto)
2)use as minimal a system as possible (turn off desktop effects, maybe use a different window manager like fluxbox)
3)check out the pci latency of your soundcard, and set it higher than your other hardware if need be (http://www.sabi.co.uk/Notes/linuxSoundLatency.html)
hope this helps;-)
Thanks for the advice,
I’m running realtime kernel : 2.6.31-9rt but I can’t find any info on realtime permissions.
Another thing I’m not sure about is on the top of Ardour it shows 48K /21.3 ms at startup
yet Jack is set up for 44100/ 5.8 ms. Does the settings for Jack have nothing to do with Ardour?
I don’t want to record at 48k but I can’t find where to change it.
this is really very simple.
All audio settings (sample rate, latency etc) are properties of JACK. If you start JACK before starting Ardour, then these settings are done using whatever method you use to start JACK (qjackctl, cmdline, etc, etc). If you start JACK from Ardour, using Ardour’s “Audio Setup” tab, then you set these properties there, although they still belong to JACK and not Ardour. All displays of these properties within Ardour once it is running reflect the values for the JACK server it is connected to.
There are a few potential complications
- The "latency" shown by Ardour is different from the one shown in qjackctl (its normally half of the qjackctl value)
- it is possible for JACK clients (such as Ardour, but including many other applications) to ask the JACK server to change its latency settings "on the fly". The JACK->Latency menu in Ardour is one way to do this
- Different applications might choose to display latency in msecs or samples.
I feel kinda stupid because nothing seems to work or I just can’t find things.
I tried starting Jack first with 44100 settings at 5.8 ms latency & then started a new song in Ardour.
Still it starts out showing 48k /21.3 ms.
On my old Gusty U-studio with exactly the same Jack settings Ardour starts with 44100/2.9 ms & I have no problems with sound pops or
clicks. I don’t see any “Audio Setup” tab & I can’t find any way to change the 48K setting in Ardour.
I think that may be part of my problem. Isn’t there a way in Ardour to change the recording setting to 44100?
If you create a new session, the session will adapt to the current Jack samplerate. An existing session will try to stick with it´s own samplerate. Ultimately the jack samplerate is the actual samplerate.
@garyed: you are probably using an audio interface that does not support 48kHz (other than via driver software). Because people didn’t like the fact that JACK would just fail to start when they asked for 44.1kHz with such cards, for the last couple of years, JACK simply starts with the sample rate closest to the one that was asked for. What type of audio interface are you using?
The Audio Setup tab exists ONLY if you start Ardour without JACK running, which it sounds as though you do not do. It offers no more power and no abilities not present in qjackctl, its just a convenience.
How did you ask for 5.8ms latency? This sounds like a calculated value …
Paul,
Sorry I’ve been away for while but I really appreciate the help & I’ll try to answer a few things.
The good news is that I was only opening up the Jack Control before starting Ardour & not actually starting the Jack server so that’s why I was still getting 48k sample rate/ 21.3 ms.(My Bad) if I start jack first it shows its running at 44100 & then open Ardour everything works great showing 44100/2.9ms & no pops or clicks.
So really the only problem I have is when I open Ardour without opening up Jack first.
Evidently when Ardour opens up Jack it defaults to 48K.
My guess is that it has something to do with my second sound card or onboard sound that I think runs at 48K
Here’s my setup:
I’m using an M-audio audiophile 2496, but i also have a soundblaster live card installed & my onboard audio is turned off in the bios. Evidently all three sound sources are picked up because cat/proc/asound/cards yields:
0 [M2496 ]: ICE1712 - M Audio Audiophile 24/96
M Audio Audiophile 24/96 at 0xb400, irq 18
1 [Live ]: EMU10K1 - SB Live! Value [CT4670]
SB Live! Value [CT4670] (rev.4, serial:0x201102) at 0x9800, irq 17
2 [V8237 ]: VIA8237 - VIA 8237
VIA 8237 with ALC850 at 0x1000, irq 22
The M-audio is the only one that shows up in Alsamixer & I know the M-audio is what Ardour is recording & playing back with.
Jack is set to use driver[ alsa]
I run qjackctl & in settings I set Frames/Period - 128 , Sample Rate 44100, Periods/Buffer 2 & that puts my latency at 5.8 ms
Also under Server - Driver:alsa
Ardour automaticaly starts Jack every time at start up so I haven’t figured how to start it without Jack though there probably isn’t a good reason to do it except for testing purposes.
I’m running Ardour 2.8.2
I haven’t got my sound working yet in firefox so I’m guessing there’s some kind of Ubuntu-Studio setup that is defaulting to the onboard sound & causing Ardour want to over ride the Jack settings unless I start Jack first.
Gary
@garyed: you can’t run Ardour without JACK.
If you start Ardour without JACK running, then the new session dialog/session control dialog that appears at startup has a tab labelled “Audio Setup” to allow to control the parameters for JACK. If you don’t actually use this dialog, you wll, as you have noted, get the default settings.
If JACK is already running when Ardour starts, this tab is not shown, because we assume that you know what you are doing.
Thanks,
The “Audio Setup” did it.
I just set it to the same settings I’m using in the Jack setup & now it defaults to 44100/2.9ms every time I open a new session.
That’s exactly what I wanted.
Well I lied,
It seems like I’m still getting xruns but not as many.
I raised the latency setting up from 128 to 256 & its much better but still a few after more tracks are recorded.
I’m pretty sure if I raise the latency up it would clear things up but I don’t really want to go any higher.
Maybe its because I’m running the 64 bit version of U-studio & my older version on the same computer is not .
Ardour works flawlessly in Gusty at the lower latency setting…
My cpu is Athlon 64 3700+
I’m also using ext4 instead of ext3 file system too. I’m tempted to do another installation just to see if 64 bit is making a difference.
@garyed: If you are using a soundcard with an ICE1712 chipset then try it in playback or capture only and see if you still get x-runs. I had one of these and it would not work reliably in full duplex mode with some kernel versions. (also caused similar problems in windows with ASIO drivers so its not a problem that’s unique to linux - but in windows you can’t try different kernels quite so easily… )
That’s interesting because I don’t get xruns on my older kernel but I’ve also never had a problem with Windows ASIO drivers either with the M-audio card.
I tried starting Ardour in record mode only but I got an error starting Jack about incorrect parameters.
I spent a long time trying to figure out what was going on when I had problems with my ICE1712 soundcard, this is probably not the right forum for a detailed technical explanation as to what happens within the hardware, but it is a problem that seems to be affected by both the kernel version, specifically the interrupt latency (not to be confused with the audio latency - I mean the time it takes for the interrupt signal from the soundcard to propagate to the alsa driver) - and the combination of PC hardware. In the end I bought a different card and that solved the problem, although my old card is now functioning perfectly well in another PC with other kernel versions…
I may experiment with a different kernel or go back to 32 bit & see if there are any differences.
thanks
Gary
Just a hint, you can set the interrupt latency of all your devices independently, no matter what kernel you’re using. Check out this page:
http://www.sabi.co.uk/Notes/linuxSoundLatency.html
I’ve got several systems running in my house, and I’ve set the latency for the hardware dependant on what these computers are mainly used for. For example, the computer I have in my living room is set up so that the video card gets higher priority than anything else, because it’s mainly used for watching videos (network card is second in line because I also download torrents), whereas my studio PC is set to give the highest priority to the soundcard, as it’s only used for recording/mixing.
Hope this helps…
linux DSP you are correct,
There is definitely a problem with either the Ubuntu kernel or Ardour itself relating to the Audiophile2496 sound card.
I now have 3 versions of Ubuntu studio partitioned on the same HD. 1- Gusty, 2-Karmic 64 ext4, 3 - Karmic standard ext3
All set up the same latency etc…
The only one that i don’t get Xruns on is Gusty no matter how many tracks I run.
@garyed: I think its quite certain that the problem is not with Ardour (or JACK). Ardour doesn’t interface directly with (or care) about your sound card, Ardour just connects to JACK as another client to the JACK audio server. JACK connects to the driver for your soundcard (ALSA, FFADO, or OSS) and finally, the driver (loaded as a kernel module) actually controls the hardware.
This sounds like the problem I was having with my ICE1712 chipset - if that is the case, then its really a problem with the chipset design, that gets triggered by an aspect of the kernel behaviour (windows or linux).
@macinnisrr: I think you may be refering to interrupt priority, which although connected with this issue isn’t quite the same. There are many things you can tweak with regard to PCI settings, that affect the so-called latency (by changing how long a device can grab the PCI bus for etc) but it isn’t quite the same as the time taken for the kernel to process an interrupt from a hardware device which I think is where the problem lies.
The ICE1712 chipset has a shared interrupt for the capture and playback halves of the card, this is triggered when either half needs ‘attention’ - the driver then has to go and read a register in the chip to find out who caused the interrupt.
The chipset also has two internal registers that act as pointers to the internal audio buffers for capture and playback. I could see these drifting out of step with one another which was odd because they are both ‘clocked’ from the same signal. If this happens it means an xrun is guaranteed at some point because it is similar to the two halves of the card running at different sample rates.
It seemed that if it took longer than one sample period e.g. 1/Fs between the interrupt happening and the driver reading the interrupt register, then the pointers would begin to drift.
Unfortunately I don’t have the card that was causing me problems anymore, but I might see if any of the ALSA devs can shed any light on this problem.