Hello,
I've been playing around with Jack/Netjack and the Opus codec in order to
setup a "low latency" WiFi audio stream at home.
After compiling Opus with custom modes and Jack2 with Opus support (both
from the master branches of the respective repositories), I was able to run
the Master-Slave setup:
Master.
jackd -R -d alsa -d hw:1 -D=false -r44100 -S -n16
jack_load netmanager
Slave:
jackd -R -d net -C0 -P2 -o0 -i0 -O320 -M1200 -l5
+ jack_connect to route the net input on the master to the speakers
But as I was getting quite frequent audio deterioration, with the master
showing messages like these:
Packet(s) missing from... -1 1
Wrong packet type : a
JackEngine::XRun: client = SLAVE_HOSTNAME was not finished, state = Running
JackEngine::XRun: client netmanager finished after current callback
JackAudioDriver::ProcessGraphAsyncMaster: Process error
Wrong packet type : a
Packet(s) missing from... -1 1
JackAudioDriver::ProcessGraphAsyncMaster: Process error
JackEngine::XRun: client = SLAVE_HOSTNAME was not finished, state =
Triggered
I've thought that maybe I should just try increasing the network latency
argument on the slave, as, for my use case, I'm happy with latency < 200
ms.
By using something like -l30 (the maximum I'm allowed to set) on the slave
I was able to greatly diminish the Process errors (I still get the same
lots of wrong packet type and packet missing messages though) but it didn't
fix the audio artifacts. Actually sometimes this change makes the playback
even worse with ms pauses every second.
So I would like to know if there is any other way to relax the low latency
requirement in order to improve playback reliability. Or is there some kind
of incompatibility in the configuration I'm passing to both endpoints that
is causing these problems?
Thanks!
André.
Dear Leonardo,
Thank you for your reply. I've considered Jacktrip before, but is not an
option because it doesn't run on Windows (and I have one Windows laptop at
home). I didn't know nj-bridge at all. Where can I find more information
about it?
Thanks.
André.
On Thu, May 21, 2015 at 11:26 AM, Leonardo O. Gabrielli <
leonardo.o.gabrielli(a)gmail.com> wrote:
> Dear Andre,
> I have experience with several WiFi 802.11 setups but not with netjack,
> which IMHO is the least suitable solution. If u want still to go on that
> way I suggest to increase the period size, to allow the network to hand
> buffers in and out with shorter deadlines, I guess that should help.
>
> The other way is using jack clients such as jacktrip or nj-bridge. I
> employed those for networked performances over the internet or wireless and
> tolerate some jitter, just adjust the buffer size at the expense of latency
> (not a big deal in your use case). Nj-bridge may be more suitable to you as
> it instantiate mono directional flows.
>
> Best
> Leonardo
> http://a3lab.dii.univpm.it/research/wemust
>
Hi,
using jack 0.124.1 I happened to do this:
const char *connect_to="";
err=jack_connect(client,connect_to,myport);
and expected jack_connect to return an error. To my surprise it
succeeded and connected "system:capture_1" to myport.
Is this "normal" and/or documented?
AFAICT, the technical reason is
jack_port_shared_t::alias2="\0" (resp. alias1)
and jack_get_port_by_name() returns the first such one...
Tobias
workaround is something like (in transport.c)
+int proc(jack_nframes_t frames, void* arg) { return 0; }
int main(int argc, char *argv[])
{
+ jack_set_process_callback(client, proc, NULL); /* for jack1 */
P.
Dnia Poniedziałek, 18 Maja 2015 00:16 Pawel <xj(a)wp.pl> napisał(a)
> HI,
>
> Seems that jackd 0.124.1 require process callback for timebase callback.
>
> i.e. jack_transport no longer works. workaround:
>
> Best Regards
> P.
>
>
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel(a)lists.jackaudio.org
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
dear collected wisdom,
i have a tough problem to solve with jackd messing up my input sound. it’s a
reoccurring crackling on the input channel that sounds a bit like pulsewave ring
modulation. i figured out it’s highly dependent on my blocksize settings.
for example:
with -p1024 the distortion starts every 7th minute and lasts for 2min50sec.
with -p512 the distortion sounds slightly different (like with a higher ringmod
freq) and starts every 3min15sec and lasts for ~1min.
with -p256 it appears every 1min45sec and lasts for 40sec.
etc.
after much research i found this...
http://thread.gmane.org/gmane.comp.audio.jackit/28114/focus=28115
and this…
http://music.columbia.edu/pipermail/linux-audio-user/2005-August/025787.html
that i believe describe the same issue.
as suggested in those posts resetting the jack_bufsize makes the distortion go
away. but only temporarily - it always comes back after exactly the same time!
for now i can let my system reset the buffer after a known time interval, but
that’s a really ugly hack and i’d be happy for suggestions on how to solve this.
below are details of my system. i compile jack2 from master and it’s all
running under debian wheezy on a beaglebone black. i use supercollider 3.7 and
a terratec aureon dual usb soundcard.
i’ve also tried with another usb soundcard (C-MEDIA) but then the crackle occurs
on the output instead (and also after longer intervals). so same issue but
sounds worse.
thank you,
_f
BeagleBoard.org Debian Image 2015-03-01
Linux asdf 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux
gcc and g++ version 4.7.2
~$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
~$ lsusb
Bus 001 Device 004: ID 0ccd:0077 TerraTec Electronic GmbH Aureon Dual USB
~/jack2$ ./waf configure --alsa
Setting top to : /home/debian/jack2
Setting out to : /home/debian/jack2/build
Checking for 'g++' (C++ compiler) : /usr/bin/g++
Checking for 'gcc' (C compiler) : /usr/bin/gcc
Linux detected
Checking for program 'doxygen' : not found
Checking for program 'pkg-config' : /usr/bin/pkg-config
Checking for 'alsa' >= 1.0.18 : yes
Checking for 'libffado' >= 1.999.17 : not found
Checking for 'libfreebob' >= 1.0.0 : not found
Checking for 'gtkIOStream' >= 1.4.0 : not found
Checking for 'eigen3' >= 3.1.2 : not found
Checking for header windows.h : not found
Checking for 'portaudio-2.0' >= 19 : not found
Checking for header mmsystem.h : no
Checking for 'celt' >= 0.11.0 : not found
Checking for 'celt' >= 0.8.0 : not found
Checking for 'celt' >= 0.7.0 : not found
Checking for 'celt' >= 0.5.0 : not found
Checking for header opus/opus_custom.h : not found
Checking for 'opus' >= 0.9.0 : not found
Checking for 'samplerate' >= 0 : yes
Checking for 'sndfile' >= 0 : yes
Checking for library readline : yes
Checking for header readline/readline.h : yes
==================
JACK 1.9.11 svn revision will checked and eventually updated during build
Build with a maximum of 64 JACK clients
Build with a maximum of 768 ports per application
Install prefix : /usr/local
Library directory : /usr/local/lib
Drivers directory : /usr/local/lib/jack
Build debuggable binaries : no
C compiler flags : ['-Wall']
C++ compiler flags : ['-Wall']
Linker flags : []
Build with engine profiling : no
Build with 32/64 bits mixed mode : no
Build standard JACK (jackd) : yes
Build D-Bus JACK (jackdbus) : no
Autostart method : classic
Build doxygen documentation : no
Enable ALSA driver : yes
Enable FireWire driver (FFADO) : no
Enable FreeBob driver : no
Enable IIO driver : no
Enable Portaudio driver : no
Enable WinMME driver : no
Build with CELT : no
Build Opus netjack2 : no
Build with libsamplerate : yes
Build with libsndfile : yes
Build with readline : yes
~$ tail /etc/security/limits.conf
@audio - memlock 256000
@audio - rtprio 75
~$ sudo jackd -P75 -dalsa -dhw:1,0 -p256 -n3 -r44100 -s &
jackdmp 1.9.11
JACK server starting in realtime mode with priority 75
self-connect-mode is "Don't restrict self connect requests"
creating alsa driver ...
hw:1,0|hw:1,0|256|3|44100|0|0|nomon|swmeter|soft-mode|32bit
configuring for 44100Hz, period = 256 frames (5.8 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 3 periods for playback
Hi there,
Not sure if this is really a JACK question, but I'll ask it to find out.
I have a problem with an older piece of audio hardware (an M-Audio Projectmix) and a Windows 8 PC. The Windows 7 drivers partially work - ASIO works OK, but I can't get the normal Windows audio output to address the Projectmix properly. Applications will attempt playback, but nothing appears on the M-Audio software metering and no sound is heard. There aren't likely to be any further driver updates for this hardware.
One solution that occurs is to use a piece of software to create a virtual audio device that Windows could address successfully, and pipe the results to the ASIO driver.
Is that something JACK could do?
Thanks,
Phil
Branch: refs/heads/master
Home: https://github.com/jackaudio/jack1
Commit: 4492cea02fb46305632d19796460b91fd319ec96
https://github.com/jackaudio/jack1/commit/4492cea02fb46305632d19796460b91fd…
Author: Hanspeter Portner <dev(a)open-music-kontrollers.ch>
Date: 2015-05-04 (Mon, 04 May 2015)
Changed paths:
M drivers/alsa_midi/a2j.h
M drivers/alsa_midi/alsa_midi.c
M drivers/alsa_midi/port_thread.c
M drivers/alsa_midi/port_thread.h
Log Message:
-----------
[alsa_midi] fix hotplug device (de)enumeration
Issues:
- With a running JACK with enabled alsa_midi driver (-X alsa_midi), plugging in
a new MIDI device has no effect, e.g. no corresponding JACK ports are spawned
- With a running JACK with enabled alsa_midi driver (-X alsa_midi), deplugging
a MIDI device has no effect, e.g. the corresponding JACK ports stay around
Result:
- JACK only creates JACK ports of ALSA MIDI clients/ports found at startup
- JACK has to be restarted for any ALSA MIDI device (de)enumeration to take
place
Problem:
- There are some functions defined which actually should accomplish this in the
alsa_midi driver code (e.g. 'a2j_update_ports' and 'a2j_free_ports'), but they
are not called from any other function ;-)
Solution:
- Discriminate properly between ALSA PORT_START and PORT_CHANGE events
- 'a2j_new_ports' function has been added which recycles some code from
'alsa_input_thread'
- Actually call the already existing hot(de)plugging infrastructure
- 'a2j_update_ports' and 'a2j_new_ports' get called from the
'alsa_input_thread'
- 'a2j_free_ports' gets called from 'alsa_output_thread'
- 'alsa_out_thread' is woken up by 'a2j_jack_process_internal'
- Cleanup code that is not used:
- 'port_add' ringbuffer has no function, as 'new_ports' ringbuffer seems to be
implemented to accomplish the same
Signed-off-by: Hanspeter Portner <dev(a)open-music-kontrollers.ch>
Commit: 6685cc737eec2937f0fb9d3088be2efee95a910e
https://github.com/jackaudio/jack1/commit/6685cc737eec2937f0fb9d3088be2efee…
Author: Paul Davis <paul(a)linuxaudiosystems.com>
Date: 2015-05-04 (Mon, 04 May 2015)
Changed paths:
M drivers/alsa_midi/a2j.h
M drivers/alsa_midi/alsa_midi.c
M drivers/alsa_midi/port_thread.c
M drivers/alsa_midi/port_thread.h
Log Message:
-----------
Merge branch 'ventosus-fix_alsa_midi_hotplug'
Compare: https://github.com/jackaudio/jack1/compare/fb78f60db1db...6685cc737eec