GitLab

Correct typos in JackNetTool.cpp

Account for IP+UDP header in MTU

alsa_in/out: Convert between sample rates when necessary

alsa_in and alsa_out set the playback latency of their ports to the target delay. The problem is the target delay is in terms of the ALSA sample rate, so it should be converted to JACK's sample rate.

Example: Imagine JACK is running at 48 kHz, and alsa_out is invoked like:

alsa_out -r 96000 -t 512
Currently, alsa_out will report 512 frames of playback latency. After the fix, it converts to 48kHz and correctly reports 256.

Also converts the result of jack_frames_since_cycle_start to ALSA sample rate.

Use linux futex as JackSynchro

Valgrind

Add autoclose option to jack_load

tests: define __STDC_LIMIT_MACROS

Fix crash in JackPosixSemaphore::Wait

Includes optimizations for internal clients, but not enabled yet.

This doesn't seem necessary since it is implmented below

Crash was observed in this function when fSemaphore was NULL, this patch
copies the NULL pointer check from the commented function above into
Wait()

Waf macosx fixes

ARM Neon support for non-dithering sample conversion functions

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>

Patch by Thomas Brand <tom@trellis.ch> and in accordance with jackd1
code base.

a leading 1 was missing [1]

[1] http://www.musicdsp.org/showone.php?id=59

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>

* detect version option before all other oprion parsing

jackd now checks its arguments for "-V" and "--version" before all other
option parsing happens.

* remove some dead code from option parsing

Version options are detected before optparse runs, the removed code
paths thus became obsolete.

* remove rest of version option from optparse

Detection of the version option is now handled outside of optparse, thus
left over stings and variables are removed.

* switch to string comparison for detection version option

Demanding an exact match for the option strings reflects the original
behavior more closely than a search for substrings.

Make backtrace support depend on execinfo.h's existence

corrected the message when transport is in an unexpected state while …

Toggle between run and stop state

wscript: improve check for ucontext

The ucontext functionality is not available on all CPUs with all C
libraries. Instead of making just assumptions based on the CPU
architecture, this commit adds the necessary checks in wscript to verify
the availability of the ucontext functionality, before using it in
dbus/sigsegv.c.

This avoids the long list of architecture exclusions, and make it more
robust when building jack2 for new CPU architectures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>

Don't pack structures on MIPS where unaligned access is not allowed

With glibc 2.16, we get following build error when building jack2:

  [193/247] cxx: tests/iodelay.cpp -> build/tests/iodelay.cpp.4.o
  ../tests/iodelay.cpp:171:43: error: 'UINT32_MAX' was not declared in this scope
  ../tests/iodelay.cpp:171:55: error: 'UINT32_MAX' was not declared in this scope
  ../tests/iodelay.cpp:172:44: error: 'UINT32_MAX' was not declared in this scope
  ../tests/iodelay.cpp:172:56: error: 'UINT32_MAX' was not declared in this scope

In glibc 2.17 or older version, Header <stdint.h> defines these macros
for C++ only if explicitly requested by defining __STDC_LIMIT_MACROS.

We can't use <cstdint> since it requires C++11 standard.

This build issue found by Buildroot autobuilder.
http://autobuild.buildroot.net/results/369/369ce208ffea43dad75ba0a13469159b341e3bf5/

Signed-off-by: Rahul Bedarkar <rahul.bedarkar@imgtec.com>

jack_latency_range_t is

struct _jack_latency_range {
    jack_nframes_t min;
    jack_nframes_t max;
};

and jack_nframes_t is

typedef uint32_t        jack_nframes_t;

so it's unsigned. Initialising it with -1 is invalid (at least in C++14). We cannot use {0, 0}, because latency_cb has

   jack_latency_range_t range;
   range.min = range.max = 0;
   if ((range.min != capture_latency.min) || (range.max !=
       capture_latency.max)) {
       capture_latency = range;
   }

so we must not have {0, 0}, otherwise the condition would never be true.

Using UINT32_MAX should be equivalent to the previous -1.

Space required before macro. No functional changes.

If configured with --clients=512 (translates to CLIENT_NUM), we exceed
the maximum stack size. CLIENT_NUM==500 still works, but let's allocate
the matrix on the heap to be safe.

Kudos to Markus Seeber for the initial bug triage.

Fixes #212

In some C-libraries (like uclibc), backtrace support is optional, so the
execinfo.h may not exist.

This change adds the check for execinfo.h header and conditionaly enable
backtrace support.

This issue has been triggered by Buildroot farms:
  http://autobuild.buildroot.org/results/391/391e71a988250ea66ec4dbee6f60fdce9eaf2766/build-end.log

Signed-off-by: Samuel Martin <s.martin49@gmail.com>

Reported by valgrind using the command below:
$ valgrind jackd -p128 -t2000 -dalsa -dhw:0 -r44100 -p2048 -n2 -S
==8930== Memcheck, a memory error detector
==8930== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==8930== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==8930== Command: jackd -p128 -t2000 -dalsa -dhw:0 -r44100 -p2048 -n2 -S
==8930==
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2016 Grame.
jackdmp 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 server starting in realtime mode with priority 10
self-connect-mode is "Don't restrict self connect requests"
creating alsa driver ... hw:0|hw:0|2048|2|44100|0|0|nomon|swmeter|-|16bit
configuring for 44100Hz, period = 2048 frames (46.4 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 2 periods for playback
==8930== Thread 4:
==8930== Syscall param write(buf) points to uninitialised byte(s)
==8930==    at 0x571388D: ??? (syscall-template.S:81)
==8930==    by 0x4EA70B3: Jack::JackClientSocket::Write(void*, int) (JackSocket.cpp:233)
==8930==    by 0x4E94C62: Jack::JackClientCheckResult::Write(Jack::detail::JackChannelTransactionInterface*) (JackRequest.h:227)
==8930==    by 0x4ECDF3A: Jack::JackRequestDecoder::HandleRequest(Jack::detail::JackChannelTransactionInterface*, int) (JackRequestDecoder.cpp:58)
==8930==    by 0x4ED4219: Jack::JackSocketServerChannel::Execute() (JackSocketServerChannel.cpp:247)
==8930==    by 0x4EA4B63: Jack::JackPosixThread::ThreadHandler(void*) (JackPosixThread.cpp:59)
==8930==    by 0x59F5181: start_thread (pthread_create.c:312)
==8930==    by 0x572247C: clone (clone.S:111)
==8930==  Address 0x41da85e is on thread 4's stack
==8930==  in frame #3, created by Jack::JackRequestDecoder::HandleRequest(Jack::detail::JackChannelTransactionInterface*, int) (JackRequestDecoder.cpp:46)
==8930==
==8930== Syscall param write(buf) points to uninitialised byte(s)
==8930==    at 0x571388D: ??? (syscall-template.S:81)
==8930==    by 0x4EA70B3: Jack::JackClientSocket::Write(void*, int) (JackSocket.cpp:233)
==8930==    by 0x4ED619B: Jack::JackClientNotification::Write(Jack::detail::JackChannelTransactionInterface*) (JackRequest.h:1606)
==8930==    by 0x4ED5F2E: Jack::JackSocketNotifyChannel::ClientNotify(int, char const*, int, int, char const*, int, int, int*) (JackSocketNotifyChannel.cpp:56)
==8930==    by 0x4EB51DF: Jack::JackExternalClient::ClientNotify(int, char const*, int, int, char const*, int, int) (JackExternalClient.cpp:40)
==8930==    by 0x4EAFA9A: Jack::JackEngine::ClientNotify(Jack::JackClientInterface*, int, char const*, int, int, char const*, int, int) (JackEngine.cpp:274)
==8930==    by 0x4EAFD34: Jack::JackEngine::NotifyAddClient(Jack::JackClientInterface*, char const*, int) (JackEngine.cpp:318)
==8930==    by 0x4EB0C99: Jack::JackEngine::ClientExternalOpen(char const*, int, int, int*, int*, int*, int*) (JackEngine.cpp:636)
==8930==    by 0x4ED4486: Jack::JackLockedEngine::ClientExternalOpen(char const*, int, int, int*, int*, int*, int*) (JackLockedEngine.h:123)
==8930==    by 0x4ED3AD5: Jack::JackSocketServerChannel::ClientAdd(Jack::detail::JackChannelTransactionInterface*, Jack::JackClientOpenRequest*, Jack::JackClientOpenResult*) (JackSocketServerChannel.cpp:132)
==8930==    by 0x4ECE0B8: Jack::JackRequestDecoder::HandleRequest(Jack::detail::JackChannelTransactionInterface*, int) (JackRequestDecoder.cpp:73)
==8930==    by 0x4ECDFBA: Jack::JackRequestDecoder::HandleRequest(Jack::detail::JackChannelTransactionInterface*, int) (JackRequestDecoder.cpp:63)
==8930==  Address 0x41d9ccb is on thread 4's stack
==8930==  in frame #3, created by Jack::JackSocketNotifyChannel::ClientNotify(int, char const*, int, int, char const*, int, int, int*) (JackSocketNotifyChannel.cpp:51)
==8930==
==8930== Syscall param write(buf) points to uninitialised byte(s)
==8930==    at 0x571388D: ??? (syscall-template.S:81)
==8930==    by 0x4EA70B3: Jack::JackClientSocket::Write(void*, int) (JackSocket.cpp:233)
==8930==    by 0x4ED633C: Jack::JackClientNotification::Write(Jack::detail::JackChannelTransactionInterface*) (JackRequest.h:1612)
==8930==    by 0x4ED5F2E: Jack::JackSocketNotifyChannel::ClientNotify(int, char const*, int, int, char const*, int, int, int*) (JackSocketNotifyChannel.cpp:56)
==8930==    by 0x4EB51DF: Jack::JackExternalClient::ClientNotify(int, char const*, int, int, char const*, int, int) (JackExternalClient.cpp:40)
==8930==    by 0x4EAFA9A: Jack::JackEngine::ClientNotify(Jack::JackClientInterface*, int, char const*, int, int, char const*, int, int) (JackEngine.cpp:274)
==8930==    by 0x4EAFD34: Jack::JackEngine::NotifyAddClient(Jack::JackClientInterface*, char const*, int) (JackEngine.cpp:318)
==8930==    by 0x4EB0C99: Jack::JackEngine::ClientExternalOpen(char const*, int, int, int*, int*, int*, int*) (JackEngine.cpp:636)
==8930==    by 0x4ED4486: Jack::JackLockedEngine::ClientExternalOpen(char const*, int, int, int*, int*, int*, int*) (JackLockedEngine.h:123)
==8930==    by 0x4ED3AD5: Jack::JackSocketServerChannel::ClientAdd(Jack::detail::JackChannelTransactionInterface*, Jack::JackClientOpenRequest*, Jack::JackClientOpenResult*) (JackSocketServerChannel.cpp:132)
==8930==    by 0x4ECE0B8: Jack::JackRequestDecoder::HandleRequest(Jack::detail::JackChannelTransactionInterface*, int) (JackRequestDecoder.cpp:73)
==8930==    by 0x4ECDFBA: Jack::JackRequestDecoder::HandleRequest(Jack::detail::JackChannelTransactionInterface*, int) (JackRequestDecoder.cpp:63)
==8930==  Address 0x41d9d1d is on thread 4's stack
==8930==  in frame #3, created by Jack::JackSocketNotifyChannel::ClientNotify(int, char const*, int, int, char const*, int, int, int*) (JackSocketNotifyChannel.cpp:51)
==8930==