I’m not finding a way to get Ardour to recognize my USB mic (Zoom H4) in the Input section for a recording track. It is recognized and works well in Audacity. I have it selected in JACK as the device to use but all I seem to get are the PC mics. I’ve read several posts that say they have an H4 running well with Ardour but no “how - to’s” yet have worked. I’m running Ubuntu Studio in Jaunty. Anyone got any ideas?
texla, if you say Jack throws an error you need to tell us what that is, otherwise there’s no way to help.
Meter Bridge, Patchage, Jack Time Machine all requires Jack (I think) to work, so w/o Jack they won’t start.
Audacity and Hydrogen can use ALSA directly and Ardour starts Jack if it isn’t running.
In what way is the RT kernel slow?? 512MB RAM should work fine unless you want to load big samples in Hydrogen or LinuxSampler. That said, I think I’ve read that the RT in the latest Ubuntu Studio is flawed.
I’d also suggest you use QJackCtl to configure Jack.
SOLVED mostly! thanks Peder, I have the H4 going through the Jack now after running these command lines from this page:
sudo su -c ‘echo @audio - rtprio 99 >> /etc/security/limits.conf’
sudo su -c ‘echo @audio - nice -19 >> /etc/security/limits.conf’
sudo su -c ‘echo @audio - memlock unlimited >> /etc/security/limits.conf’
Plus I added the audio user like it suggested for Jaunty.
It was a Jaunty and Ubuntu fix that was needed - Many are offered out there but this was what got me running.
Peder, as for what is slow when running in my RT kernel, everything. It feels like my memory is being hijacked somehow. The Jack setup I have now, won’t even work with the realtime option selection either so I’m running it without. I was thinking I should wait to get more RAM to try to fix these issues but it sounds like you think I should be able to run basic recording with what I have.
Also, I’ve read some bad reviews of the RT kernel in Ubuntu Studio, too. Now that I’m here can I just run Ardour from the vanilla Jaunty kernel for now to do basic recording (2-3 tracks) ? Or do you think it’s absolutely essential to use RT with Ardour and Jack?
Wow, thanks Pablo and Thorgal - really great info! I will check all this out and be back - really enjoying what I’m hearing from Ardour tracks already and I very much appreciate all the help on this forum.
The H4 has two XLR inputs, and can be used to monitor output as well. I have one, and it saved the day when I was recording my podcast one day. We were using my friend’s Mac as a Cart Player, and suddenly his audio output died and disappeared from his audio config. I got out the H4, set it up as a USB interface, and used the 1/8 inch stereo output to get sound out of the Mac.
for the alsa tab, thats midi stuff…shouldn’t bother you.
hmm, you mentioned recording a mono track. could it be that you have your microphone on the wrong channel then (switch xlr inputs on the h4)? i guess though you checked that allready. you have recording enabled on the mono track? otherwise you won’t see the input. hmm that’s about it. if you want further help, you would have to describe exactly what you are trying to do, step by step.you could also check if other applications can record from the h4 with jack enabled. i think though the problem is not in ardour.
how do you normally proceed when you want to record with ardour?
what you should do is:
- connect h4 to the computer
- start jack with h4 as your soundcard
- start ardour (maybe with a new session)
- create a monotrack
- check if in qjackctl the connections between system capture_1 or/and 2 are going to the ardour_in track_1
- switch recording on in ardour on the monotrack
- see if it works.
sorry i don’t know anything about your experience with audiolinux or linux in general, so maybe those steps are obvious.
I obviously meant “fix” as a shorter way of saying ‘allowing a non-privileged user to run real-time tasks’, hence the quotation marks. Correct me if I’m wrong but I don’t think this is needed if you run a RT-patched kernel.
And as for the RAM answer I didn’t think it was necessary to delve inte the deep mysteries of linux caching and such. I just tried to explain that Ardour in itself isn’t that RAM-dependent.
The limits.conf "fix" is IIRC actually only needed for standard kernels, the RT has this, sort of, "built in".
The limits.conf is not a ‘fix’ It ia a necessity to grant permissions to users/groups to create realtime threads. It is considered a security hole to grant this by default as then any user could create multiple realtime threads and swamp your machine to an unresponsive state.
Ardour doesn't use RAM for recording, it dumps the sound more or less directly to disk, so unless you're seeing lots of swap being used it shouldn't be necessary to add RAM just for the sake of recording. OTOH RAM is cheap and more never hurts...
Partially correct IIRC. RAM will allow a larger in buffer memory and is used for caching purposes on disk writes by FS drivers IIRC. So in other words, more RAM won’t hurt, but you are correct in thatin the end your HD is the one that really needs to keep up.
Thanks Peder - very much appreciate the info about RAM with Ardour and the go ahead for the original kernel - Yep, I’m running a test right now and it all looks very good - Of course, I tried this in Audacity yesterday and it crashed after 15 minutes! I’m really diggin’ what I’ve seen of Ardour so far and appreciate the communty help from everyone!
from Texas and Louisiana
The limits.conf “fix” is IIRC actually only needed for standard kernels, the RT has this, sort of, “built in”.
So if it works OK now you should try to go back to the original kernel and see if that works better.
Ardour doesn’t use RAM for recording, it dumps the sound more or less directly to disk, so unless you’re seeing lots of swap being used it shouldn’t be necessary to add RAM just for the sake of recording. OTOH RAM is cheap and more never hurts…
Jack seems very flawed - it won’t even open in default without an error - don’t know if this is because it has to have another program open first or what. Also, various sound programs don’t seem to open at all (don’t know if this is because of Jack):
Meter Bridge, Patchage, Jack Time Machine and others (Audacity, Hydrogen and Ardour do open)
And the Real Time Kernel on Ubuntu Studio is very slow… but that could be because of my 512 MB RAM
(but Jaunty in the vanilla kernel is lightning fast with same RAM) - will be upgrading RAM shortly but just testing out apps until I do with this…
OK just wondering if anyone has any experience with these issues or if I should leave you alone and find some help with the installs with Ubuntu Studio or Jaunty - however help on the main forums has been slow or nonexistent lately (maybe I’m in the wrong Timezone!) So anywhere else you suggest I can go bother folks?
Hey tbonedude - I was unsure about this setting, thanks for clarifying. I tried it like this jpeg suggested but now it won’t start Jack to create a new session - says my parameters don’t match. Here’s my questions for anyone with any experience in these:
- Ardour - When creating a new session and I choose USB audio device and 1 playback/Recording on 1 device, is there any reason why the advanced tab still shows my input and output as ALC880 Analog? There is also no way to change them to USB in this setting. But if I choose 2 devices for playback/record, I can choose USB - is this an error or is this more MIDI stuff I should leave alone?
Also, the only way I can choose to start a new session is if I choose ALC880 Analog as my playback/recording device. Any attempts to use USB have resulted in a Jack error - no matter what Jack setting I try - so far anyways…
JACK - When I try to choose my interface, I see 2 options that seem viable:
hw:1 H4 and hw:1,0 USB audio.
Which one should I choose in your opinion? And after choosing them, do I still go in and add each one as the input and output? When I do this it turns my interface choice back to default.
JACK - anyone know of another basic or simple audio program I could use just to test my jack settings and see if the H4 is at least being routed through it? I don’t think Audacity is using Jack at all.
Also thanks everyone for all the help and also the info about the H4 having a digital output - very helpful and I would have never known this. Hope to get this all resolved and use it soon!
I use an H4 in full duplex regularly as an interface through jack. I think the problem is that you haven’t selected the H4 as a USB interface to be used in your session. http://www.freeimagehosting.net/uploads/cce48875b9.jpg. Also, the H4 does have hardware monitoring, but not out of your computers headphone jack. Since you can only use one sound card at a time, you must hook up your speakers through the H4’s line out jack. Hope this helps
Correct me if I'm wrong but I don't think this is needed if you run a RT-patched kernel.
I believe you are wrong. (At least for 2.6 kernels, and PAM rlimits which apply to both the rt patched and non rt patched, I can’t remember 2.4 or realtime_lsm, it has been to long since I or most anyone has used those solutions on the desktop;)
I can confirm that Seablade is right. According to my recent experience with 64studio and generic ubuntus tweaked for audio work, you need at least the rtprio line in ‘/etc/security/limits.conf’ to even launch jack successfully (at least it starts) with the ‘Realtime’ option, regardless if the kernel is rt-patched or not. According to jackaudio.org, faq number two, you also need the memlock line (I think that not necessarily unlimited, but at least a good amount of RAM, in kb). As an example, 64studio offers a rt kernel, has “the three lines” (the two mentioned plus the nice priority) in ‘limits.conf’ and includes the main user in the audio group. But if you install a plain ubuntu (or ubuntustudio as it seems for texla’s experience), then run or not a linux-rt, you certainly have to edit the ‘limits.conf’ to launch jack in realtime mode.
@texla, the audio setup tab of ardour and the setup button of qjackctk (jack control) are just two different backends to do the same thing: start the jack server.
However, afaik they don’t save the jack options and parameters in a common place. No wonder that you had success with ardour setup (very probably, you were not using the realtime option as this is the default behaviour) and you failed with qjackctl setup (here the default is just the opposite, realtime mode: yes, and you hadn’t the priority.) Now you have it, well done!. As there are much more jack-aware applications that you might try, I also suggest you should launch qjackctl before ardour always, (and, of course, before any other jack client) in order to avoid any discrepancies between the two setups in different jack starts.
It is not essential to run jack and ardour with the realtime kernel. But I recommend you use the realtime option in jack. If you really need very low software latencies and still a good performance, then yes, but then I would recommend a 64studio kernel from their jaunty backports as a better option than the ubunstudio default and, of course, that you increase your RAM. Anyway, my two cents is that you use the generic kernel by the time being, experiment and then decide.
I also strongly recommend you read a bit about the jack server and linux audio in general. linuxmusicians.com is a good place to start and it has a nice section for newbies in the wiki.
If you are using Jaunty, the RT kernel that they shipped it with is flawed (2.6.28.xxx). As a common symptom to all users using it, If your machine is dual-core, only one core is recognized by the kernel.
Regarding limits.conf, seablade is right, it is necessary regardless whether the kernel is patched for RT stuff or not. It is a user / group related permission configuration, not an RT related conf. The RT patch is to make the kernel behave close to a hard realtime system, i.e. a deterministic process time-wise. The vanilla kernel is not doing bad these days but does not qualify as hard RT. The RT patch is meant to achieve “hard realtime-ness” or as close as possible (which does not mean low latency at all but instead, a deterministic time duration for a given process, every time the process is executed … and this is really tough to achieve, given the gazillions things running in your PC, fighting to get the CPU for their own needs, cf. interrupts, IRQs, etc … ).
PS: by the way, 2.6.31-rt10 is out I have been using 2.6.31 without the RT patch and it is already quite usable! we’re getting there
Do not attempt to set the channel count. This option should probably have never been exposed to the user.
the H4 is only an input device as far as I know. Therefore, its not suprising that you cannot choose it for output.
this means that you need to use a different device for output. This is Bad. Or, at least, not good.
You have the correct choices for input. Whatever device you select, it will be called “system” in JACK. Why do we do this? because we want you to be able to use the same connection information even if you are using a different device. If we called it “Zoom H4”, then the moment you tried to use that session without H4, any connections to the H4 will fail, and there will be no way for the application to guess at a suitable alternative connection.
You should read the man page for alsa_in (or alsa_out, for that matter). It provides a better way to handle devices like this that are not really suitable as audio interfaces for a DAW, but that you nevertheless want to record from (or playback to).
Hey lokki. It’s a desktop setup and Jack is probably the issue here for sure. I’ve gone back to the Jack Control and added the H4 to the Input Device and set the Input Channels to 2. It doesn’t let me choose it as an output device. There seems to be no change in the input response in Ardour.
Any idea what I should be seeing in my options for inputs?
When I left-click, I get these choices:
Ardour: All of them are outs apparently
System: Capture 1, Capture 2
Does that seem right?
this problem is not directly related to ardour. if jack sees the interface and can handle it, ardour will also be able to use it. so your problem seems to be jack related. did you choose the right interface in qjackctl? (i assume you use it) when you’re on a laptop be careful not to select just usb device, this could be your laptop-microphone. doublecheck if you have the h4 selected. also, check that you have the h4 in input and output devices selected. furthermore, to reduce xruns on usb devices you can try and adjust the periods/buffer sizer to 3. t if all of the above doesn’t help, does jack startup fine? i guess so, otherwise ardour wouldn’t come up.
the device works in audacity also with jack? or with pulseaudio or alsa?
ah yes, maybe pulseaudio is messing with your audiocards, you can uninstall it and instead run good old alsa, just google for
pulseaudio removal ubuntu 9.04, you’ll find howtos
hope this helps
if i start jack via qjackctl i get (if i open the connections window) two sections, one for input and one for output. i get a “system” in the output and input section. when i then start ardour and add a track, i get system and ardour on both sides, outs and ins. what you want to do is connecting the outs from system to the ins of the track that you created in ardour. this is all done in qjackctl and not in ardour. that’s the way i do it. if you don’t see any input for ardour in qjackctl after you created a track, then something is wrong. are you in duplex mode in qjacktl? if not, try to enable it.
hmm, thats it for the moment.