Hi Jack people,
I am doing a lot of testing of various types of Windows audio software
at the moment. ReWire is good but Jack would make a nice alternative. I
tested in Windows Vista and got Jack Audio running, but it crashed a few
times and I got very crackly audio. After moving to my Windows 7 64bit
dual boot installation (I eventually discovered the custom/hacked PAX
drivers for my X-Fi card to replace buggy Creative drivers) I found Jack
more stable but still get this crackling in the audio - this is not
present in any other audio from my system, MME, ASIO, games, ReWire,
etc.
So how do I get involved with the Windows version ? I can put in bug
reports and do testing. I have been known to fire up windows compilers
(after eating the right kind of mushrooms, ya know how it is) but I'm
not an experienced coder. Frankly I wonder what is causing the crackling
because the rest of Jack in Windows seems to be working and stable.
DJ Barney
--
~~~
http://djbarney.org
Hi there,
I am wanting to run jackd on low resourced/power embedded systems
(running Linux).
When I run jackd on these systems it tries to lock down way to much
memory ... much more then is available.
Is the amount of memory locked down by jackd configurable ? Or is it an
operating system set thing ?
Does anyone have any constructive ideas or suggestions for running jackd
on these low resource embedded systems ?
thanks
Matt
Hi all,
as in through the hottest of summers--as southerners can't even
wait--here comes part one:
QjackCtl 0.4.0 (summer'15) is out!
though aside that everybody knows this already,
QjackCtl is a (maybe not so any more but) simple Qt [3] application
to control the JACK [2] sound server, for the Linux Audio infrastructure.
website:
http://qjackctl.sourceforge.net
downloads:
http://sourceforge.net/projects/qjackctl/files
- source tarball:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0.tar.gz
- source package:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.sr…
- binary packages:
http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.i5…http://download.sourceforge.net/qjackctl/qjackctl-0.4.0-23.rncbc.suse132.x8…
Change-log:
- Some windows fixes added (patch by Kjetil Matheussen, thanks).
- Most advanced Setup/Settings are moved into new Setup/Advanced
settings tab; limit range for the real-time priority setting, now having
6 as absolute minimum valid value (after patches by Robin Gareus, thanks).
- A new top-level widget window geometry state save and restore
sub-routine is now in effect (EXPERIMENTAL)
- Delayed geometry setup for widget windows upon startup has been
deprecated and scrapped altogether.
- Setup/settings dialog tab is going into some layout changes; also got
rid of old patchbay auto-refresh timer cruft, which was previously
hidden/disabled.
- New socket names are now automatically inferred from selected client
names while on the Patchbay widget, Socket dialog.
- Fixed for some strict tests for Qt4 vs. Qt5 configure builds.
- German (de) translation update (by Guido Scholz, thanks).
License:
QjackCtl stands free, still open-source software, distributed under
the terms of the GNU General Public License (GPL [4]) version 2 or later.
Weblog (upstream support):
http://www.rncbc.org
See also:
http://www.rncbc.org/drupal/node/912
References:
[1] QjackCtl - A JACK Audio Connection Kit Qt GUI Interface
http://qjackctl.sourceforge.net
[2] JACK Audio Connection Kit
http://jackaudio.org
[3] Qt framework, C++ class library and tools for
cross-platform application and UI development
http://qt.io/
[4] GPL - GNU General Public License
http://www.gnu.org/copyleft/gpl.html
Enjoy && have a whole hot'ta Summer'15 fun!
--
rncbc aka. Rui Nuno Capela
--
rncbc aka. Rui Nuno Capela
I send a patch once on this list and this is a "patched" version.
I keep this, because it was very helpfull while testing and improve other apps ( like hydrogen , fsthost ), especially tempo change issues. Not perfect but better than "official", especially in low tempos ( like 30 BPM ).
.. so yes you are inconvincible ;-)
P.
Dnia Czwartek, 2 Lipca 2015 20:17 Paul Davis <paul(a)linuxaudiosystems.com> napisał(a)
> Was this the stuff you tried (unsuccessfully) to convince me need to
> go into the tools repo?
>
> On Thu, Jul 2, 2015 at 1:12 PM, Pawel <xj(a)wp.pl> wrote:
> > Hi,
> >
> > Tobias, you can check my slightly improved version of jack_transport:
> > https://sourceforge.net/p/nxjsm/code/HEAD/tree/trunk/tools/transport.c
> >
> > I'm also the author of new Hydrogen jack-master code. It's works much better , but probably not perfect ;-)
> >
> > P.
> >
> > Dnia Czwartek, 2 Lipca 2015 18:57 Paul Davis <paul(a)linuxaudiosystems.com> napisał(a)
> >> Frankly, computing BBT time has never been part of "how to use the
> >> JACK API". It should probably never have been included in the source
> >> code in the first place.
> >>
> >> Managing BBT time is *extremely* complex - we have worked on it for
> >> years in Ardour and it still has issues. I'd prefer to just rip it
> >> out.
> >>
> >> On Thu, Jul 2, 2015 at 12:47 PM, Tobias Hoffmann
> >> <lfile-list(a)thax.hardliners.org> wrote:
> >> > On 02/07/15 17:30, Tobias Hoffmann wrote:
> >> >>
> >> >> On 02/07/15 15:38, Paul Davis wrote:
> >> >>>
> >> >>> jack_transport is not intended to act as a the time master.
> >> >>
> >> >> Well, comparing example-clients/transport_client.c and tools/transport.c,
> >> >> I'd say the one big difference between the two is that tools/transport.c
> >> >> (aka jack_transport) can act as a *simple* timebase master...
> >> >
> >> >
> >> > Ok, I see now that the BBT update algorithm (in the "else" branch in
> >> > timebase()) in transport.c is quite broken, because it accumulates rounding
> >> > errors. However always using the first, recalculating branch (basically: if
> >> > (true)) seems to be stable -- or at least: better than Hydrogen's timebase
> >> > master, which updates the BBT only every few cycles... (I've read that
> >> > somewhere a completely rewritten Jack Master implementation for Hydrogen is
> >> > available, which I have not tested yet).
> >> >
> >> > I find it quite sad that even some code distributed in the jack tarball is
> >> > an example of how NOT to use the Jack API ...
> >> >
> >> > Tobias
> >> >
> >> >
> >> >
> >> >
> >> >
> >> _______________________________________________
> >> Jack-Devel mailing list
> >> Jack-Devel(a)lists.jackaudio.org
> >> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
> >
> >
> >
> > _______________________________________________
> > Jack-Devel mailing list
> > Jack-Devel(a)lists.jackaudio.org
> > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Hi,
Tobias, you can check my slightly improved version of jack_transport:
https://sourceforge.net/p/nxjsm/code/HEAD/tree/trunk/tools/transport.c
I'm also the author of new Hydrogen jack-master code. It's works much better , but probably not perfect ;-)
P.
Dnia Czwartek, 2 Lipca 2015 18:57 Paul Davis <paul(a)linuxaudiosystems.com> napisał(a)
> Frankly, computing BBT time has never been part of "how to use the
> JACK API". It should probably never have been included in the source
> code in the first place.
>
> Managing BBT time is *extremely* complex - we have worked on it for
> years in Ardour and it still has issues. I'd prefer to just rip it
> out.
>
> On Thu, Jul 2, 2015 at 12:47 PM, Tobias Hoffmann
> <lfile-list(a)thax.hardliners.org> wrote:
> > On 02/07/15 17:30, Tobias Hoffmann wrote:
> >>
> >> On 02/07/15 15:38, Paul Davis wrote:
> >>>
> >>> jack_transport is not intended to act as a the time master.
> >>
> >> Well, comparing example-clients/transport_client.c and tools/transport.c,
> >> I'd say the one big difference between the two is that tools/transport.c
> >> (aka jack_transport) can act as a *simple* timebase master...
> >
> >
> > Ok, I see now that the BBT update algorithm (in the "else" branch in
> > timebase()) in transport.c is quite broken, because it accumulates rounding
> > errors. However always using the first, recalculating branch (basically: if
> > (true)) seems to be stable -- or at least: better than Hydrogen's timebase
> > master, which updates the BBT only every few cycles... (I've read that
> > somewhere a completely rewritten Jack Master implementation for Hydrogen is
> > available, which I have not tested yet).
> >
> > I find it quite sad that even some code distributed in the jack tarball is
> > an example of how NOT to use the Jack API ...
> >
> > Tobias
> >
> >
> >
> >
> >
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel(a)lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Hi,
I'm still using debian's jackd1/libjack0 package (0.124.1) and have not
tried to reproduce this with git master yet (at least, I haven't seen an
obvious fix in the commit log since 0.124.1).
In one terminal window I run jack_showtime.
In the other window I do:
jack_transport
> tempo 96 # just in case
> master
> play # does not
jack_showtime correctly shows the state, but no BBT information. From my
own client I know that jack_position_t::valid==0.
Some testing revealed that the timebase() callback in tools/transport.c
is *not called at all*, although jack_set_timebase_callback is called
and returns without error.
- But everything works fine when I switch to the jack2 stack...
And in some cases, when switching between/enabling/disabling different
Transport masters,
jack_position_t::valid retains the JackPositionBBT flag (and stale
information) -- but no-one updates them any more...
Maybe related: I've seen some strange values (*very* large negative
number) for bar_start_tick when using ardour4.1.
The very first time (and after rewind?) it contains 0.0 and is not
updated. A quick glance into the ardour source code reveals that this
field is not implemented yet. I could probably live with that.
BUT: After stopping+starting the playback, these strange values
appear... How can I know whether some value in this field is usable at
all -- except for some heuristics?
Back to the original topic... in both cases the jack_position_t struct
contains stale/random values, instead of starting from a "clean" base --
maybe memset(,0,) is all that is needed here?
Tobias
Branch: refs/heads/master
Home: https://github.com/jackaudio/headers
Commit: 23c29914806edefb496af098e937cc09e472bbbe
https://github.com/jackaudio/headers/commit/23c29914806edefb496af098e937cc0…
Author: Paul Davis <paul(a)linuxaudiosystems.com>
Date: 2015-07-02 (Thu, 02 Jul 2015)
Changed paths:
M jack.h
Log Message:
-----------
add new public API: jack_port_rename
This is semantically similar to jack_port_set_name() but because it is also passed a jack_client_t*, it can
contact the server to ensure that not only the rename is done but that port rename callbacks are delivered
appropriately