[Apologies for cross-postings] [Please distribute]
*Save the date: Linux Audio Conference 2018*
The 2018 Linux Audio Conference will take place at
*c-base, Berlin*
*7th -11th June 2018*
The LAC 2018 will feature a full program of talks, workshops and music.
Theofficial call for papers and works will be sent shortly after the
winter break -
so use the quiet of the holidays to think about possible submissions.
All relevant information will be made availableon:
http://lac.linuxaudio.org/2018/
All the best,
the LAC 2018 Organizing Team
--
Henrik von Coler
Elektronisches Studio, Fachgebiet Audiokommunikation
Electronic Music Studio, Audio Communication Group
Technische Universität Berlin
Fakultät I Geistes- und Bildungswissenschaften
Institut für Sprache und Kommunikation
Faculty I Humanities
Institute of Speech and Communication
Einsteinufer 17c, Sekr. EN 8, 10587 Berlin
Germany
Tel: +49 (0)30 314 22327
Fax: +49 (0)30 314 21143
voncoler(a)tu-berlin.de
www.ak.tu-berlin.de
Hello there, I was using Jack until last month. Tried to start it today
and nothing. Any ad vice would be appreciated. Tx. JoeF.
15:45:55.995 Statistics reset.
15:45:56.038 ALSA connection change.
15:45:56.260 D-BUS: Service is available (org.jackaudio.service aka
jackdbus).
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
4294967295, skipping unlock
15:45:56.346 ALSA connection graph change.
15:45:59.493 D-BUS: JACK server could not be started. Sorry
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
4294967295, skipping unlock
Thu Dec 21 15:45:59 2017: Starting jack server...
Thu Dec 21 15:45:59 2017: JACK server starting in realtime mode with
priority 10
Thu Dec 21 15:45:59 2017: self-connect-mode is "Don't restrict self
connect requests"
Thu Dec 21 15:45:59 2017: ERROR: Cannot lock down 82274202 byte memory
area (Cannot allocate memory)
Thu Dec 21 15:45:59 2017: Acquired audio card Audio0
Thu Dec 21 15:45:59 2017: creating alsa driver ...
hw:0|hw:0|1024|3|44100|0|0|nomon|swmeter|-|32bit
Thu Dec 21 15:45:59 2017: ERROR:
ATTENTION: The playback device "hw:0" is already in use. Please stop the
application using it and run JACK again
Thu Dec 21 15:45:59 2017: ERROR: Cannot initialize driver
Thu Dec 21 15:45:59 2017: ERROR: JackServer::Open failed with -1
Thu Dec 21 15:45:59 2017: ERROR: Failed to open server
Thu Dec 21 15:46:00 2017: Saving settings to
"/home/lulujoe13/.config/jack/conf.xml" ...
15:46:08.819 Could not connect to JACK server as client. - Overall
operation failed. - Unable to connect to server. Please check the
messages window for more info.
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
4294967295, skipping unlock
A few days ago a new version of JACK2 was released.
You can grab the latest release source code at
https://github.com/jackaudio/jack2/releases.
The official changelog is:
- Fix Windows build issues
- Fix build with gcc 7
- Show hint when DBus device reservation fails
- Add support for internal session files
If you did not know already, I am now maintaining JACK2 (and also JACK1).
So this latest release was brought to you by yours truly. ;)
The release was actually already tagged on the git repo quite some time
ago, but I was waiting to see if Windows builds were possible.
I got side-tracked with other things and 1.9.12 ended up not being
released for some time, until someone reminded me of it again... :)
There are still no updated macOS or Windows builds, but I did not want
to delay the release further because of it.
The 1.9.11 release (without RC label) was skipped to avoid confusion
with the versions.
So 1.9.12 is the latest release as of today. macOS and Windows binaries
still use an older 1.9.11 version.
Being the maintainer of both JACK1 and JACK2 means I can (more or less)
decide the future of JACK.
I believe a lot of people are interested to know the current plan.
First, JACK1 is in bug-fix mode only.
I want to keep it as the go-to reference implementation of JACK, but not
add any new features to it.
The reason for this is to try to get JACK1 and JACK2 to share as much
code as possible.
Currently JACK2 includes its own copy of JACK headers, examples and
utilities, while JACK1 uses sub-repositories.
During the course of next year (that is, 2018) I want to get JACK2 to
slowly use the same stuff JACK1 does, then switch to use the same
repositories as submodules like JACK1 does.
This will reduce the differences between the 2 implementations, and make
it a lot easier to contribute to the examples and utilities provided by
JACK.
(Not to mention the confusion caused by having utilities that work in
simlar yet different ways)
We will keep JACK1 "frozen" until this is all done.
Second, but not least important, is to get the JACK1 specific features
into JACK2.
A few things were added into JACK1 after JACk2 was created, that never
made it into JACK2.
This includes meta-data (JACK2 does have the API, but a non-functional
one) and the new internal clients.
The purpose is to reduce reasons users might have to switch/decide
between JACK1 and JACK2.
JACK2 should have all features that JACK1 has, so that most users choose
JACK2.
Now, you are probably getting the impression that the focus will be on
JACK2, which is correct.
Though I realize some developers might prefer JACK1's design, the long
"battle" of JACK1 and JACK2 needs to stop.
Development of new features will happen in the JACK2 codebase, and JACK1
will slowly become legacy.
Well, this is my personal plan at least.
Not sure if this all can be done in 2018, but better to take things
slowly and get things done than do nothing at all.
I will keep you updated on the progress through-out the year.
Happy holidays everyone!
Hi!
I came across several locations in the Jack source code which look like
copy&paste style bugs (see attached diff). Maybe someone familiar with the
code can review these?
Thanks & kind regards,
Markus
Hi!
I have some questions about the minimum and maximum values of a port's latency
(i.e., its latency range). The documentation states the following:
"Both latencies might potentially have more than one value because there may
be multiple pathways to/from a given port and a terminal port."
Does this also apply to a setup with two output ports "A" and "B"
(representing two distinct physical devices) with different capture latency,
which are both connected to the same input port "C"?
Here are some details of an example setup (useful for demonstration purposes,
but probably not for doing any real recording work) as reported by jack_lsp:
"A" (Focusrite Saffire PRO 14 Firewire audio interface):
firewire_pcm:00130e0402403491_1394/Out:01 (Mic/Lin/Inst:01)_in
port latency = 337 frames
port playback latency = [ 0 1792 ] frames
port capture latency = [ 337 337 ] frames
properties: output,physical,terminal,
"B" (Line6 PODxt Live guitar effects processor synchronized by zita-ajbridge):
line6_in:capture_1
port latency = 867 frames
port playback latency = [ 1792 1792 ] frames
port capture latency = [ 867 867 ] frames
properties: output,physical,terminal,
"C" (Ardour track):
ardour:track 1/audio_in 1
port latency = 0 frames
port playback latency = [ 1792 1792 ] frames
port capture latency = [ 867 867 ] frames
properties: input,
Under the assumption that the physical inputs of "A" and "B" represent the
same time scale, the correct answer for the port capture latency at port "C"
would be [ 337 867 ] and not [ 867 867 ].
So my questions are:
*) What is the rationale behind jack reporting the larger of the two latencies
of "A" and "B" both as the minimum and maximum latency of "C", and ignoring
the smaller one?
*) Is it possible to provide additional information to jack to state that the
signals at "A" and "B" originate from the same physical source (or from
different physical sources sharing the same time scale), such that both
latencies of "A" and "B" are taken into account for the latency range of "C"?
Thanks & kind regards,
Markus
Hello
I am working on a Java program special for visual impaired persons
that needs to detect weather the headphone jack plugs on Windows-7.
can Jack detect it?
Jack can notify headphone plugging by a call back method?
I will be appreciate, if you would how to do that via Jack, if possible.
Shadyar Khodayari
On Mon, October 23, 2017 11:53 am, Philippe Bekaert wrote:
> wireshark reveals that dante is using ptp v1 - it's not that
> non-standard.
Correct, I have not looked up the Audinate patent(s) yet, I do not know
what was unique enough to award a patent. In any case ALC Networx did not
seem to think that the Ravenna approach of using PTPv2 (IEEE 1588-2008)
for synchronization and RTP/RTCP (IEEE 1733-2011 and IETF RFC3550 and
RFC3650) for media streams would be covered by any patents.
> Especially rtp is not difficult : it's just one packet format, and we
> need none of the special features, essentially just the time stamp
> in the header and the audio data.
Yes, time stamp calculations and latency adjustments seemed like the only
part that would possibly be a little tricky. The rest seems like just
manipulating sample values to get into the correct order in the packet.
Jack uses floating point for sample format and RTP uses integers, so the
usual conversion between integer and floating point that you would do for
sending samples to a hardware sound card applies.
> I'm sticking with linux in the first place, but using platform
> independent tools whereever available.
> Hence also my consideration of the asio C++11 library for networking
> support.
OK, the first time I misread that as an ASIO library, i.e. the Steinberg
designed Windows specific multi-channel audio specification, not asio C++
library for asynchronous I/O.
I checked my fedora installation and that is easily available as the
asio-devel package. I think libasio-dev is the equivalent in debian.
Seems that should not be a problem for any recent distribution.
Actually, now that I look at the details that seems to be just headers,
I'm not sure where the actual libraries are implemented. Something to
investigate later.
> I'm considering to have a user set up system time synchronisation
> with the audio network clock master and use system time as
> reference indeed, as you also proposed.
One thing I do not know is what the clock will be set to using one of the
standalone audio devices as the PTP master. I'm not sure if those devices
have a battery backed clock, so potentially if you set your system clock
to the PTP clock in a network which only contains a Ravenna device for
example, your system clock could jump to some unexpected value,
potentially far in the past. Just something to consider for documentation
purposes for the moment, hopefully I will find a way to get access to some
hardware for testing.
> It won't work if you have different audio devices synchronised with
> different master clocks
That is always the case, whether using network audio, USB, or AES/EBU or
S/PDIF connections, so again I think just a note for the documentation.
Typically any devices which are on the same network segment or VLAN will
end up using the same master clock because of the PTP best master clock
algorithm so in practical installations should not be a problem. I think
you would have to specifically change the default clock domain from clock
0 to some other value to have that problem.
A second level of consideration is that two devices which are using the
same master clock could still be configured to use different sample rates,
so those two devices could still not be used together as a single
aggregate audio device. That could be manually checked at the beginning,
but eventually should be part of whatever configuration method exists,
compatibility of stream parameters should be verified before those streams
are allowed to be configured together as part of the aggregate device.
--
Chris Caudle
On Mon, October 23, 2017 4:32 am, Philippe Bekaert wrote:
> ALC Networx and audinate (several times) concerning patent issues
My limited understanding is that the original Dante protocol is or was
covered by a patent regarding the non-standard clocking method they used,
but Ravenna specifically uses only IEEE and IETF specifications which
should be not covered by any current patents, with the exception of
features which should be part of the hardware (e.g. if the Ethernet
adapter vendor is licensing a patent for some hardware feature we should
not need to care). I have not heard of any patents asserted against IEEE
1588-2008, and protocols like RTP and RTCP have been implemented for many
years by browsers and media players, so I think there should be no patents
there.
> many choices for the implementation of each of the required components
> (full implementation generic libraries, or ad hoc pieces of open source
My preference would be re-use anything available, days are too short to
re-implement software which is already working. That presumes that a
library for what is needed is well maintained, and that the function is
not so simple that understanding how to use the library is not more work
than just implementing for the jack driver.
One thing that will influence what libraries you may choose to use is
whether you want to make the software cross platform or linux only. My
thinking there is that there are virtual sound card implementations for
Windows and Mac OS already, so jack on Windows and Mac OS can use the
existing sound system interface.
If you implement as linux only, you could potentially take certain
shortcuts such as requiring that the user install linuxptp and synchronize
the system clock to the audio PTP domain first. That way you could use
the system clock as the clock for scheduling the net driver.
> Right now, I'm using the free merging AES67 sound card driver on a
> macbook pro to generate AES67 streams, and later also to receive.
I do not have a Mac, so I did not even think of that. That is a good
choice, essentially the equivalent of the free Lawo R3lay driver I was
testing on Windows. The only disadvantage I can see is the driver is
limited in what buffer sizes and sample rates it supports, so you can only
test a subset of what is possible to support, but definitely should allow
getting all the basic work completed with just software implementations on
each end.
> I'm running ptp4l (hardware timestamping support, on a server) or ptpd
> (if you don't have hw ts - on my laptop)
I believe ptp4l should also support software timestamp.
I can run ptp4l on my workstation to synchronize to my BeagleBone ptp
master, and ethtool reports that there is no PTP hardware clock available:
Time stamping parameters for enp3s4f0:
Capabilities:
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
PTP Hardware Clock: none
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv1-l4-event (HWTSTAMP_FILTER_PTP_V1_L4_EVENT)
ptpv2-l4-event (HWTSTAMP_FILTER_PTP_V2_L4_EVENT)
ptpv2-l2-event (HWTSTAMP_FILTER_PTP_V2_L2_EVENT)
I am continuing to copy the jack-devel mail list for now, hopefully there
are some others who will be interested in participating, if not eventually
we can take this to a private distribution until something is ready for
wider testing.
--
Chris Caudle
