Sound is via ALC 1150 chipset; I don't think that's the problem. When I go directly from pianoteq to alsa there's no problem; can use even a 64 sample buffer. Maybe I need a little help in killing the default jack server and starting it back (with dummy back end ) using direct jackd command line instead of using qjackctl? Then I think it may keep my specified buffer size. Am Linux newby, takes a little work! :)

On Jan 17, 2017 4:23 AM, "Jeanette C." <julien@mail.upb.de> wrote:

Jan 17 2017, john gibby has written:
...

When qjackctl brings up
the jack server, the buffer size gets overridden to 1024; I see the message
in the log. What am I doing wrong? Is Jack the wrong approach, when it is
ecasound, not jack, that writes to alsa?

Hi John,
it appears that your soundcard is the problem. I've only started JACK on
the commandline or through a dedicated start script, not using qjackctl
or other JACK-supplied tools. But if you give a buffersize to JACK it
will honour that buffersize, if the soundcard can stand it. I haven't
seen an application before that couldn't honour JACK's buffersize,
whatever it is. Especially Ecasound can certainly go down to 64 samples.

What soundcard do you have? Have you tried starting JACK for your
soundcard on the commandline and see what happens?
jackd --timeout 4500 -R -d alsa -d hw:0 -p 128
Assuming that your soundcard is the first one (hw:0).

I have no experience with Pianoteq, but since it is meant as a realtime
app, it should make sure that its sounds are played back without delay
or with minimal delay. 128 and even 64 samples aren't that uncommon.
...

Best wishes,

Jeanette

--------
When you need someone, you just turn around and I will be there <3