Hi,

This is a copy/paste from a message a few days ago, hope its useful :

Dear List, I'm trying to get Jack working with PD on OSX but am receiving the following error every time I attempt to set jack as the built in audio input device via the PD audio settings window. What am I doing wrong?

Sorry but jack won't works as an audio device in PC, you have to recompile it with native jack support. you can download pd 0.37 pre-compiled here: http://www.meskalina.it/elementicaotici/dev/downloads/pd-0.37-0- Jack.zip

Johnny Petrantoni, musician, software developer.

jackosx (JackPilot,JACK-insert,JAS): http://www.jackosx.com http://jackosx.sf.net ---

On Mon, 26 Jan 2004, Patrick Pagano wrote:

i used both the binary (from miller) and tried to compile with --enable-jack

it gives an error that it cannot find -lrt and i get the same errors as the previous poster.

Jack does NOT seem to work with pd on OSX Soundflower does work though.

On Monday, January 26, 2004, at 06:47 PM, derek holzer wrote:

...

Chris,

I am sure not an OSX guru, but maybe I can ask a few questions to get the ball rolling:

Chris Madak wrote:

...

first, pd doesn't seem to recognize -jack (as in "./pd -rt -jack") at the command line.

What error does it throw?

...

i realize that pd doesn't exactly work per se with jack under osx yet, but i thought i'd take a shot at it. any thoughts?

Did you compile PD with the --enable-jack option? If you used somebody else's installer, this almost certainly didn't happen. If PD was not compiled with Jack support, you won't get anywhere.

Of course, apologies if you have done so. These are just the easy things I can think of off the top of my head ;-)

best, D.

-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 144: "Simply a matter of work"

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

Hallo, Dan Wilken hat gesagt: // Dan Wilken wrote:

I'm looking to buy a sound-card. According to past posts on the list, both the Midiman Quattro and the Ediroyal UA-20 seem like good options with reliable Linux and OSX experiences. Has anyone had recent experience to the contrary? Is there another 4 channel I'm overlooking?

The UA-20 isn't 4-channel. The Quattro doesn't seem to work currently with kernel 2.6. If you can wait a week: I will test 18 USB interfaces on Linux the next days, and I will report about this somewhere. I do have a Quattro, and it's working so-and-so.

Has anyone unplugged these during a performance and moved them to another machine, leaving the original behind playing through the PCI (or built in) card? Mac and Linux.

Huh?

Also, do either of these reduce CPU load? Do the PCI cards do this more effectively? Enough so to change my mind?

PCI is much more efficient than USB (1.0).

ciao

Frank Barknecht _ ______footils.org__

Hallo, Dan Wilken hat gesagt: // Dan Wilken wrote:

...

PCI is much more efficient than USB (1.0).

But does it reduce CPU load, as in, might I be able to get more of my tracks playing at once if I have a good PCI sound-card?

Audio data intended to go to a USB device still has to go over PCI to the USB host controller. From there it additionally will have to be shoveled to the USB card. And you have a bandwith restriction, so you can only squeeze so much data over the USB cable. USB devices are generally very stupid, most work still has to be done by the computer. They just play back what comes in. This is in contrast to say the RME cards, which do a lot of things like mixing on the card itself and thus spare some CPU cycles. But this only gets relevant when doing, say, 12 channels of 96/24 data. The bandwith restriction alone might be in favour of getting PCI. On Linux with USB you also will be restricted in what samplerates are good to use. As USB has a resolution of 1000 frames per second, you need to choose the rate so that it can be divided by 1000.

Example (as remembered from a list mail by Clemens Ladisch, I cannot find anymore, and thus prone to errors on my side):

Samplerate is 44100 Hz, which is one sample every 1/44100 second. You need to match this with 1000 USB frames per second or one every 1/1000 second. So one USB frame needs to transport 44.1 samples. As there are no fractional samples, it will transport 44 samples most of the time, but every 10th frame will transport 45 samples.

But ALSA only supports constant period size, so this will not work very well and you'll have to crank up period size. For example on my laptop I have to use a period size of 2048 in Pd to get almost click free audio with a Quattro at 44100. Even I who is just using some midi sliders, can feel this amount of latency.

Thus it's better to use a sample rate of 48000, where you get constant 48 samples every frame. But then the UA-20 only does 44,1 kHz samplerate. Bad kitty. All this isn't a problem with PCI or PCMCIA cards. CPU load is really not an issue in the decision, it is not really important in the context of other things that are much worse in the comparison.

Conclusion: If you don't *have* to use USB audio - because you run a laptop - avoid it like the plague.

ciao

Frank Barknecht _ ______footils.org__

Hi,

marc_widmer wrote:

As Frank Barknecht wrote, the Quattro is, at least for me, not the best buy. I had problem to get it working properly on debian 2.4.22 with low latency patch and jack (tested on two machines). And i've heared some rumours that it will "never" work on 2.6.

"Never"?? That would be bad, but where did you hear this?

so better wait for Frank's results.

My tests will only be on 2.4 and I'm not sure if I can test Jack with all cards. It isn't required by the magazine I'm testing for...

With the UA-20 beware that it only does 44.1 kHz sample rate, nothing higher.

I'm curious what devices I will get to test tomorrow. ;)

ciao

Frank Barknecht _ ___footils.org_