[LAU] using Jack an interface to ecasound

john gibby johnalan.gibby at gmail.com
Tue Jan 17 16:49:43 UTC 2017

Thanks!!  I can answer some of these questions, though am at work w/o
access to my system.  I think Tweed is correct that I'm probably running
jack1.  I *am* running a recent copy of Av-Linux, don't know where I got
AVS from, sorry.  And I agree with Ralf about user error... am definitely
pretty clueless, but trying to learn...  I won't complicate things by
trying to switch to jack2, not yet anyway.  I do seem to be able to stop
and start Jack via qjackctl.  I *have* configured Setup in qjackctl for the
desired 128 sample buffer.  qjackctl starts jackd, not jackdbus.  I will
send the version later when I get home. One weird thing is that even after
stopping jack via qjackctl, if I then try to start it back from the command
line, it says "default jack server" is already running.

Seems to me my main confusion/going wrong has to do with trying to insert
jack BEFORE ecasound, i.e. using "dummy" backend instead of alsa.  When I
don't do this, a problem occurs but just now I can't remember exactly how
to describe the problem.  When I use "dummy" as backend, everything seems
to work almost perfectly; I see pianoteq in qjackctl, I send 2 channels of
pianoteq to the jack outputs, and ecasound picks them up and changes them
to 6 channels correctly (I hear correct signals on low/mid/high analog
outputs).  Everything works, EXCEPT, in the pianoteq output dialog where I
select "jack", I see it's using 1024 samples instead of the desired 128,
and 1024 is the only choice...  And I also see, in the message log of
qjackctl after I start jack, where it says something like "overriding
period size to 1024".  So even though I set the sample size to 128 in
qjackctl setup for dummy backend, and I set -i jack -b 128 in ecasound as
well, looks like I end up with a 1024 sample buffer going into Jack....
Thanks again,

On Tue, Jan 17, 2017 at 10:41 AM, Tweed <tweed at lollipopfactory.com> wrote:

> On 01/17/2017 09:31 AM, john gibby wrote:
> I think my AVS implementation is not using Jack2.  (I say this b/c I tried
> to use the -S option for synchronous running, and jackd didn't recognize
> it.)  From what I read, seems worth it to install Jack2, so I plan to do
> that...  unless you think a bad idea :)
> That zita-Irx software looks, well, incredibly rich.  I guess I may try to
> switch to it instead of ecasound...  Amazing, all these great resources in
> the Linux world...
> Thanks again,
> John
> On Tue, Jan 17, 2017 at 6:17 AM, Tweed <tweed at lollipopfactory.com> wrote:
>> On 01/17/2017 04:35 AM, john gibby wrote:
>> 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
>> _______________________________________________
>> Linux-audio-user mailing listLinux-audio-user at lists.linuxaudio.orghttp://lists.linuxaudio.org/listinfo/linux-audio-user
>> maybe a jackdbus thing?  if you're using jack2, what does "jack_control
>> status" show?
>> if it says "started",  do "jack_control stop" then try your jack
>> command/qjackctl.
>> -- www.the-temp-agency.com/lollipop-factory
>> _______________________________________________ Linux-audio-user mailing
>> list Linux-audio-user at lists.linuxaudio.org http://lists.linuxaudio.org/li
>> stinfo/linux-audio-user
> If jackd doesn't recognize "-S" then its jack1.  whats jackd -v show.
> 0.12x is jack1,  1.9.x is jack2. If  you have jack1 its not a dbus issue.
> maybe another running audio process (alsa-loop daemon? pulse-jack whatever
> its called?) not allowing jackd to stop(not sure if thats right tho seems
> like I've seen this with aj-snapshot).  I use jack2 (unrelated reasons).  I
> don't know anything about avs linux (I first thought you meant Av-Linux - a
> great audio distro), be careful when changing out one JACK for another as
> your package manager may try to remove things you don't want removed.
> Anyway, there shouldn't be any reason related to your problem that you need
> to switch JACK1 <> JACK2. Try to close any jack clients then stop the jack
> server.  at this point you should be able to stop jack with qjackctl if
> not, killall jackd on command line.   "top" or "htop" or "ps -ef | grep
> jackd"  to see if jackd has stopped or not. once you confirm jackd has
> stopped, try to run your ecasound command.
> -- www.the-temp-agency.com/lollipop-factory
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20170117/3190f435/attachment.html>

More information about the Linux-audio-user mailing list