Problem with recording

Hello,

I’m running into a very basic problem. I can’t seem to get Ardour to record anything, or even play back. I am running on SuSe 10.3 and I’ve installed all the libraries. I’ve compiled it from source (version 2.4.1) and as far as I can tell, the compile was successful. Ardour does start up and I can do create tracks and tweak values, but when I hit the play button, nothing happens.

This is what I do:

  1. I start up the jack server from the command line with “jackd --driver alsa”. Jack loads up everything and it looks okay.
  2. I start up QJackCtl and connect it. Seems to work. For some reason, I can’t start Jack server automatically with it, but running it at the command line seems to work fine (step 1).
  3. I start up Ardour. I see all the Jack connections, etc, seems to be okay.
  4. I make a new track, assign a name, etc…
  5. I set the input channel on new track to the output of the alsa channels.
  6. I set the output to default.
  7. I click the record button on the track.
  8. I click the record button on the master transport controlls.
  9. I click the play button…

nothing. The time doesn’t increment or give me any indication that it is recording any data. I never see anything happening and the play button just seems to be broke. I even tried to load up an audio file and play it, but that doesn’t seem to work either.

What am I missing? Could I have a bad compile? Or something in the Jack engine not set right? It looks okay. Is there anything I can check? I’d appreciate any comments or help you an offer. Thanks a bunch. The program looks great, just want to use it.

Thank you. That I understand. That’s kind of what I thought it was from the messages, but I don’t get the term XRUN to mean that. Not important, I guess. Thanks again.

xrun is not an error, it’s a data chunk that’s not been processed in time. It depends on your hardware and software as well. For example, if your soundcard cannot cope with processing very small audio buffers and periods, if jackd is nonetheless set up so, you will have tons of xruns. A way to reduce xruns is to increase the buffer length but the cost is a greater latency. But to come back to your question, an xrun is an audio buffer under or overrun.

One last question. Can someone tell me what the heck an xrun is? Everyone references it but no one explains it, not even the developers who just start using it like everyone knows what it is. I see it’s some kind of callback in the code, but why is it called an xrun instead of just an error. :stuck_out_tongue:

I am getting xruns constantly with what appears to be all the data skipped and that’s most likely the source of my problem. Message is “XRUN callback (46 skipped)” continuously.

Is there a log somewhere that may have more information?

Sorry, I’m just a newb on linux sound. Finding information on all this can be a bit frustrating when things don’t work right. Seems there’s just bits and pieces all over with tons of broken links and collecting it into something meaningful is a challenge to say the least.

Is there a better web site than the main developer one?

not sure if i understand you, but if the relevant part is that the playhead does not move try disabling the sync options in the ‘options’ menu.

cheers,
doc

That’s essentially the problem. It may be expecting an external source to drive it, but I don’t see anything. I disabled all the sync options. I set it to “Time Master”, which I interpret to mean that Ardour is controlling the time. Still nothing happens. The “record” button blinks, but it will not leave the pause state (i.e. the button with the square on it next to the record button stays green) and go to the play mode to start recording.

I know this has to be something stupid and basic. I just can’t seem to find it.

…perhaps, there is some log window open behind the editor?
i think that in that case ardour would expect you to first close the log window.

cheers,
doc

what is set above the ‘time master’ button?

(internal/jack/mtc)

I think I have an even more basic problem. When I run QJackCtl, it won’t start up the JACK server in real-time. And even when I disable realtime, when I click the transport play button in QJackCtl, it just stops too. The whole transport system seems broken in some way and I’m not sure why. I’m using C-Media 8738-MC onboard audio, could that be the problem? I’m not trying to do anything serious right now, just get things setup for later. ALSA seems to find the connections without any problems.

I’ll take any ideas anyone may have, but it doesn’t look like an Ardour problem. Thanks in advance.

EDIT: I tried all the options above the Time Master button, but left it at Internal.

I’ve traced it down to what appears to be a JACK transport problem, but help over at JACK central is less than to be desired. I’ve gotten JACK to run at real-time from my user level process, but when I load up QJackCtl, the only buttons that enable are the “start” and “fast forward” buttons. Clicking the play button tries to start the transport, but it immediately stops with no error or reason why. RTFM’ing all I can find only tells me it’s supposed to work, and it doesn’t. Getting a bit frustrated.

If anyone has any ideas, I’ll take em. I’ve rebuilt JACK with various options and grabbed the latest source. I’ve tried getting Ardour to sync to JACK and that doesn’t help any. Ardour won’t even sync to its internal sources.

EDIT: Well, seems that the watchdog thread is stopping JACK for some reason causing all kinds of problems. Overriding it doesn’t work either. Guess SuSe 10.3 has some problems with JACK or my chipset. Bleh.

Now that you mention this, I do recall that the SuSE package of JACK is bad. You should either build JACK yourself (after removing the SuSE package) and/or take this to the relevant SuSE forums. It is beyond irritating to me that packagers can break the behaviour of applications in this way.

Hmmm, thanks. I did build JACK from scratch, but I didn’t remove the old one. It shipped with 0.103.x, but 0.109.2 isn’t working either. Maybe I need to do some cleaning.

I guess X (in Xrun) stands for “under” or “over” :slight_smile:

I have the exact same problem. I run jack and I can’t manage to start the transport, it is always stopped. When I open Ardour, create a track and try to record, the same thing happens, that is, nothing. The mic is working but it seems that Ardour does not receive any signal. I really don’t know what to do,if anyone can help, please.

I use Ubuntu Hardy, with a SB Audigy LS sound card and ALSA. The sound works fine outside Ardour, I can record in sound recorder and I can listen to everything.

Thanks,
Juliano.

I did it. The secret is: Soft Mode. When using ALSA driver jack needs to ignore the xruns in order to work. Nice.

the soft mode will ignore reporting or reacting on xruns but these will exist nonetheless. The real option you want is : continue recording in spite of xruns. The default, if I am not wrong, is “stop recording on xrun”. Be aware that if you want to record anyway, xrums will sound like a dropout or click when you play your track. Ardour will create a marker at the xrun occurence so you can edit your track easily. But if you get gazillions of them, I would tweak my system further to avoid them if I were you :wink:

@MarkR & Juliano7s,

Be aware that JACK works with many but certainly not all Audio Chipsets, Curiously later model Soundblasters and many Cheapies like Intel HDA, C-Media etc. are good with ALSA but not JACK.