I bought mixbus yesterday and was really happy about almost everything about it… until I started exporting sessions. Somehow, exporting causes mixbus to hang (or just take a VERY LONG TIME to finish up when there’s only one 10 second track in the session) on my system. I never had such problems when I was running plain old ardour2. In fact, I even tried running ardour2 without mixbus with the exact same settings on jack and didn’t have that problem.
Have any of you here had the same problem? If you have and you tweaked it, what did you do to work around it?
@seablade: yup, i moved the end marker so that the start-end range is around 10 secs or less.
@joegiampaoli: ok, so my .jackdrc file reads “/usr/bin/jackd -p512 -u -dalsa -dhw:0 -r48000 -p1024 -n2 -Xraw -H” (realtime mode on, unlock memory on, h/w monitor ports on). I’m using qjackctl with JACK version 0.3.4. I imported an ardour2 session with some sound design work into mixbus, I’ve just tried deactivating all the plugins I used (TAP pitch shifter, C*Eq, mono to stereo splitter, TAP reverb) and it seems that you might be right. One of the plugins (or combination of them) might be causing the crash but I can’t seem to narrow it down as I get mixed/unpredictable results every time.
The main issue is, however, that mixbus still takes a rather long time to finish processing the export of a 10 sec track (about a minute without any effects as compared to almost instantly with just ardour2). When I export, the progress meter zooms past but then it takes about a minute or more (depending on the number of plugins) for the process to complete and for the export window to go away. When I notice that my processors start going mad for too long (i.e. it crashed), I kill mixbus and JACK shows this :
“subgraph starting at qjackctl timed out (subgraph_wait_fd=24, status = 0, state = Running, pollret = 0 revents = 0x0)
process cycle within freewheel failed”
but the exported file plays back fine as if there was nothing wrong with the export. I read somewhere about earlier versions of ardour that downsampling from 48KHz to 44.1KHz might cause this and all this time I’ve been exporting to 44.1KHz. Could this be the cause?
Btw, I tried creating a new track on a brand new mixbus session to test and I still get the problem, so I doubt it’s because of the known ardour2 --> mixbus session issue.
which was a different issue, but anyway it reminded me on that.
in your second post in this thread, you write that you are using jack version 0.3.4.
this cannot be true, this is the version of qjackctl, which is a graphical frontend for jackd.
you could type into a terminal:
i have no idea why the ‘H’ option is giving you a bad performance. perhaps it is just not good to use it on your machine, perhaps it is kinda broken. no idea, i never used this option myself.
Do you have an RME card at all? The -H option I think only works with RME cards…
Enable hardware monitoring of capture ports. This is a method for obtaining "zero latency" monitoring of audio input. It requires support in hardware and from the underlying ALSA device driver.
When enabled, requests to monitor capture ports will be satisfied by creating a direct signal path between audio interface input and output connectors, with no processing by the host computer at all. This offers the lowest possible latency for the monitored signal.
Presently (March 2003), only the RME Hammerfall series and cards based on the ICE1712 chipset (M-Audio Delta series, Terratec, and others) support --hwmon. In the future, some consumer cards may also be supported by modifying their mixer settings.
Without --hwmon, port monitoring requires JACK to read audio into system memory, then copy it back out to the hardware again, imposing the basic JACK system latency determined by the --period and --nperiods parameters.
Though this behavior or method of failing seems odd, if your card isn’t supported I certainly wouldn’t use it.