Re: [LAD] Looking for some jackd debugging help
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
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for some jackd debugging help
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 beenusing to manage jackd and additional audio interfaces
> > via zita-a2j. I have UbuntuStudio Control configured to use a
> > Tascam US-4x4 as the main audio interface with128 sample process
> > frames at a 48 kHz sample rate on my test machine, with thebuilt-in
> > audio port on the motherboard as a a2j/j2a bridge. Audio to and
> > from themotherboard interface is broken up with the zita-a2j and
> > zita-j2a running aslaunched by Ubuntu Studio Control. Notably, the
> > -p run option is set to 64. If Irun zita-a2j myself with -p set
> > nice and high, to 1024 for example, I get goodclean 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
> > knowwhere I can find the source code for Ubuntu Studio Control so I
> > can investigate afix 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
> id="-x-evo-selection-start-marker">/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 Ovenswww.ovenwerks.net
> ___Linux-audio-dev
> mailing listlinux-audio-...@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev
signature.asc
Description: This is a digitally signed message part
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for some jackd debugging help
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 Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for some jackd debugging help
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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for some jackd debugging help
> > On Sun, 2020-03-29 at 11:35 +0200, Fons Adriaensen wrote: > > This *should* work of course, but I'm wondering why things are > > donethat 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 > > nexttrack ? > > 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 renderthread that > > > are not intended for use in that thread. > > > > Which ones are you calling there ? Normally there is no needat all > > to call Jack from the its own process() callback. > > > All jack client client call backs are handles througha message > > > queue, > > > > Except for process() I hope. Which other callbacks are youusing ? > > 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 anddisconnections > > > 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- > > > servershutdown 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 anyreason (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 tendsto run clients out of order, which depending on the > > application maygo unnoticed, or be a serious problem. > > Jack1 specifically doesn't provide glitch-less jack connection > changes, so that is not an option. -Ethan signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for some jackd debugging help
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 Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Looking for some jackd debugging help
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 > Linux-audio-dev@lists.linuxaudio.org > https://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Looking for some jackd debugging help
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 signature.asc Description: This is a digitally signed message part ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
