[ANN] Vee One Suite 0.9.13 - A QStuff* Spring'20 Release batch #2

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[ANN] Vee One Suite 0.9.13 - A QStuff* Spring'20 Release batch #2

Rui Nuno Capela
Greetings once more,

The 'Vee One Suite' of so called 'old-school' software instruments,
synthv1 [1] as a polyphonic subtractive synthesizer, samplv1 [2] a
polyphonic sampler synthesizer, drumkv1 [3] as yet another drum-kit
sampler and padthv1 [4] as a polyphonic additive synthesizer, are all
being released now for the second 'QStuff*' Spring'20 batch of the
(quarantine) season.

All still available in dual form deliveries:
- a pure stand-alone JACK client with JACK-session [5], NSM (Non Session
management [6]) and both JACK MIDI and ALSA MIDI [7] input support;
- a LV2 instrument plug-in [8].

Not much of a ravishing change-log, just on the brink of utterly boring
maintenance stuff:
- Always keep the current sample loop-cycle on note-off, while entering
a DCA Release stage. (applies to samplv1 [2] only)
- Maximum pitch-bend range has been expanded to 0..400%, allegedly to
support some PME driven instruments.
- Make man page compression reproducible (after request by Jelle van der
Waa, thanks).
- Fixed crash when showing the tooltip of a negative note number that
results from dragging over and beyond the left edge of the virtual piano
keyboard.
- Remove -v (verbose) flag from 'strip' post-link command.
- Fixed CMake build by adding missing Custom Color Theme (palette) form
file (.ui).
- Bumped copyright headers into the New Year (2020).

The 'Vee One Suite' are free, open-source Linux Audio [10] software,
distributed under the terms of the GNU General Public License (GPL) [11]
version 2 or later.


**synthv1 - an old-school polyphonic synthesizer [1] **

  synthv1 0.9.13 (spring'20) released!

  synthv1 is an old-school all-digital 4-oscillator subtractive
polyphonic synthesizer with stereo fx.

  LV2 URI: http://synthv1.sourceforge.net/lv2

website:
  https://synthv1.sourceforge.io
  http://synthv1.sourceforge.net

project page:
  https://sourceforge.net/projects/synthv1

downloads:
  https://sourceforge.net/projects/synthv1/files

- source tarball:
  https://download.sf.net/synthv1/synthv1-0.9.13.tar.gz
- source package:
  https://download.sf.net/synthv1/synthv1-0.9.13-53.rncbc.suse.src.rpm
- binary packages (openSUSE Tumbleweed):
  https://download.sf.net/synthv1/synthv1-0.9.13-53.rncbc.suse.x86_84.rpm

https://download.sf.net/synthv1/synthv1-lv2-0.9.13-53.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
  https://download.sf.net/synthv1/synthv1-0.9.13-53.x86_64.AppImage

git repos:
  https://git.code.sf.net/p/synthv1/code
  https://github.com/rncbc/synthv1.git
  https://gitlab.com/rncbc/synthv1.git
  https://bitbucket.org/rncbc/synthv1.git


**samplv1 - an old-school polyphonic sampler [2]**

  samplv1 0.9.13 (spring'20) released!

  samplv1 is an old-school polyphonic sampler synthesizer with stereo fx.

  LV2 URI: http://samplv1.sourceforge.net/lv2

website:
  https://samplv1.sourceforge.io
  http://samplv1.sourceforge.net

project page:
  https://sourceforge.net/projects/samplv1

downloads:
  https://sourceforge.net/projects/samplv1/files

- source tarball:
  https://download.sf.net/samplv1/samplv1-0.9.13.tar.gz
- source package:
  https://download.sf.net/samplv1/samplv1-0.9.13-53.rncbc.suse.src.rpm
- binary package (openSUSE Tumbleweed):
  https://download.sf.net/samplv1/samplv1-0.9.13-53.rncbc.suse.x86_84.rpm

https://download.sf.net/samplv1/samplv1-lv2-0.9.13-53.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
  https://download.sf.net/samplv1/samplv1-0.9.13-53.x86_64.AppImage

git repos:
  https://git.code.sf.net/p/samplv1/code
  https://github.com/rncbc/samplv1.git
  https://gitlab.com/rncbc/samplv1.git
  https://bitbucket.org/rncbc/samplv1.git


**drumkv1 - an old-school drum-kit sampler [3]**

  drumkv1 0.9.13 (spring'20) released!

  drumkv1 is an old-school drum-kit sampler synthesizer with stereo fx.

  LV2 URI: http://drumkv1.sourceforge.net/lv2

website:
  https://drumkv1.sourceforge.io
  http://drumkv1.sourceforge.net

project page:
  https://sourceforge.net/projects/samplv1

downloads:
  https://sourceforge.net/projects/drumkv1/files

- source tarball:
  https://download.sf.net/drumkv1/drumkv1-0.9.13.tar.gz
- source package:
  https://download.sf.net/drumkv1/drumkv1-0.9.13-43.rncbc.suse.src.rpm
- binary package (openSUSE Tumbleweed):
  https://download.sf.net/drumkv1/drumkv1-0.9.13-43.rncbc.suse.x86_84.rpm

https://download.sf.net/drumkv1/drumkv1-lv2-0.9.13-43.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
  https://download.sf.net/drumkv1/drumkv1-0.9.13-53.x86_64.AppImage

git repos:
  https://git.code.sf.net/p/drumkv1/code
  https://github.com/rncbc/drumkv1.git
  https://gitlab.com/rncbc/drumkv1.git
  https://bitbucket.org/rncbc/drumkv1.git


**padthv1 - an old-school polyphonic additive synthesizer [4]**

  padthv1 0.9.13 (spring'20) released!

  padthv1 is an old-school polyphonic additive synthesizer with stereo fx.

  padthv1 is based on the PADsynth algorithm by Paul Nasca, as a special
variant of additive synthesis.

  LV2 URI: http://padthv1.sourceforge.net/lv2

website:
  http://padthv1.sourceforge.net
  https://padthv1.sourceforge.io

project page:
  https://sourceforge.net/projects/padthv1

downloads:
  https://sourceforge.net/projects/padthv1/files

- source tarball:
  https://download.sf.net/padthv1/padthv1-0.9.13.tar.gz
- source package:
  https://download.sf.net/padthv1/padthv1-0.9.13-53.rncbc.suse.src.rpm
- binary package (openSUSE Tumbleweed):
  https://download.sf.net/padthv1/padthv1-0.9.13-53.rncbc.suse.x86_84.rpm

https://download.sf.net/padthv1/padthv1-lv2-0.9.13-53.rncbc.suse.x86_84.rpm
- AppImage [9] package (JACK stand-alone only):
  https://download.sf.net/padthv1/padthv1-0.9.13-53.x86_64.AppImage

git repos:
  https://git.code.sf.net/p/padthv1/code
  https://github.com/rncbc/padthv1.git
  https://gitlab.com/rncbc/padthv1.git
  https://bitbucket.org/rncbc/padthv1.git


References:

 [1] synthv1 - an old-school polyphonic synthesizer
     https://synthv1.sourceforge.io
     http://synthv1.sourceforge.net/

 [2] samplv1 - an old-school polyphonic sampler
     https://samplv1.sourceforge.io
     http://samplv1.sourceforge.net/

 [3] drumkv1 - an old-school drum-kit sampler
     https://drumkv1.sourceforge.io
     http://drumkv1.sourceforge.net/

 [4] padthv1 - an old-school polyphonic additive synthesizer
     https://padthv1.sourceforge.io
     http://padthv1.sourceforge.net/

 [5] JACK Audio Connection Kit
     https://jackaudio.org/

 [6] NSM, Non Session Management
     http://non.tuxfamily.org/nsm/

 [7] ALSA, Advanced Linux Sound Architecture
     https://www.alsa-project.org/

 [8] LV2, Audio Plugin Standard, the extensible successor of LADSPA
     http://lv2plug.in/

 [9] AppImage, Linux apps that run anywhere
     https://appimage.org/

[10] Linux Audio consortium of libre software for audio-related work
     https://linuxaudio.org

[11] GNU General Public License
     https://www.gnu.org/copyleft/gpl.html


See also:
  https://www.rncbc.org/drupal/node/2076


Enjoy && Stay safe!
--
rncbc aka. Rui Nuno Capela
[hidden email]
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Looking for some jackd debugging help

Ethan Funk
Hello audio developers,

I have been working slowly on a port of a radio automation system I originally wrote for OSX to a more general, cross-platform design using jack-audio and gstreamer instead of Apple's Core audio API. As part of the design change, I have separated the mix-engine and media handling into separate processes, where the mixer forks media players, which connect back the core mixer via jack, then are disconnected by the mixer when finished, prior to the media player instance shutting down.  

It appears to me that there is a problem with jackd crashing after a day or two of the core mixer (arServer4) running new media player clients, connecting, disconnecting, and then quitting, as music is loaded and played in a test automation scenario, on an Ubuntu 19.10 test setup. I have been debugging both the core-mixer programs and the the media players over the course of the last few months. I don't see any memory leaks any more, and all thread safety issues appear to have been resolved. I am not calling jack calls in the real-time render thread that are not intended for use in that thread. All jack client client call backs are handles through a message queue, so they to are also safe. All other jack calls are protected by a thread lock. Again, my programs are not crashing, jackd is. And nothing crashes for weeks when I keep one media player connected to my core-mixer, playing the same file over and over. So it really does appear to be the connections and disconnections that are causing the trouble. As a side note, Carla is also crashing, but about 3 time more often than jackd is.

Here is what I get from my arServer4 core-mixer program's stderr (registered to jackd as "ars9550"), just before the jack-server shutdown call back fires off:

Cannot read socket fd = 7 err = Success
CheckRes error
JackSocketClientChannel read fail
SuspendRefNum error
JackClient::Execute error name = ars9550
Server is not running

I am running jackd in a shell so I can watch it crash, and it just appears to just die after a few days... no special messages.
jackd -v yields:
jackdmp 1.9.12
[copyright stuff...]

Which, even though it is version 1.9.12, I believe is a jack2 server correct? This is supposed to support live client connection and disconnection, so I don't think I am doing anything wrong.

I would like to run jackd in gdb so I can see where it is failing, but I am unsure how to build it without breaking my system's installed jack package, which is of course built without debugging enabled.

Any help would be appreciated.

Ethan Funk
Audiorack4 project hosted at:
https://github.com/eafunk/audiorack


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

Fons Adriaensen-3
On Sat, Mar 28, 2020 at 12:38:46PM -0700, Ethan Funk wrote:
 
> I have been working slowly on a port of a radio automation system I
> originally wrote for OSX to a more general, cross-platform design using
> jack-audio and gstreamer instead of Apple's Core audio API.  As part of
> the design change, I have separated the mix-engine and media handling
> into separate processes, where the mixer forks media players, which
> connect back the core mixer via jack,  then are disconnected by the
> mixer when finished, prior to the media player instance shutting down.

This *should* work of course, but I'm wondering why things are done
that way. In a 'real' studio, would you disconnect and remove e.g.
a CD player after each track, and install a new one for the next
track ?

The simple alternative is to have a fixed number of players running
all the time, and just outputting silence when not playing a track.
Whenever you need to play a track, find and idle player and use it.
 
But as said, your approach should just work. I'm not yet convinced
this is a Jack problem. I've had much more complex systems (with
tens of jack clients coming and going and hundreds of ports)
running for months.

> I am not calling jack calls in the real-time render
> thread that are not intended for use in that thread.

Which ones are you calling there ? Normally there is no need
at all to call Jack from the its own process() callback.

> All jack client client call backs are handles through
> a message queue,

Except for process() I hope. Which other callbacks are you
using ?

> So it really does appear to be the connections and
> disconnections that are causing the trouble.

Yes.
 
> Here is what I get from my arServer4 core-mixer program's stderr
> (registered to jackd as "ars9550"), just before the jack-server
> shutdown call back fires off:

What happens just before that, that would trigger a crash ?
In other words, does this happen when you call Jack for any
reason (e.g. connect or disconnect), or just by itself ?
 
> Cannot read socket fd = 7 err = Success
> CheckRes error
> JackSocketClientChannel read fail
> SuspendRefNum error
> JackClient::Execute error name = ars9550
> Server is not running

I'm not familiar with the Jack2 code, so I've no idea what
that could mean.
 
> I would like to run jackd in gdb so I can see where it is failing, but
> I am unsure how to build it without breaking my system's installed jack
> package, which is of course built without debugging enabled.

You could also try Jack1 instead. Note that this has its own problems,
in particular when connections are changing all the time -- it tends
to run clients out of order, which depending on the application may
go unnoticed, or be a serious problem.

> Any help would be appreciated.
 
Sorry, I can't help more...

--
FA



> _______________________________________________
> Linux-audio-dev mailing list
> [hidden email]
> https://lists.linuxaudio.org/listinfo/linux-audio-dev

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

John Rigg-6
In reply to this post by Ethan Funk
On Sat, Mar 28, 2020 at 12:38:46PM -0700, Ethan Funk wrote:
> I would like to run jackd in gdb so I can see where it is failing, but
> I am unsure how to build it without breaking my system's installed jack
> package, which is of course built without debugging enabled.

You could try installing the compiled version over the existing
package files. On Debian I add the following to the ./waf configure
command when I want to do this:

--prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu

Substitute the libdir path relevant for your distro
if not Debian based.

John
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

Ethan Funk
In reply to this post by Fons Adriaensen-3
On Sun, 2020-03-29 at 11:35 +0200, Fons Adriaensen wrote:
This *should* work of course, but I'm wondering why things are done
that way. In a 'real' studio, would you disconnect and remove e.g.
a CD player after each track, and install a new one for the next
track ?

In a real studio of old, mixers had 16, 32, and some times more stereo inputs, with a dedicated input for each of your 3 cart machines, 3 CD players, 2 turn tables, 4 microphones, two or more phone callers, 2 network feeds, RPU remote, a tape deck, and so on. Huge mixers, with just a few channels used at a time. Why so many channels? Because DJs are not technicians, and can't be trusted to be allowed to change the mixer input configuration, even though they are only using a few channels at a time, some time just two channels as they segue between songs.

With a computer replacing the mixer entirely, I still have all sorts of audio sources: some live like microphones and turn tables, some virtual like audio file players, network streams, and SIP phone sources. And additionally sources like a jack source coming out of some other program. Keeping the media handling as separate programs allows the core-mixer to have a relative small number of inputs, 8 by default. Extra live inputs associated with physical audio device inputs and be added when needed, then unloaded when done. Use 1 live guest mic, or three if needed. Sources are treated as an abstrcation, allowing all different types of sources to be used now, and ones not thought of now, in the future. As long as you never need more than 8 sources running at once, your good. Pre-loading takes you back to needing a lot of inputs for every possible source you could ever use, most of which are used only occasionally.

I am not calling jack calls in the real-time render
thread that are not intended for use in that thread.

Which ones are you calling there ? Normally there is no need
at all to call Jack from the its own process() callback.



All jack client client call backs are handles through
a message queue,

Except for process() I hope. Which other callbacks are you
using ?

For sure. My process call back is it's own direct callback function. It calls jack functions that a typical process function is expected to call:
jack_port_get_buffer

jack_midi_get_event_count
jack_midi_event_reserve
jack_midi_event_get

and the whole family of jack_ringbuffer functions. All are design to be used from the process function, as I understand it. Am I wrong?

I also call pthread_cond_broadcast some times from with in the process function, when it has done something that I want another thread in my program to go take note of. This seems like a typical and intended use of pthread_cond_broadcast, so I don't think that should be a problem.

All other jack calls are made in other program threads, and are made thread safe by wrapping  a dedicated mutex around jack function calls. I looked at the jack client source code back when I was having thread problems, and determined that none of the jack client calls I looked at were thread safe without a mutex lock. So rather than looking any deeper, I just put a lock around all calls.

So it really does appear to be the connections and
disconnections that are causing the trouble.

Yes.
 
Here is what I get from my arServer4 core-mixer program's stderr
(registered to jackd as "ars9550"), just before the jack-server
shutdown call back fires off:

What happens just before that, that would trigger a crash ?
In other words, does this happen when you call Jack for any
reason (e.g. connect or disconnect), or just by itself ?

jackd always crashes just short of one minute after a media player instance finished and has unregistered with jackd. Not the disconnection even, but the unregister prior to shutdown event. The 1 minute is a clue, but I don't know why jackd wait 1 minute to die.
 
You could also try Jack1 instead. Note that this has its own problems,
in particular when connections are changing all the time -- it tends
to run clients out of order, which depending on the application may
go unnoticed, or be a serious problem.

Jack1 specifically doesn't provide glitch-less jack connection changes, so that is not an option.

-Ethan

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

Ethan Funk
In reply to this post by Fons Adriaensen-3
I was wrong in my thinking that jackd  had a stability problem. After spending (wasting) a lot of time troubleshooting jackd, a jackd crash finally occurred while I was siting in front of the machine, and I noticed that I lost the mouse and keyboard too for about 10 seconds. So this whole time, the trouble has been flaky USB hardware on the motherboard, not jackd.

Testing on a new computer has been flawless, for going on two weeks now.

That leads me to a question regarding Ubuntu Studio Control, which I have been using to manage jackd and additional audio interfaces via zita-a2j. I have Ubuntu Studio Control configured to use a Tascam US-4x4 as the main audio interface with 128 sample process frames at a 48 kHz sample rate on my test machine, with the built-in audio port on the motherboard as a a2j/j2a bridge. Audio to and from the motherboard interface is broken up with the zita-a2j and zita-j2a running as launched by Ubuntu Studio Control. Notably, the -p run option is set to 64. If I run zita-a2j myself with -p set nice and high, to 1024 for example, I get good clean audio, at the expense of latency on that interface. That's fine for me, since I still have good, low latency on the main interface. Does any one know where I can find the source code for Ubuntu Studio Control so I can investigate a fix to make this settable?

Thanks,
Ethan Funk


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

Len Ovens
On Sat, 13 Jun 2020, Ethan Funk wrote:

> That leads me to a question regarding Ubuntu Studio Control, which I have been
> using to manage jackd and additional audio interfaces via zita-a2j. I have Ubuntu
> Studio Control configured to use a Tascam US-4x4 as the main audio interface with
> 128 sample process frames at a 48 kHz sample rate on my test machine, with the
> built-in audio port on the motherboard as a a2j/j2a bridge. Audio to and from the
> motherboard interface is broken up with the zita-a2j and zita-j2a running as
> launched by Ubuntu Studio Control. Notably, the -p run option is set to 64. If I
> run zita-a2j myself with -p set nice and high, to 1024 for example, I get good
> clean audio, at the expense of latency on that interface. That's fine for me,
> since I still have good, low latency on the main interface. Does any one know
> where I can find the source code for Ubuntu Studio Control so I can investigate a
> fix to make this settable?

-controls is written in python and so easy to change. You can view the
source directly by looking at /usr/bin/autojack. Zita-ajbridge has the
buffer to 1/2 that of jack... but that is proving to be a problem in some
cases. Internal should be at least 128 and hdmi should be 4096. The git
repo is https://github.com/ovenwerks/studio-controls (it has been
"unbranded" so other distros can feel free to use it)

This is a relatively new project and so is very much not bug free. Being
able to directly set buffer size for each device used sounds very much
like a reasonable feature request. (also a feature that has been thought
of before)

Be aware that autojack runs from session start and because of the way some
DEs use systemd/logind to start sessions... the session never really ends
so a reboot or a killall autojack may be needed to see how changes do. I
would suggest running autojack in a terminal while testing new code so
that you have access to terminal output. once you have finished with the
code running studio-controls should restart it in the background again if
you have closed the terminal.


--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

Ethan Funk
Thanks. I found autojack, and know just enough Python to make some sense of it. I am still confused as to where autojack is getting the 64 value. I easily found...

                procin = subprocess.Popen(
                    ["/usr/bin/zita-a2j", "-j", f"{ldev}-in", "-d", f"hw:{ldev}", "-r", dsr, "-p", def_config['ZFRAME'],
                     "-n", def_config['PERIOD'], "-c", "100"], shell=False)

...which would seem to pull the -p parameter from the def_config array. And I see that it's default value is 512, set early on in the code. However, I assume this value is over ridden by my saved session setting of 128 at some point when the code gets going. Where is the 64 coming from? Maybe ZFRAME is set by the GUI to half frames?

In some ways Python does make life easier than C. I can just edit the file with a "* 2" or "* 4", log out and back in again and go. I assume you are part of the group of people behind this project... so thank you!

-Ethan

On Sat, 2020-06-13 at 17:12 -0700, Len Ovens wrote:
On Sat, 13 Jun 2020, Ethan Funk wrote:

That leads me to a question regarding Ubuntu Studio Control, which I have been
using to manage jackd and additional audio interfaces via zita-a2j. I have Ubuntu
Studio Control configured to use a Tascam US-4x4 as the main audio interface with
128 sample process frames at a 48 kHz sample rate on my test machine, with the
built-in audio port on the motherboard as a a2j/j2a bridge. Audio to and from the
motherboard interface is broken up with the zita-a2j and zita-j2a running as
launched by Ubuntu Studio Control. Notably, the -p run option is set to 64. If I
run zita-a2j myself with -p set nice and high, to 1024 for example, I get good
clean audio, at the expense of latency on that interface. That's fine for me,
since I still have good, low latency on the main interface. Does any one know
where I can find the source code for Ubuntu Studio Control so I can investigate a
fix to make this settable?

-controls is written in python and so easy to change. You can view the 
source directly by looking at /usr/bin/autojack. Zita-ajbridge has the 
buffer to 1/2 that of jack... but that is proving to be a problem in some 
cases. Internal should be at least 128 and hdmi should be 4096. The git 
repo is 
https://github.com/ovenwerks/studio-controls
 (it has been 
"unbranded" so other distros can feel free to use it)

This is a relatively new project and so is very much not bug free. Being 
able to directly set buffer size for each device used sounds very much 
like a reasonable feature request. (also a feature that has been thought 
of before)

Be aware that autojack runs from session start and because of the way some 
DEs use systemd/logind to start sessions... the session never really ends 
so a reboot or a killall autojack may be needed to see how changes do. I 
would suggest running autojack in a terminal while testing new code so 
that you have access to terminal output. once you have finished with the 
code running studio-controls should restart it in the background again if 
you have closed the terminal.


--
Len Ovens
www.ovenwerks.net

_______________________________________________
Linux-audio-dev mailing list
[hidden email]

https://lists.linuxaudio.org/listinfo/linux-audio-dev


_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Looking for some jackd debugging help

Len Ovens
On Sat, 13 Jun 2020, Ethan Funk wrote:

> Thanks. I found autojack, and know just enough Python to make some sense of it. I
> am still confused as to where autojack is getting the 64 value. I easily found...
>
>                 procin = subprocess.Popen(
>                     ["/usr/bin/zita-a2j", "-j", f"{ldev}-in", "-d", f"hw:{ldev}",
> "-r", dsr, "-p", def_config['ZFRAME'],
>                      "-n", def_config['PERIOD'], "-c", "100"], shell=False)
>
> ...which would seem to pull the -p parameter from the def_config array. And I see
> that it's default value is 512, set early on in the code. However, I assume this
> value is over ridden by my saved session setting of 128 at some point when the
> code gets going. Where is the 64 coming from? Maybe ZFRAME is set by the GUI to
> half frames?
ubuntustudio-controls sets zframe to jack frame divided by 2. This is what
the man apge suggests (or maybe a coversation in the mailing list). So, in
$HOME/.config/autojack/autojackrc you will find that frame = 1024 and
zframe = 512 by default. You can change the value in this file to whatever
you want and tell jack to restart and it will pick it up. The next version
of -controls will need to handle this better.

I am glad you are finding it useful. It started as a "quick" script in
bash to set things up for my own use. Other people asked to be able to use
it and here we are.

--
Len Ovens
www.ovenwerks.net

_______________________________________________
Linux-audio-dev mailing list
[hidden email]
https://lists.linuxaudio.org/listinfo/linux-audio-dev