Changing the sample rate in version .99

How is the sample rate changed in Version .99? I have set both qjackctl and Envy24ctl at 88200 and told Ardour that Jack is time master and tried positional sync as “sync with jack”. I created a .asoundrc file for alsa with the code:
pcm.rate_convert {
type plug
slave {
pcm “hw:0,0”
rate 88100
}
}

Which was the only reference I found on the ALSA site to sample rate. But I sure could have missed others. I have a slew of files created under windows that are at this SR. I’d like to keep them at that rate while using them in Ardour.

System is:
Ubuntu 6.10 Edgy
M-Audio Audiophile 2496
ALSA 1.0.11
Envy24Control
qjackctl
jackd

Ardour runs fine and I can both record and playback. I’d just like to set the sample rate at other than 48000.

Jack sets the sample rate. Changing the sample rate requires you to restart jack. All jack clients run at the sample rate jack runs at. You do not need asoundrc files to set the sample rate.

If jack fails to start at 88200, can you give us the output of jack? That output is visible in the messages dialog of qjackctl, if you start jack via qjackctl otherwise it’s available at the terminal you start it.

further, the “rate_convert” ALSA plugin should NOT be used for this purpose. it exists to “fake” a different sample rate than the hardware can provide. i don’t think that this is what you want at all.

JACK’s ALSA backend has parameters to set the sample rate, and qjackctl’s Setup dialog provides a very easy way to control it.

In qjackctl on the settings page I have sample rate set at 88200. I’ve restarted qjackctl several times and restarted ardour several times. The setting remains on the settings page. Are there any another places that need to be set?

I’ll remove the lines from .asoundrc.

In qjackctl’s status message box, without ardour running the sample rate is blank. Once ardour is started but without a project the sr is still blank. Once ardour is running with a project and jack is started, the sr is 48000. The setting page of qjackctl still shows 88200.

Even with jack set to 88200, when starting a new project in ardour the new project dialog says the project will be at 48000.

The only lines of note in qjackctl “messages” window is:
“12:45:39.109 Could not open ALSA sequencer as a client. MIDI patchbay will be not available” I don’t have a MIDI sequencer so the line makes sense.

One other thing, and I don’t know if it is significant, is I can start qjackctl fine but if I hit the “Start” button without ardour running it stops right away saying it could not connect to jack server as client. However, I don’t get this message if ardour is running before I hit the start button.

Actually, it looks like I need to try to decipher the Jack site’s documentation. As of now, it means very little to me (new linux user). I didn’t really want to get into weeks of configuring just to run a program. I really like to just make some recordings utilizing some of the tracks I’ve recorded with Ableton’s Live. I’m trying to get away from Windows.

If you start jack from commandline with these options:
(instead of hw:1 you might need hw:0 or hw:2 or whichever number your soundcard has)

jackd -d alsa -d hw:1 -r 88200

Then jack returns something like that:

jackd 0.102.29
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details


JACK compiled with System V SHM support.
loading driver …
apparent rate = 88200
creating alsa driver … hw:1|hw:1|1024|2|88200|0|0|nomon|swmeter|-|32bit
control device hw:1
configuring for 88200Hz, period = 1024 frames, buffer = 2 periods
ALSA: final selected sample format for capture: 32bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit little-endian
ALSA: use 2 periods for playback
jack main caught signal 2
no message buffer overruns

If you post your output, we might figure out if something is wrong with jackd or your soundcard (or maybe qjackctl).

Here is the output:

jackd 0.101.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver …
apparent rate = 88200
creating alsa driver … hw:0|hw:0|1024|2|88200|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 88200Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback

**** alsa_pcm: xrun of at least 13.659 msecs

**** alsa_pcm: xrun of at least 4.964 msecs

**** alsa_pcm: xrun of at least 4.203 msecs

jack main caught signal 2
no message buffer overruns

Does that tell you anything?

It seems there is no problem with jackd setting the sample rate to 88200.

Try to connect ardour with that jack session and see if it gets the samplerate (only for that, it won’t be useful for working with it).

With this jack session, Ardour now shows 88200 with 11.6 msecs latency. I see that the “frames” or samples, as some call them, can be set also. In Ableton I used 512 samples and that gave me a very good latency number. With jack at 512 Ardour shows 5.8 msecs, which should work well.

So why doesn’t qjackctl do this? Will I have to run the jackd command with these parameters from a terminal every time? If so, can a script be written to automate this? Is there a jack config file I can put them in?

Also, the terminal windows shows a continuous stream of xruns while jack is running. Are these of concern?

So why doesn’t qjackctl do this?

Don’t know because i don’t use it. Maybe somebody knows.

Will I have to run the jackd command with these parameters from a terminal every time? If so, can a script be written to automate this? Is there a jack config file I can put them in?
You can write them to an own script.

Write a file like this:

#!/bin/bash
jackd -R -P 80 -t 1000 -u -d alsa -d hw:0 -p 512 -n 2 -r 88200

(replace “jackd” with “jackstart” if you can’t get realtime priority and still get xruns)

Maybe place it in “~/bin/jackstart88.sh”.

Then make it executeable:

chmod +x ~/bin/jackstart88.sh

And you can test it with:

~/bin/jackstart88.sh

or when the path is set just:

jackstart88.sh

Also, the terminal windows shows a continuous stream of xruns while jack is running. Are these of concern?

Yes, they are buffer overruns which means that you lose audio data, one result are cracks in the recording/playback. When jack runs with realtime priority and a buffer big enough they should not appear.

If you still get xruns and don’t need very low latency, you could increase the buffer to “-p 1024” or even “-p 2048” and “-n 3” or “-n 4”. But these values don’t work with every card.

Thanks, I’ll give that a try.

As for latency, I’ll have to experiment. I usually lay down a track then record the next track while listening to the first. So latency is an issue. I haven’t tried recording much yet, since I just installed ardour a couple days ago. I had excellent results with LIVE in windows using those parameters. However, I don’t know how much the OS gets in the way of the audio in Linux, so I may not need the 512 and can use higher. It looks like getting the lowest latency possible without xruns is the target.

Hopefully, tonight I’ll get a chance to tackle this. I’ll post back with the results.

If anyone has any thought on why qjackctl isn’t setting the sample rate, I’d like to hear it.

btw, “jackstart” is ONLY for 2.4 kernels patched with the “capabilities enabling” patch. it should never be used on a 2.6 kernel system - it will do absolutely nothing.

Sounds as your qjackctl isn’t working at all. You do press the “start” button to start jackd, right? Qjackctl is not configured to start jackd as qjackctl starts up.

When you press play, the “display” between the stop, status and quit, setup buttons should light up and read “Starting” and then “Started”.

Does this work for you like I described it?

No it doesn’t. I get “Starting” then it stops with the error message “Could not connect to JACK server as client. Please check the message window for more information.”

Here is what the message window says:
“23:39:54.982 Startup script…
23:39:54.982 artsshell -q terminate
23:39:55.347 Startup script terminated with exit status=256.
23:39:55.348 JACK is starting…
23:39:55.360 jackd -v -R -dalsa -r88200 -p512 -n2 -D -Chw:0 -Phw:0 -i2 -o2
23:39:55.378 JACK was started with PID=18111 (0x46bf).
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_alsa.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_dummy.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_oss.so
jackd 0.101.1
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
server `default’ registered
loading driver …
apparent rate = 88200
creating alsa driver … hw:0|hw:0|512|2|88200|2|2|nomon|swmeter|-|32bit
control device hw:0
configuring for 88200Hz, period = 512 frames, buffer = 2 periods
ALSA: cannot set channel count to 2 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
registered builtin port type 32 bit float mono audio
required capabilities not available
capabilities: =
new client: alsa_pcm, id = 1 type 1 @ 0x8058bc0 fd = -1
starting server engine shutdown
freeing shared port segments
stopping server thread
23:39:56.219 JACK was stopped successfully.
23:39:57.718 Could not connect to JACK server as client. Please check the messages window for more info.”

I tried it setting the channels to 1 and got the same message with 1 in place of 2 and jack stopped. With zero channels it stays running and ardour is recording. Seems odd that zero channels would work but it seems to. it must start counting at zero. Both stereo channels are working. The sample rate is correct (88200) and the latency looks good a 5.8 msecs. No xruns in the message window. Looks like that could have been the problem. Thanks, to you and everyone that contributed.

Any other thoughts? Does this look like all is well?

There’s the problem.

ALSA: cannot set channel count to 2 for capture ALSA: cannot configure capture channel

You cannot use exactly 2 channels.

Alsa should sort it out by itself but apparently it doesn’t. You can try to set the number of input channels higher. It only works for me on an Phase88 also with envy24 chip, when i use 12 channels (8 analog input, 2 spdif, 2 intermal mixer).

You might have to try every number between 4 and your number of inputs plus 4 until you find the right one.

Then it will complain about the playback channels, because of the same problem. For me playback channels are 10. Try to set them as well and jack should start running.

And this might be another one, but i’m not sure.

required capabilities not available capabilities: =

This means that the old capability module isn’t working and maybe the new one doesn’t either. You could check that (if jack is running) with

ps -C jackd -cmL

That should return two threads that have “FF” scheduler instead of “TS”. If all have “TS”, you don’t have realtime, which will lead to xruns.

  1. there is generally no good reason to try to control the number of channels. just let JACK use all the available channels. it was probably a mistake to make the option to ask for less channels than actually exist so visible.

  2. messages about “capabilities” means that jackstart is being used and it should not be used on anything but a 2.4 kernel patched to enable capabilities. i very much doubt if anyone here is using 2.4.

  1. I was suggesting the first because without parameters on channels his jackd started with zero channels.

    hw:0|hw:0|1024|2|88200|0|0|nomon|swmeter|-|32bit

Maybe it’s a problem with the old version of jack or a misconfiguration of alsa?

  1. You’re right about that it should not be used anymore.

If i remember right, this module is still available. In the standard kernel of edgy. Maybe jackstart was used or jack in ubuntu was compiled to use this module (what i doubt).

Anyways using qjackctl seems to be a bad idea.

You should definitely not specify -i2 -o2 with an ice1712 card, just let jackd work it out by itself as Paul suggested. If you want to see how many channels are running you can use jackd -v option. You’ll probably see 2 input ports and eight output ports (the eight outputs can be sent to the Audiophile’s hardware mixer if required, but I wouldn’t bother as Ardour’s mixing is better quality).

BTW latency shouldn’t be an issue when overdubbing. You can monitor the track being recorded with `zero’ latency by routing the input to the Audiophile’s hardware mixer along with the playback from Ardour’s master outputs. I’ve been using this technique for a long time with my ice1712 cards with no latency problems at 1024 frames/period. Low software latency is only required for MIDI etc., if you have zero latency hardware monitoring like on the ice1712.

Another thing:

/usr/lib/libjack0.100.0-0/jack_alsa.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_dummy.so
getting driver descriptor from /usr/lib/libjack0.100.0-0/jack_oss.so
jackd 0.101.1

You have libjack0.100-0 and jackd 0.101.1, ie. different versions. Could that be one of the problems?

required capabilities not available
capabilities: =

I seem to remember seeing this message with an earlier version of jackd (0.97 ?) even when jackstart wasn’t being used. IIRC it was a bogus message and it got fixed, but I can’t remember when.

jackd -v -R -dalsa -r88200 -p512 -n2 -D -Chw:0

Instead of the above I’d suggest:
jackd -R -P80 -dalsa -r88200

Don’t forget to specify the -P80, which sets how high a realtime priority it gets. It defaults to -p1024, -n2 and hw:0 for both playback and capture so you don’t need to specify those.
You should use the largest buffer size possible for
reliability (which is 1024 for ice1712) - remember you have zero latency hardware monitoring.

jrigg - thanks for catching the clashing JACK versions.
this is almost certainly the cause of the problems being reported with qjackctl.

we are slowly working out how to avoid these issues, but for now, it is almost never going to work to have two versions of JACK installed. the typical case occurs after installing an (older) version of JACK via a package management system, which ends up in /usr/bin and /usr/lib, and then later installing from source which ends up in /usr/local/bin and /usr/local/lib.

one of the two versions of JACK that are installed needs to be removed. removing the packaged one is probably easier and closer to what you actually want.