[LAU] using Jack an interface to ecasound

Tweed tweed at lollipopfactory.com
Tue Jan 17 15:41:48 UTC 2017

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 
> <mailto: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
>>     <mailto: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 list
>>     Linux-audio-user at lists.linuxaudio.org
>>     <mailto:Linux-audio-user at lists.linuxaudio.org>
>>     http://lists.linuxaudio.org/listinfo/linux-audio-user
>>     <http://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
>     <http://www.the-temp-agency.com/lollipop-factory>
>     _______________________________________________ Linux-audio-user
>     mailing list Linux-audio-user at lists.linuxaudio.org
>     <mailto:Linux-audio-user at lists.linuxaudio.org>
>     http://lists.linuxaudio.org/listinfo/linux-audio-user
>     <http://lists.linuxaudio.org/listinfo/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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20170117/eca88fc3/attachment.html>

More information about the Linux-audio-user mailing list