[Jack-Devel] Jack and thunderbolt

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

[Jack-Devel] Jack and thunderbolt

liebrecht
I really battle to find the optimum solution for ultra low latency
monitoring using Linux.
Since I am using Jack I have a few compatibility questions.

1) Is jack known to be able to work with thunderbolt 3 on Linux ?
2) Thunderbolt included, what is the lowest latency sound transport
format that jack can work within your opinion on Linux
e.g. thunderbolt / AES50 / Ultranet / Madi / etc
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

Bill Gribble
I haven’t measured lowest-possible latency, but I successfully use thunderbolt 3 from my HP laptop running Linux, via an Apple thunderbolt to FireWire adapter, to a Mackie Onyx FireWire mixer.  The mixer appears as a normal FireWire interface to Jack.

bg

> On Dec 5, 2018, at 17:47, [hidden email] wrote:
>
> I really battle to find the optimum solution for ultra low latency monitoring using Linux.
> Since I am using Jack I have a few compatibility questions.
>
> 1) Is jack known to be able to work with thunderbolt 3 on Linux ?
> 2) Thunderbolt included, what is the lowest latency sound transport format that jack can work within your opinion on Linux
> e.g. thunderbolt / AES50 / Ultranet / Madi / etc
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

Chris Caudle
In reply to this post by liebrecht
On Wed, December 5, 2018 4:47 pm, [hidden email] wrote:
> I really battle to find the optimum solution for ultra low latency
> monitoring using Linux.

For monitoring while recording, hardware monitoring is often optimum

> Since I am using Jack I have a few compatibility questions.
> 1) Is jack known to be able to work with thunderbolt 3 on Linux ?

The jackd server uses ALSA for interfacing to most audio devices, although
it does have a way to directly use some Firewire devices.  Really the
question should be is there a driver for a particular Thunderbolt device
you want to use.
My understanding is that Thunderbolt is basically PCIe with some slight
modifications to allow hot plugging cables, determining whether the
peripheral needs PCIe or DisplayPort protocol, a few other things, but the
important point being it does not define audio transport as for example
USB audio class does, so even if one Thunderbolt interface is supported by
ALSA, that does not mean that other Thunderbolt interfaces would be
supported, you would still need a driver that takes care of register level
access to the specific device you want to use.


> 2) Thunderbolt included, what is the lowest latency sound transport
> format that jack can work within your opinion on Linux
> e.g. thunderbolt / AES50 / Ultranet / Madi / etc

That question is not well formed.  Thunderbolt is a data transport used in
computers, not specifically an audio transport. AES50 and MADI are
specifically an audio transports, and no computer has a direct AES50 or
MADI connection.  So again, the question is what particular  audio device
would you like to use, and then see if there is an ALSA driver available.

The lowest latency would be PCIe connection from your processor to a
device with analog converters on board.  Many people have reported good
results from RME devices over the years.
If you happen to already have an analog converter you like with AES3 or
MADI interface, RME has cards with those transports as well.

But that is specifically just addressing the lowest latency way to get
data from your processor to an analog audio connection.  You did not
explain what you are trying to achieve, so spending money on an interface
that can run with low latency may not be the best way to achieve what you
really want.  Not to mention that there are many more system
considerations than just interface transport in determining latency, you
can spend quite a bit of time optimizing your system for low latency, but
there are still quite a few things out of your control on a modern Intel
based system (such as system management mode firmware that runs outside of
the control of the kernel scheduler).

So do you need low latency for monitoring while recording?  Probably
hardware monitoring is optimal (either with an interface that supports
hardware monitoring, or by using an external analog mixer, preamp, etc.
which supports monitoring features).
For software synthesizers?  Then system latency will probably dominate
over audio interface, you will have plenty to work on before nearly any
interface is the limiting factor.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

Ralf Mardorf
On Thu, 6 Dec 2018 20:56:25 -0600, Chris Caudle wrote:
>The lowest latency would be PCIe connection from your processor to a
>device with analog converters on board.  Many people have reported good
>results from RME devices over the years.

FWIW I get lower latency using an USB Focusrite Scarlett 18i20 2nd gen,
than using a PCIe RME HDSPe AIO, let alone that Linux can not access
all IOs of the RME HDSPe AIO and that it can not be used with ALSA
directly when using Ardour, this RME card can only be used with jack
when using Ardour. It was this way with my old AMD machine and hasn't
changed for my new Intel machine. Regarding MIDI jitter my best
experiences are with PCI (Envy24, Terratec EWX 24/96) and PCIe (RME
HDSPe AIO), but regarding audio latency USB (Presonus 1818VSL and even
lower when using a Focusrite Scarlett 18i20 2nd gen) works best for me.
YMMV! However, hardware monitoring when using Class Compliant USB
devices usually can't be done by the audio device's internal routing, a
mixing console is needed for latency free monitoring, while cards that
need an individual ALSA driver, such as the HDSPe AIO might be able to
use the internal hardware routing (e.g. by hdspmixer).

--
pacman -Q linux{,-rt{-cornflower,,-securityink,-pussytoes}}|cut -d\  -f2
4.19.7.arch1-1
4.19.5_rt4-0
4.19.1_rt3-0
4.19_rt1-0
4.18.16_rt9-1
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

Ralf Mardorf
On Fri, 07 Dec 2018, [hidden email] wrote:

>On 2018-12-07 00:54, Ralf Mardorf wrote:
>> However, hardware monitoring when using Class Compliant USB devices
>> usually can't be done by the audio device's internal routing, a
>> mixing console is needed for latency free monitoring, while cards
>> that need an individual ALSA driver, such as the HDSPe AIO might be
>> able to use the internal hardware routing (e.g. by hdspmixer).
>Thanks all for the insightful responses.
>
>The last part of your answer is something I dont see often.
>Do you have any point of departure where I can read up about which
>devices can access the onboard DSP of audio interfaces such as those
>you mention eg 1818vsl or other. It is the first time I see hints of
>someone or programs able to access the onboard DSP for low latency
>monitoring. Didnt see this ever mentioned but it is desperately
>needed. After receiving your post I tried to find similar on the web,
>but it is all very unclear what is possible and for which devices.

Please reply to the mailing list and don't top-post.

That is probably a misunderstanding. The Presonus and the Focusrite 2nd
gen USB devices don't provide access to the device's internal routing
when using it with a Linux machine. They are class compliant and don't
need individual drivers. Sound devices that aren't class compliant need
an individual driver and there might be access to the device's internal
routing, as there is for some RME audio devices, when using the Linux's
hdspmixer wich is similar to RME's totalmix,
http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php.

Monitoring without latency means, that you could route the input
channels, directly to the output channels. IOW if you connect a
microphone, you could listen to the unprocessed signal without latency,
it's not the signal processed by your Linux machine.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

liebrecht

>
> Please reply to the mailing list and don't top-post.
>
> That is probably a misunderstanding. The Presonus and the Focusrite 2nd
> gen USB devices don't provide access to the device's internal routing
> when using it with a Linux machine. They are class compliant and don't
> need individual drivers. Sound devices that aren't class compliant need
> an individual driver and there might be access to the device's internal
> routing, as there is for some RME audio devices, when using the Linux's
> hdspmixer wich is similar to RME's totalmix,
> http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php.
>
> Monitoring without latency means, that you could route the input
> channels, directly to the output channels. IOW if you connect a
> microphone, you could listen to the unprocessed signal without latency,
> it's not the signal processed by your Linux machine.
>

Thank you for the explanation.
That answers most of my questions very nicely, even ones I havent asked
yet.

reply do not list the usergroup address but the poster so this will
happen every now and then.
It involves reply all then remove the to: address and cut and paste the
cc (which is the group address) into to: it is the way the group
software adds addresses.
the group address should ideally be in the reply-to and not a cc, but I
will do the abovementioned workaround.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] AVB

liebrecht
In reply to this post by Ralf Mardorf
My last question.

Thank you for helping so far.

I see there is development going for AVB using Intel I210 NIC
"https://sourceforge.net/projects/open-avb/"
and
"https://github.com/AVnu/OpenAvnu"

I know I can ask there, but it would be better to know from the Jack
perspective as the buck most likely stops here before it can be deemed
useful.

Is the development of AVB on Linux that far down the road that the Jack
Developers can work with AVB ?
Also what is your prospects for when it might come available.


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Ralf Mardorf
Hi,

some users shared experiences at the Linux Audio User mailing list, see
https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB.

Consider to read those threads and if you should still have questions
after reading, to subscribe to the Linux Audio User mailing list and to
send a request to this list,
https://lists.linuxaudio.org/listinfo/linux-audio-user.

Regards,
Ralf
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Christoph Kuhr
Hi,

in our research project we are implementing a JACK AVB Interface.
I presented it on the last Linux Audio Conference:

http://lac.linuxaudio.org/2018/pages/event/43/

https://media.ccc.de/v/lac2018-43-software_architecture_for_a_multiple_avb_listener_and_talker_scenario


Best,
Ck


On 12/08/2018 09:32 AM, Ralf Mardorf wrote:

> Hi,
>
> some users shared experiences at the Linux Audio User mailing list, see
> https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB.
>
> Consider to read those threads and if you should still have questions
> after reading, to subscribe to the Linux Audio User mailing list and to
> send a request to this list,
> https://lists.linuxaudio.org/listinfo/linux-audio-user.
>
> Regards,
> Ralf
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Christoph Kuhr
On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend.




On 12/08/2018 02:35 PM, Christoph Kuhr wrote:

> Hi,
>
> in our research project we are implementing a JACK AVB Interface.
> I presented it on the last Linux Audio Conference:
>
> http://lac.linuxaudio.org/2018/pages/event/43/
>
> https://media.ccc.de/v/lac2018-43-software_architecture_for_a_multiple_avb_listener_and_talker_scenario 
>
>
>
> Best,
> Ck
>
>
> On 12/08/2018 09:32 AM, Ralf Mardorf wrote:
>> Hi,
>>
>> some users shared experiences at the Linux Audio User mailing list, see
>> https://www.google.com/search?&q=linux+audio+user+mailing+list+AVB.
>>
>> Consider to read those threads and if you should still have questions
>> after reading, to subscribe to the Linux Audio User mailing list and to
>> send a request to this list,
>> https://lists.linuxaudio.org/listinfo/linux-audio-user.
>>
>> Regards,
>> Ralf
>> _______________________________________________
>> Jack-Devel mailing list
>> [hidden email]
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

liebrecht
On 2018-12-08 08:37, Christoph Kuhr wrote:
> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend.
>

Thanks all for the response, it helped me a lot to make the right
decissions.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

David Kastrup
In reply to this post by Ralf Mardorf
Ralf Mardorf <[hidden email]> writes:

> That is probably a misunderstanding. The Presonus and the Focusrite
> 2nd gen USB devices don't provide access to the device's internal
> routing when using it with a Linux machine. They are class compliant
> and don't need individual drivers. Sound devices that aren't class
> compliant need an individual driver and there might be access to the
> device's internal routing, as there is for some RME audio devices,
> when using the Linux's hdspmixer wich is similar to RME's totalmix,
> http://www.rme-audio.de/en/support/techinfo/hdsp_totalmix_software.php.
>
> Monitoring without latency means, that you could route the input
> channels, directly to the output channels. IOW if you connect a
> microphone, you could listen to the unprocessed signal without
> latency, it's not the signal processed by your Linux machine.

It's not entirely without latency since sample acquisition and
downsampling and interpolation filtering take its time as well, as to
the actual mixing and then going back into the analog domain with
similar measures.

I think it's in the order of 2ms of latency you have to take into
account.  It's not a lot but it certainly is latency.

--
David Kastrup
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and thunderbolt

Chris Caudle
On Tue, December 11, 2018 10:05 am, David Kastrup wrote:
> Ralf Mardorf <[hidden email]> writes:
>> Monitoring without latency means, that you could route the input
>> channels, directly to the output channels.

> It's not entirely without latency since sample acquisition and
> downsampling and interpolation filtering take its time as well, as to
> the actual mixing and then going back into the analog domain with
> similar measures.

There are some interfaces which have an analog mixer on an output so that
you can mix the input signal and the returned signal from the computer
interface directly in the analog domain.  The only latency on the input
side is analog propagation delay, which is usually not worth discussing in
an audio context.  That style of interface can be really convenient for
portable setups where you don't want to carry a mixer or monitor
controller with you.

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] Bitrate from Jack or USB driver

liebrecht
In reply to this post by Christoph Kuhr
I thought it was the last of my questions but I have two more, of this
is the first mail.

My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you
configure it to 96000Hz with the windows mixer.
It seems as soon as you close down the windows based presonus audiobox
software it defaults back to 44100Hz and soesnt keep it in memory when
you use it on Linux.

Questions:
1) I need to confirm the above.
Is there any way jack can report the bitrate of the data it receives
from usb driver and therefore the bitrate by which the presonus 1818vsl
send the data.

2) If the 1818vsl does revert back after a windows config at a higher
rate, is there any current facility in jack to configure the presonus to
work with 96000Hz ?
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

[Jack-Devel] jackd start/stop

liebrecht
In reply to this post by Christoph Kuhr
I could not find a solution online for such a trivial matter, therefore
my question here.

jackd is not a service as I tried to stop and start it with
service jackd stop/start and it reports no such service

Therefore it seems the only way to stop jackd is with
kill -9 <pid>
That would be fine, but there is no such process jackd when i do ps.

# ps -A |grep -i jack
  2905 ?        00:01:02 jackdbus

There is is only jackdbus which must be something else.

I can see that ardour/mixbus calls jackd with parameters at startup, but
if I manually try to start jackd it says it is already running .... but
it has no PID. So is it a runaway process on my system.

jack disappears often and I have to reboot to get it back, obviously
want to avoid that if I can stop and start it cleanly, or preferably
reset it cleanly erasing all lock files if any exists etc.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Bitrate from Jack or USB driver

Robin Gareus
In reply to this post by liebrecht
On 12/14/18 8:47 AM, [hidden email] wrote:

> I thought it was the last of my questions but I have two more, of this
> is the first mail.
>
> My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you
> configure it to 96000Hz with the windows mixer.
> It seems as soon as you close down the windows based presonus audiobox
> software it defaults back to 44100Hz and soesnt keep it in memory when
> you use it on Linux.
>
> Questions:
> 1) I need to confirm the above.

I don't have this issue. The device works fine at 44.1k and 48k. I don't
use it at 96k.

I dimly recall users reporting various issues on Linux after using the
1717VSL on windows once, which resulted in a broken firmware update.
That was 2013-ish though. IIRC the solution was flashing the firmware.
That was reported on LAU or LAD.

If you still have access to a windows box, update the firmware as
described at
https://answers.presonus.com/17746/cannot-switch-samplerates-audiobox-1818vsl


> Is there any way jack can report the bitrate of the data it receives
> from usb driver
[..]

Probably not. Jack facilitates inter-application communication in
userspace. Hardware I/O on Linux happens at lower level.

you can try  https://community.ardour.org/files/adevices.sh which probes
/proc/asound/

Cheers!
robin
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Bitrate from Jack or USB driver

Chris Caudle
In reply to this post by liebrecht
On Fri, December 14, 2018 1:47 am, [hidden email] wrote:
> My presonus 1818vsl seemingly defaults to 44100 Hz never mind if you
> configure it to 96000Hz with the windows mixer.
> It seems as soon as you close down the windows based presonus audiobox
> software it defaults back to 44100Hz and doesn't keep it in memory when
> you use it on Linux.

Most USB devices will use whatever the driver requests if possible.  The
driver will request whatever the application which  opens the ALSA driver
requests if the driver accepts the request as supported by the card (USB
devices return a parameter list which shows what rates are supported).

> Questions:
> 1) I need to confirm the above.
> Is there any way jack can report the bitrate of the data it receives
> from usb driver and therefore the bitrate by which the presonus 1818vsl
> send the data.

Check the /proc/asound/ entry for your card.  See below, in my case it was
card0/pcm0p/info, depending on your card configuration it may be something
other than card0 and pcm0.
The script that Robin mentioned will dump that info for you.

> 2) If the 1818vsl does revert back after a windows config at a higher
> rate, is there any current facility in jack to configure the presonus to
> work with 96000Hz ?

Sure, just specify what sample rate you want to use when you start jackd
and it will send that request to the ALSA driver, which should send that
request to the hardware.

Startup with 48k requested:

$ jackd -dalsa -dhw:Lambda -r48000
jackdmp 1.9.12
...startup messages, copyright, blah blah...
Acquire audio card Audio0
creating alsa driver ...
hw:Lambda|hw:Lambda|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian in
3bytes format

Startup with 44.1k requested:
$ jackd -dalsa -dhw:Lambda -r44100
...startup messages, copyright, blah blah...
Acquire audio card Audio0
creating alsa driver ...
hw:Lambda|hw:Lambda|1024|2|44100|0|0|nomon|swmeter|-|32bit
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian in
3bytes format

Startup with 96k requested (note this is not supported, so defaults to
closest supported value, which in this case is 48k):
$ jackd -dalsa -dhw:Lambda -r96000
...startup messages, copyright, blah blah...
Acquire audio card Audio0
creating alsa driver ...
hw:Lambda|hw:Lambda|1024|2|96000|0|0|nomon|swmeter|-|32bit
configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 24bit little-endian in
3bytes format

Note that jackd does not warn the rates do not match, which is not what I
expected.

$ cat /proc/asound/card0/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 2048

I thought that the ALSA driver would return the value of the actual sample
rate used, and jackd would check that and display if the rate in use did
not match the requested rate.  Apparently not, at least not for all cards,
maybe driver dependent.

--
Chris Caudle



_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jackd start/stop

Chris Caudle
In reply to this post by liebrecht
On Fri, December 14, 2018 2:11 am, [hidden email] wrote:
> jackd is not a service as I tried to stop and start it with
> service jackd stop/start and it reports no such service

Correct, it is a userspace application that needs to be started under your
user account.  Applications using jackd for routing have to be able to
share a memory buffer, so you cannot for example run jackd as a system
service that any or multiple users could use.

> Therefore it seems the only way to stop jackd is with
> kill -9 <pid>

If you start from a command line you can use control-c key combination.
Often users start from the qjackcontrol application, the application has a
"stop" button which can be used to stop jackd.  I also have my
qjackcontrol set to run "killall jackd" on exiting just in case the jackd
process hung for some reason and did not respond to control commands, but
I have not actually seen that happen, it is just a precaution.

Look in your applications directory, probably /usr/bin on most
distributions, might be in /bin on some.
There should be several apps with jack in the name.  These could be useful
to you:
/usr/bin/jack_connect
/usr/bin/jack_control
/usr/bin/jack_disconnect
/usr/bin/jack_lsp
/usr/bin/jack_samplerate
/usr/bin/jack_server_control


> That would be fine, but there is no such process jackd when i do ps.
> # ps -A |grep -i jack
>   2905 ?        00:01:02 jackdbus
>
> There is is only jackdbus which must be something else.

There are two variants of what is called version 2 of jackd, stand alone
jackd and jackdbus, which is jackd which exposes dbus controls.  For
various historical reasons what I called version 2 of jackd is not really
a continuation of version 1, it is another implementation of the same
userspace API with a completely different engine.  It started as an
experiment to try out some different features, but jackd 1 and jackd 2
ended up continuing in parallel, with slightly different internal
features, but same API presented to applications.  Since you have jackdbus
on your system that indicates your distribution ships jackd 2.

The jackdbus application is started using dbus, if you attempt to start it
manually it gives a warning:
jackdbus should be auto-executed by D-Bus message bus daemon.
If you want to run it manually anyway, specify "auto" as only parameter

Probably some application automatically started jackdbus when you started
the application. Hard to know which one that would have been.

> I can see that ardour/mixbus calls jackd with parameters at startup, but
> if I manually try to start jackd it says it is already running .... but
> it has no PID. So is it a runaway process on my system.

More probably jackd detects that there is already a process providing jack
API services, in your case jackdbus.  Use jack_control to query the
parameters, stop, etc.

> jack disappears often and I have to reboot to get it back

You do not really have to reboot, if your system is configured to use
jackdbus then just start an application which needs jackd and it will be
automatically started, or use jack_control start to start it manually.

Which distribution are you using?  You should be able to configure your
system to use jackd instead of jackdbus.  If you manually start jackd from
a terminal before starting any audio applications then jackdbus should
detect that another jackd server is running and not start, but you can
probably configure the audio applications to start jackd instead of
jackdbus if you would prefer.

Can you check what is in the ~/.jackdrc file?
(by the way, not sure how familiar you are with linux terminal use, just
reply if something is unclear, e.g. "~" means your user home directory).
Possibly either that file, or a system file in /etc/jackdrc is configured
to use jackdbus as the default jack server.  My drc file has this for
example:
/usr/bin/jackd -P70 -t2000 -dalsa -dhw:Lambda -r48000 -p1024 -n3 -zt -I376
-O376

That indicates to applications that want to automatically start a jack
server that my preference is jackd (instead of jackdbus), 2000 millisecond
timeout for applications to respond, ALSA driver backend, my Lambda audio
interface, 48k sample rate, 1024 samples per period, 3 periods buffering
latency, use triangular PDF dither, and report 376 samples of input and
output latency.
You do not have to set all of those backend parameters, you may be able to
get away with defaults for some.

I doubt you will care about the differences between jackd and jackdbus
though after finding jack_control, it sounds like you just have not
experimented enough to find all the various jack application yet.
Admittedly they are not documented very well.  I'm not sure jackdbus is
documented anywhere in an easy to find form, the jack website just has man
pages for jackd, which has probably contributed to your confusion:
https://github.com/jackaudio/jackaudio.github.com/wiki/jackd(1)
https://github.com/jackaudio/jackaudio.github.com/wiki/jackdrc%285%29

The jack_control wiki page is probably the only place that mentions jackdbus:
https://github.com/jackaudio/jackaudio.github.com/wiki/WalkThrough_User_jack_control

--
Chris Caudle


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

Jörn Nettingsmeier-5
In reply to this post by Christoph Kuhr
On 12/8/18 2:37 PM, Christoph Kuhr wrote:
> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend.

I would say that for now, if you need to speak AVB, the easiest path is
to get a recent MOTU USB class-compliant device with an AVB port. That
way, the Linux system only needs to concern itself with the USB audio
part, and the routing in the MOTU connects you to the AVB world.
Thankfully, after being quite useless for open-source for many many
years, they've now made two good decisions:
* USB class compliance, and
* the masterstroke, i.e. implementing the mixer as a web server that can
be accessed via any browser, thus relieving open-source developers of
the tedious task of reverse-engineering a mixer that will then only work
on one particular device.

Christoph, would you agree, or can people who do not frequent the same
circles of hell as you are so competently doing consider "native" AVB
yet? I've been lurking, but mostly been very, very afraid :)



--
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: AVB

liebrecht
On 2018-12-22 15:40, Jörn Nettingsmeier wrote:

> On 12/8/18 2:37 PM, Christoph Kuhr wrote:
>> On the next LAC we want to present a IEEE1722 AVTP Mediaclock Backend.
>
> I would say that for now, if you need to speak AVB, the easiest path
> is to get a recent MOTU USB class-compliant device with an AVB port.
> That way, the Linux system only needs to concern itself with the USB
> audio part, and the routing in the MOTU connects you to the AVB world.
> Thankfully, after being quite useless for open-source for many many
> years, they've now made two good decisions:
> * USB class compliance, and
> * the masterstroke, i.e. implementing the mixer as a web server that
> can be accessed via any browser, thus relieving open-source developers
> of the tedious task of reverse-engineering a mixer that will then only
> work on one particular device.
>
> Christoph, would you agree, or can people who do not frequent the same
> circles of hell as you are so competently doing consider "native" AVB
> yet? I've been lurking, but mostly been very, very afraid :)

That is in fact the exact way I am going after long information
gathering.
Motu is the way to go, separate stage mixer with user config monitoring,
independent from web based <1ms web based mixer, and the USB compliant
io you can use to record with mixbus etc (arrives at your USB interface
on PC at about 1ms latency. I am getting a B16 stagemixer and the
AVB/USB interface. Pricey, but it solves about every problem I had and
then some.
I am selling off my Presonus and Steinberg gear. I really loved
Steinberg, but the outright disregard for Linux that in my opinion
exists at these companies makes it not palatable to own anymore.
Presonus hardware in my opinion are great, but it is severely limited
with little help when you ask to address the limitations which it was
advertised as differently.

Just wish there were a mixbus mixer in one of these stagemixers.

I have gone through all the options and Motu  it is the only one
standing. the responses I got from other manufacturers ranged from the
comical to outright ignorance of what users need.

I have a feeling that AVB/IEEE  will win over the ultranet stuff from
Sony that is now licvensed out to someone handling it. that looks like a
disaster to me. I am not going to invest in an interface that Sony the
inventor did not want to pursue, it means that the profit margin must be
about zero.

We have unfortunaltely a bit of VHS vs Betamax again with AVB vs
Ultranet, but I sure find AVB the better horse to bet on.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12