JackAudio August 2017

jackaudio@lists.linuxaudio.org

13 participants
7 discussions

Re: [Jack-Devel] Jack server keeps playing sound after client disconnetcs

by Ralf Mardorf

On Thu, 24 Aug 2017 11:50:23 -0700, Yuri wrote: >On 08/24/17 10:31, Ralf Mardorf wrote: >> seemingly jackaudio.org was down, so consider to resend your concerns >> to the mailing list, since it's up again. I'm not a jackd developer, >> just a user and simply try to point out, that Ctrl+C isn't a shortcut >> that ensures a specific action of an application. You seem to assume >> that Ctrl+C does kill an app or something similar, but actually an >> app is free to continue running or to do anything else. > > >No, I am not assuming this. Ctrl+C, of course, doesn't guarantee a >particular action. I am just pointing out that in case of a >client-server architecture, which is the case here, server can't rely >on the client to always take a particular action before disconnecting. >It is a much more sound strategy to always clean up after >disconnecting client regardless of what the client did. > > >So, you are saying that all OSes suffer from this problem, not only >FreeBSD? One client I observed this recently with is 'sclang' from >SuperCollider. Hi, I don't know, I'm on Linux, but don't use Ctrl+C to exit an app launched by command line, that is a jackd client. Either I'm using the apps regular options to exit or if something should go wrong, I'm using a script to send all apps that are part of a jackd session, including jackd, a SIGKILL, before the same script restores the jackd session. IMO a sound server aimed for real-time usage should assume that clients do the right thing. Much likely the sound architecture of FreeBSD isn't that reliable for a real-time audio sound server as ALSA in combination with the Linux kernel's real-time capabilities is. Actually I don't understand the problem. Why do you sent a SIGINT to an app? What is done by the app, after receiving the SIGINT? I don't know what jackd does or should do. The strategy you mentions might be right or wrong, however, using Ctrl+C IMO is asking for trouble, since we seldom know what action does follow. Regards, Ralf

8 years

Re: [Jack-Devel] ?==?utf-8?q? Jack server keeps playing sound after client disconnetcs

by Ralf Mattes

Sorry, used the wrong sender: Am Freitag, 25. August 2017 10:42 CEST, "Ralf Mattes" <r.mattes(a)mh-freiburg.de> schrieb: > > Am Freitag, 25. August 2017 04:15 CEST, Yuri <yuri(a)rawbw.com> schrieb: > > > Sorry, but you are completely wrong. It's Jack that doesn't clean up> after the failed clients that is a problem. > > > > So far this is only your diagnosis and it's backed up by very little evidence. > You haven't provided us with information about the real symptoms - > "old audio" is a pretty broad description. Are we talking about the amount > of audio data that gets processed in one jack process callback (as Chris Claude > wrote, that would be sample-rate / (n-periods * buffer-size) ). I doubt you can > even hear this. For anything longer, I think your diagnosis is off. Where should > those sample came from? Who would be filling the shared memory buffers? > I think for any serious debugging you need to provide us with better symptom > descriptions. For example, as Ralf already did notice, sending an interrupt signal > to a process doesn't mean that that process dies an instant death. The process could > have installed a signal handler that performs, a graceful fade-out. Also, you wrote: > > > This particluar application, sclang, doesn't quit by itself without > > Ctrl-C, if this isn't encoded in the script. > > I hope you now that sclang is not a jack (audio) client, it's only an interpreter that > controls the supercollider server process (scsynth or supernova) by means of OSC > messages. You either need to send the server a stop message or kill it. > > Sorry, but you are completely wrong. It's Jack that doesn't clean up> after the failed clients that is a problem. > > Can you describe what you would expect as a "clean up? AFAIK jackd plays the > last filled buffer, then detects that the client fails to fill the buffers and "zombifies" > (read: kills) the client - unless you told the server not to! Did you? Or did you crank up > the client timeout? > > Cheers, Ralf Mattes > > > > Yuri > > > > > > _______________________________________________> Jack-Devel mailing list > > Jack-Devel(a)lists.jackaudio.org > > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org >

8 years

Re: [Jack-Devel] Jack server keeps playing sound after client disconnetcs

by Ralf Mardorf

On Thu, 24 Aug 2017 08:56:40 -0700, Yuri wrote: >On 08/24/17 08:51, Ralf Mardorf wrote: >> FWIW SIGINT could be handled by the client, IOW Ctrl+C not >> necessarily does what you expect it to do, Ctrl+C doesn't result in >> e.g. SIGKILL. > > >If Jack relies on clients to clean up, this will require fixing a lot >of clients for this to work. It is better if this is handled in the >server. Hi Yuri, seemingly jackaudio.org was down, so consider to resend your concerns to the mailing list, since it's up again. I'm not a jackd developer, just a user and simply try to point out, that Ctrl+C isn't a shortcut that ensures a specific action of an application. You seem to assume that Ctrl+C does kill an app or something similar, but actually an app is free to continue running or to do anything else. Regards, Ralf

8 years

[Jack-Devel] Jack server keeps playing sound after client disconnetcs

by Yuri

After the user hits Ctrl-C on the client, jackd keeps playing some sound it got from this client. Only jackd restart helps. Why doesn't the server clear the buffer when client disconnects? What part of code is responsible for cleaning up after a disconnected client? Problem is observed on the FreeBSD 11.1 with jack-0.125.0 Yuri

8 years

[Jack-Devel] Jack: "Too many servers already active"

by Malik Costet

Cheers everyone, As part of my testing of, and indeed as (an intended) part of the software I'm writing, I'm starting and stopping many jackd instances on the box in question (a Pi). Today, to my surprise, I seem to have hit upon some kind of limit, for attempts to launch a server (via the command-line) fail with the message "Too many servers already active". I haven't kept count, but I might have successfully started and stopped a couple dozen instances of JACK before that happened (only ever one at a time, though). Now, the point is, there definitely *aren't* any jackd processes running at the time I'm executing that command. So I'm wondering whether there's perhaps some environment setting that JACK checks? Or something? Note that a restart of the system fixes the issue. That wouldn't be an acceptable long-term solution, however. For what it's worth, I'm running JACK on a headless environment, and am setting DISPLAY=:0 to work around the DBUS issues. Ideas, suggestions, etc. much welcome. M.

8 years

[Jack-Devel] Question JackAudio

by Vintsent Bekaert

Hi guys, First of all, sorry for my bad English. So here's my question: Im a DJ playing traktor (64 bit) and I want to use Ableton (64bit) effects. In order to do so I need to route my traktor audio in Ableton. I use a Native Instruments Audio 10 interface. Is there a solution with Jackrouter for 64-bit? And how to do so? Greets, -- Vintsent Bekaert

8 years, 1 month

[Jack-Devel] Cannot combine audio devices with more than 64 channels

by Jörg Müller

I need to combine two HDSPe MADI FX cards to one virtual device. I have a working driver, which is alsa-compatible. I can select each single card in any alsa-compatible application and all channels work flawless. For combining the MADI FX cards to one virtual device, I created an .asoundrc with 194 inputs for each card. When I start that virtual device via jackd -R -d alsa -C madifx_record_all -P madifx_playback_all I get this error: > creating alsa driver ... > madifx_playback_all|madifx_record_all|1024|2|48000|0|0|nomon|swmeter|-|32bit > jackd: pcm_multi.c:1060: snd_pcm_multi_open: Assertion `!slave_map[sidxs[i]][schannels[i]]' failed. However, it works when I reduce the amount from 194 to 64 channels per card. I tried to use 128 channels per card, but that fails the same way. See my alsa-info attached, which also includes the .asoundrc content. I also found this, which might be related: https://ccrma.stanford.edu/mirrors/lalists/lad/2005/06/0202.html To me, this looks like a bug. What do you think?

8 years, 1 month

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

JackAudio August 2017