[LAU] using Jack an interface to ecasound

[john gibby]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20170117/6d34984e/attachment.html>