Ardour not recognizing Audigy Drive input

I have a SB Audigy Platinum, which comes with a 5.25" “drive” that goes in a drive bay. It provides several inputs and outputs, so I thought it would be handy for recording. I set up Ardour, and Jack does run just fine, but when I go to set up the inputs I don’t show any alsa_pcm inputs at all, just ardour inputs. Furthermore, when I try just setting those as my input for a track, I get some errors AUDIO ENGINE: Cannot connect xxxx to xxxx for any input/output I set. I plugged my guitar straight into the Line2 input on the drive panel, and I can adjust levels in kmix, and I can hear the guitar just fine through the speakers. I just can’t figure out how to set this as a recording source. In kmix, I have a Line2 for an output, and I can change the level of the guitar input, though the line2 input level doesn’t seem to do anything. Any thoughts as to how I can get this set as my recording source? I tried before with audacity and couldn’t get the input recognized there either, I’m getting really frustrated. Any help would be appreciated.

Sorry, haven’t been around to post lately. Yes, you are correct about udev, I fixed the permissions issues in that conf file. Everything appears to be working great now, except for artsd playback into alsa. It is very choppy, when I point artsd to use alsa. If I switch it to Threaded OSS it works fine, downside is that it doesn’t work when jack is running. Still looking for the reason that happens.

I’ve been tooling around with ardour and audacity, recording some simple acoustic covers to try it out. Ardour works beautifully.

In the meantime, if you could dig up any info or tips about rlimits it would be much appreciated.

Been busy, but here are some brief notes on my rlimits setup. This is on 10.2 system with 2.6 kernel from current, so it may not apply to anyone else. I would suggest following the general instructions provided by the author, etc, and then, if you still can’t get jack to lock memory try the hints below.

  • the sample /etc/set_rlimits.conf file that came with the version I downloaded hadn’t been updated to reflect the addition of the “memlock” key/value pair; adding it to the config looks something like this:

    ALL /usr/bin/jackd nice=-1 rtprio=70 memlock=59000

    Note that the “59000” is merely an arbitrarily high value (since it’s a maximum) and could probably be much lower - I just haven’t had time to trial-and-error it, since it doesn’t seem that important to keep it low (you want jackd to have all it wants, right? ;).

  • although this was enough to allow jackd to run realtime from the command line, it took some additional tweaking to get it to do so from qjackctl. First, I added qjackctl to the set_rlimits.conf, which solved some problems, but I still couldn’t get jackd to lock memory when launched that way. What finally worked for me was to uncheck the “realtime” box in qjackctl and use as the server path:

    set_rlimits jackd -R

    This is instead of creating a script that launches jackd and using that as the server path, as suggested by one source, which I couldn’t get to work with full realtime privileges.

Hope some of that is coherent - I’m a little distracted at the moment, so if it’s not clear I’ll try to explain better. Good luck!

Thanks for the tip on rlimits. I’ll check that out.

I have figured out what the deal is. Apparently the driver for these cards changed between the kernel versions. The driver was updated to do multichannel capture work. This is possibly why I got all of the whacky routing with 2.4. There’s a doc in the kernel source that I found, and it recommended some new JACK settings to get everything set properly. Following that, I now have 16 inputs, trial and error and I found the right one! So I can record now under 2.6, and there’s no bleedover either.

Now, here’s my question to you. Something must have changed recently with Slack. I keep changing the perms on the devs for the sound. This includes everything in /dev/sound and /dev/snd. But every time I reboot they get reset. This didn’t happen before (years ago). Is there some new trickery going on at boot time?

Second question. My jackd startup, no matter the device/interface I select, complains that it cannot open device “alsa_pcm”. I’m supposing my other issues are related to this, artsd crashes, I get no sound output at all, and jack is forced to start up in capture-only mode. What/where is this device file, and do I have to create it? Also doesn’t happen under 2.4, so it COULD be a change like the above. Any ideas?

Got it working. Turns out I need to learn to read between the lines with kernel docs. I had to set my input and outputs to be 16 in number, then select hw:0,2 for input/capture, then hw:0,3 for playback. After that, I just had to set ardour to record from input 9 for the front panel. Things are looking great now! All I have to clear up now is the permissions change on bootup, and check out that rlimits package to get jackd going in realtime, and I’ll be happy.

The slippery permission issues are probably related to udev, which is what dynamically creates devices under 2.6 kernels, and is something I’m pretty new to myself, but there’s plenty of information out there about it by now, since every other distro has been using it by default for a while already.

I’ll try to post a few notes about my experiences setting up the realtime stuff when I get home from work.

Actually, I’m a moron. I had a misconfiguration with Jack (no connections/routes/whatever set). I am still struggling to learn the ardour interface, still haven’t sucessfully recorded anything. I do get the level bar going up so I know it is getting the input, and I set up a track that I set to recordable, but when I record I still don’t get anything. I’ll figure it out. I am also getting some echo/reverb effect on my guitar, is this a result of the latency, or something built in? I couldn’t find anywhere to disable any echo. If anyone has any ideas I’d appreciate it.

sounds to me like you’re probably hearing the monitor. if so, that’s normal.

To expand on that, you’re probably hearing both the direct sound from your soundcard (which you can usually disable using “mute” on the input channel in alsamixer etc.) AND the signal that ardour is receiving via jack, delayed because of latency. If the latency is enough to create an “echo” effect, you’ll probably want to turn of the ardour monitoring and keep the direct one, otherwise playing a guitar (or whatever) will feel pretty weird. :slight_smile:

Thanks. I suspected it was a result of the direct signal through the headphones added to the slightly delayed by latency signal. To clarify, the Audigy seems to directly send the signal on Line2 (the front panel input) straight to the headphone out on the front panel, regardless of what is going on in Jack or Ardour. That is exactly what you said and reassured me of. I can deal with and get around that later. I just updated that workstation, it had been sitting unused for a while, and so I just installed Slack 11 on it, which is still on the 2.4 kernel. I still need to do tweaking to it and get a new kernel compiled and installed, hopefully that will resolve the latency issues. Thanks again for the responses.

Yay, a fellow slacker! :slight_smile: It happens that I just finally managed to get my jack setup tuned more-or-less to completion, using the 2.6.18 kernel source from slack current compiled on 10.2, as practice for when I rip everything out and install 11.0. The last few details involved a lot of trial-and-error, and using set_rlimits a little differently than the write-ups I found suggested in order to use qjackctl… hopefully I’ll have a chance to gather my notes and present them in a readable format soon, but otherwise if you post questions here with “slack” in the subject, I’ll try to dump any relevant info kicking around in my head…

Haven’t ever used anything other than Slack since the Slack pre-7 days. I have been out of it for a bit with work, but finally got my personal workstation here updated. I’m not certain what the set_rlimits thing is, its been too long since I dove into the guts of a linux system.

I AM still having a couple of issues. One, under the stock bare.i kernel (2.4) ardour works somewhat ok, in that I can set my inputs for a track to the alsa_pcm:capture and it indeed records my guitar input. HOWEVER, it still has that echo, even after I turn down the “Line2” output in kmix. Furthermore, it still has a reverby sound on playback of a track also. I’m not sure what is causing this. Next issue, when I have two tracks, when I set to record on the second track and have something already recorded with the first, the sound of the first gets “bounced down” to the second track as well. I even set the output for track1 to go nowhere, though it seems to be reconnecting my outputs to alsa_pcm:Playback automatically despite my settings in ardour. My track connections are as follows:
Track1:IN=alsa_pcm:Capture OUT=
Track2:IN=alsa_pcm:Capture OUT=
Master:IN=Track1/OUT,Track2/OUT OUT=alsa_pcm:Playback

As far as I understand it, Track1 shouldn’t be bleeding into Track2.

Finally, I don’t know why but I can get recording input under 2.4 but not 2.6. Still debugging that issue also.

Use Alsamixer to manage your capture channels. They’re separate controls not necessarily
bound to the sliders of yer GUI mixer.

You need to enable the IECwhateveritis LiveDrive record and set the level appropriately

The controls in alsamixer are identical to the ones in KMix. I do not have a problem with recording under 2.4, but the same settings under 2.6 do not record in. I’m not certain what issue I’m having that you are referring to.

The set_rlimits utility is what you’ll want to use on a low-latency (kernel built with preemption options enabled) Slackware system to grant realtime privileges to apps like jackd and ardour. From what I understand, most other distros use pam for this purpose, which I know nothing about. Good explanation here:

As for the soundcard issues, you propably need to actually mute the INPUT source in kmix (even though it sounds counter-intuitive, this doesn’t keep the input from getting to the alsa_pcm:Capture ports, at least in my case) in order to only hear the signal as received/passed through by ardour (or any other jack app). If the latency on your system is high, though, this will result in a slightly delayed sound (you’ll be hearing only the “echo”) which is why people put all that work into system tuning. :slight_smile: You can, instead, mute the track in ardour as you’re recording, which should eliminate the echo and allow you to hear the undelayed (simply fed from input>output in hardware) monitor signal, and ardour still seems to do a good job of making the tracks sync up “on tape”. It sounds as though there might be some weirdness going on in the internal routings of your card, though, especially if you’re getting one track bleeding onto another, so you might need to dig into that (make sure only the inputs you’re using are selected as “capture source”, all inputs muted, etc).

As for 2.4 vs 2.6 issues, I didn’t have any, so I don’t know, other than making sure all the snd_* modules that were being used in the old kernel are available/loaded in the new one, particularly the specific driver for your soundcard, etc.