Hi Jack-devel,
This time it's not an impossible-to-reproduce bug, but a feature request!
Let me know it there's a better place to post this. I think similar things
have been suggested before, but this idea for a 'loopback' client hasn't as
far as I'm aware.
A loopback Jack client to intercept streams to and from partially
Jack-aware programs such as SMPlayer and Firefox would be useful. Both of
these programs output audio to Jack, but only to the system ports, which
makes routing the audio inconvinient. My setup includes a Jack client for
pre-speaker processing (called "Apps Out"), which reduces the audio by 35
dB and applies EQing, so any unexpected connetions directly to the system
ports are inconveniently loud and muddy. Even if these programs gain
support for changing their default output ports, there may be other
programs that won't.
The ALSA loopback device effectively pretends to be hardware, so most
ALSA-aware programs will be connected by default to Apps Out (and its
counterpart "Apps In"), as there is a persistent connection between these
clients and the ALSA-Jack bridge. Some way of configuring a Jack session so
that programs would think that Jack's hypothetical loopback client is the
system capture/plackback - with the real system capture/playback appearing
to be a non-system client - would solve everything. Like adding a monitor
strip for use between the apps and the hardware.
Failing that, is there a way I can force partially Jack-aware programs to
use the ALSA loopback device instead of Jack, maybe by hiding Jack's
existence?
- Tom
Whoops, putting the list back in the email.
Default system output, that is.
On 31 December 2016 at 23:35, Thomas Howe <tho7maspenguin(a)gmail.com> wrote:
> Ah, I have no idea how Jack works on MacOS. As far as I know it isn't
> possible on Linux to specify a Jack port as the default output.
>
> On 31 December 2016 at 23:02, Michael <keybounce(a)gmail.com> wrote:
>
>>
>> On 2016-12-31, at 2:41 PM, Thomas Howe <tho7maspenguin(a)gmail.com> wrote:
>>
>> Maybe I'm using the wrong terms. I mean it has its own Jack client
>> 'Firefox' whenever it runs, unlike programs like Flash which rely on
>> ALSA/PulseAudio, so it's Jack-aware. Firefox seems to lack features that
>> would let me establish a persistent connection between its Jack client and
>> another Jack client, which would generally be expected of a Jack-aware
>> program, so that's why I used "partially Jack-aware".
>>
>>
>> Hmm?
>>
>> First, you're talking about Jack/Firefox on Linux; I'm talking about
>> Jack/Firefox on MacOS.
>>
>> With that said, any program that talks to Jack through the default audio
>> out (10.9.5, when this was still possible) shows up as the program name. In
>> the case of firefox, I will see Firefox or plugin-container, depending on
>> firefox native or flash.
>>
>> But this is just using the normal audio out system on Macs; this is the
>> same system that fails on 10.10 or later (as I understand it, only programs
>> that let you explicitly select an audio device can talk to Jack on those
>> OS's; since Firefox/flash, as well as most games and other programs, only
>> talk to the default audio device, none of them can use Jack on newer Mac
>> OS's.)
>>
>>
>>
>> On 31 December 2016 at 17:06, Michael <keybounce(a)gmail.com> wrote:
>>
>>>
>>> On 2016-12-30, at 7:26 PM, Thomas Howe <tho7maspenguin(a)gmail.com> wrote:
>>>
>>>
>>> A loopback Jack client to intercept streams to and from partially
>>> Jack-aware programs such as SMPlayer and Firefox would be useful. Both of
>>> these programs output audio to Jack, but only to the system ports, which
>>> makes routing the audio inconvinient.
>>>
>>>
>>> When you call Firefox "partially Jack-aware", what do you mean? I can
>>> only get firefox to output to the default system audio; I can set that to
>>> Jack, but neither Firefox nor flash do anything special when playing videos
>>> / ogg files / etc.
>>>
>>> ---
>>> Entertaining minecraft videos
>>> http://YouTube.com/keybounce <http://youtube.com/keybounce>
>>>
>>>
>> _______________________________________________
>> Jack-Devel mailing list
>> Jack-Devel(a)lists.jackaudio.org
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>>
>> ---
>> Entertaining minecraft videos
>> http://YouTube.com/keybounce
>>
>>
>
Hi!
I'm writing, becasue I recently have a problem that I think is closely
related to JACK.
A few days ago, suddenly I was unable to play or record anything.
I found out that I can use my soundcards in Ardour only if I use ALSA as a
backend - not JACK.
Running JACK with 3 different audio interfaces everytime spawns 32 in / 32
out channels in the "System" JACK hardware clients - and none of that works.
I thought there's a problem with my system installation, but the same
problem occured when I booted up an AV Linux LiveCD - and that really
confused me.
I described the issue in more detail on LinuxMusicians.com forums:
https://www.linuxmusicians.com/viewtopic.php?f=27&t=16527
I'd like to invite you to take a look.
- unfa
Hi list.
I am sure this has been answered before:
On windows: I am running audio from ableton to a spatialisation software
and from the spatialisation software to the soundcard.
The latency added for each step seems to be equal to the vector size
setting (for instance 512)? Meaning that the output latency for such a
setup would be 1024?
Is this correct?
Thank you list!
All the best
Thor
Dear All,
What exactly is the difference between *jack_midi_event_reserve* and
*jack_midi_event_write* ?
In particular, if I call *jack_midi_event_write*, does it actually copy
the data from the buffer, which I provide?
Or does it use that same buffer.
Another question is how can I send midi events generated from GUI,
(which does not run in the audio callback)?
My guess is to cache them somewhere and transmit them inside the callback?
Am I guessing correctly?
Cheers,
Robert
hi there
i already opened up an issue on github [1] but it seems there is more
activity. so i decided to send my problem also to this list, i hope
that's ok?
we have a setup here with one jackd2 instance running with netmanager as
audio-master and one jackd2 instance connecting to it via netjack2 as
audio-slave.
when i restart the jack daemon on the slave i occasionally end up with
an unusable jackd2 instance on the master.
this seems to come from the way the netmanager component destroys
handles for netjack2 masters (JackNetMasterInterface instances)
if a netjack2 master handle encounters a network error or the connection
gets closed, it sends its own jackd process a KILL_MASTER signal via a
local socket. if this packets gets lost the jackd2 process gets rendered
unusable (other local jack-clients and netjack clients can process audio
anymore...)
the quick(!) choice to evaluation if i'm on the right track was to
remove sending of this multicast packet and setting a newly introduced
flag fExit in the JackNetMasterInterface::Exit method.
in JackNetMasterManager::Run i hooked up to check all netjack2 slaves
periodically for this fExit flag and if it is set, it gets removed&the
the associated objects deleted.
i also removed the call to pthread_exit and instead switched to throwing
an exception as it gets catched (by the netjack1 code anyway) by
JackNetMaster::SetProcess.
my testsetup was two machines, one running with netmanager and one
connecting to it via netjack2.
i restart the jackd process periodically.
one cycle consists of
- starting jackd
- wait for 10 seconds
- stop jackd
- wait for 5 seconds
after about ~10 minutes the jackd on the master (which doesn't get
restarted) runs into the problem and is unusable from this moment on.
with the patch attached to the issue the jackd process gets unusable
after ~12 hours (this time with the logoutput i attached to the issue) i
don't know if this is still a problem with my patch (besides it needs
much nicer integration anyway) or i hit another problem here.
i would be glad if someone could have a look on it and point me in the
right direction!
thanks!
Jan
[1] https://github.com/jackaudio/jack2/issues/239
--
Barco Control Rooms GmbH
Greschbachstrasse 5a
D - 76229 Karlsruhe
http://www.barco.com
mailto:jan.reusch@barco.com
__________________________________________________________________________________________
Registered at 76229 Karlsruhe, Amtsgericht Mannheim, HRB 102241,
Management: Piet Candeel, Lutz Nehrhoff von Holderberg
This message is subject to the following terms and conditions: MAIL DISCLAIMER<http://www.barco.com/en/maildisclaimer>
Hi all,
I'm having a problem with the jackdbus process; after some hours it starts
maxing out two of my four CPU cores, which in turn causes xruns when
running apps. It looks like other people have found the same problem, but
no solutions.
Here's a video of this happening:
https://drive.google.com/open?id=0B2eROo5JatB4eHZweUtROTduSWc
I cut the important bits out and sped it up. It shows me starting jack via
QJackCtl with a monitor of the log file and QJackCtl's messages in the
first section, the processor spike in the second, an xrun in the third, and
the processors returning to normal in the fourth. There's a clock at the
bottom left corner of the screen.
I'm running Arch with the Linux 4-8-4.1-ARCH (x86_64) kernel. Let me know
what other information would be useful! I can't figure out how to even
start debugging this.
Thanks for watching,
Tom
(putting back jack-devel again)
It just says that it configures for 22050Hz, it doesn't say whether it
succeeded.
So things seems to work as it should.
On Tue, Dec 13, 2016 at 10:38 AM, ROBERT WOLF <
robert.wolf(a)hercsmusicsystems.com.au> wrote:
> Two programs show this information:
>
> 1. QJackCtl.
> 2. When I run my own program *AND* jack server is not running, *THEN* for
> some reason the jack server gets started (apparently using the command
> stored in .jackdrc file) and I see the following printout:
>
> jackd 0.122.0
> Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn
> and others.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
>
> JACK compiled with System V SHM support.
> loading driver ..
> apparent rate = 22050
> creating alsa driver ... hw:PCH,0|hw:PCH,0|1024|2|
> 22050|0|0|nomon|swmeter|-|32bit
> ALSA lib conf.c:4578:(parse_args) Unknown parameter 1
> ALSA lib conf.c:4711:(snd_config_expand) Parse arguments error: No such
> file or directory
> ALSA lib control.c:953:(snd_ctl_open_noupdate) Invalid CTL hw:PCH,0
> control open "hw:PCH,0" (No such file or directory)
> configuring for 22050Hz, period = 1024 frames (46.4 ms), buffer = 2 periods
> ALSA: final selected sample format for capture: 32bit integer little-endian
> ALSA: use 2 periods for capture
> ALSA: final selected sample format for playback: 32bit integer
> little-endian
> ALSA: use 2 periods for playback
>
>
>
> *HOWEVER!!!! **jack_get_sample_rate(...);* still reports *44100*.
>
> How intriguing?!
>
>
>
> On 13/12/16 19:53, Kjetil Matheussen wrote:
>
> Which program shows this window?
>
> (added jack-devel mailing list back to the conversation)
>
> On Tue, Dec 13, 2016 at 8:35 AM, ROBERT WOLF <robert.wolf@
> hercsmusicsystems.com.au> wrote:
>
>> There is a window with messages and it says this:
>>
>> configuring for 22050Hz, period = 1024 frames (46.4 ms), buffer = 2
>> periods
>>
>>
>> On 13/12/16 11:09, Kjetil Matheussen wrote:
>>
>>
>>
>> On Mon, Dec 12, 2016 at 7:33 AM, ROBERT WOLF <
>> robert.wolf(a)hercsmusicsystems.com.au> wrote:
>>
>>> Dear All,
>>>
>>> According to the documentation *jack_get_sample_rate* reports the
>>> sample rate as was used by *jackd*.
>>> This does not happen in my case.
>>> I start *jackd* using different sampling rates (i.e. 22050, ect.).
>>> JACK reports that it does indeed uses the selected sampling rate.
>>>
>>> But *jack_get_sample_rate* always returns 44100.
>>>
>>> Why?
>>>
>>>
>> How did Jack report that it used the selected sampling rate?
>> I.e. where did you read that?
>>
>>
>>
>>
>
>
Which program shows this window?
(added jack-devel mailing list back to the conversation)
On Tue, Dec 13, 2016 at 8:35 AM, ROBERT WOLF <
robert.wolf(a)hercsmusicsystems.com.au> wrote:
> There is a window with messages and it says this:
>
> configuring for 22050Hz, period = 1024 frames (46.4 ms), buffer = 2 periods
>
>
> On 13/12/16 11:09, Kjetil Matheussen wrote:
>
>
>
> On Mon, Dec 12, 2016 at 7:33 AM, ROBERT WOLF <robert.wolf@
> hercsmusicsystems.com.au> wrote:
>
>> Dear All,
>>
>> According to the documentation *jack_get_sample_rate* reports the sample
>> rate as was used by *jackd*.
>> This does not happen in my case.
>> I start *jackd* using different sampling rates (i.e. 22050, ect.).
>> JACK reports that it does indeed uses the selected sampling rate.
>>
>> But *jack_get_sample_rate* always returns 44100.
>>
>> Why?
>>
>>
> How did Jack report that it used the selected sampling rate?
> I.e. where did you read that?
>
>
>
>