On Mon, 24 Feb 2014, David J Myers wrote:
> I need to take the audio input from my sound hardware on one Linux box,
> send it over the network to a second Linux box and play it back on the
> second box sound hardware.
> Can this be done using jackd and jack_netsource without modification? If
> not, can it be done with a simple Jack applet of my own? If not, how can
> I implement this quickly without writing my own streaming server and
> client?
Without wanting to hijack the thread (your subject is NetJack but your
question more general), I had a similar use case and this could be useful
to you:
http://www.pogo.org.uk/~mark/trx/
Thanks
--
Mark
On Mon, Feb 24, 2014 at 10:38 AM, David J Myers <
david.myers(a)amg-panogenics.com> wrote:
>
> user@ubuntu:~$ jackd -d net
> jackd 0.121.2
>
JACK 1 is now at 0.124.1 ... upgrading is recommended. You are using a
version that is heading towards 4 years old.
On Mon, Feb 24, 2014 at 11:58:21AM -0000, David J Myers wrote:
> I need to take the audio input from my sound hardware on one Linux box, send
> it over the network to a second Linux box and play it back on the second box
> sound hardware.
Yes. Using the latest jackd1 release will make this easier, however,
you can also go for whatever your distribution has available.
Basically, you run
$ jackd -d alsa
on the first box and
$ jackd -d net
on the second. If you have jackd2, it would be "netone", not "net".
You then use Fons' zita-ajbridge on the second machine to connect to
your physical I/O. (they replace the older alsa_in/out tools)
The latest jackd1 can do the last two steps in one step.
Maybe netjack2 is also an option for you. Go for whatever works.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
Hi there,
I'm trying to find out whether I can use NetJack1 to do the following:-
I need to take the audio input from my sound hardware on one Linux box, send
it over the network to a second Linux box and play it back on the second box
sound hardware.
Can this be done using jackd and jack_netsource without modification? If
not, can it be done with a simple Jack applet of my own? If not, how can I
implement this quickly without writing my own streaming server and client?
Many thanks for your time.
DavidJ
On Fri, Feb 21, 2014 at 03:29:40PM -0500, Paul Davis wrote:
> On Fri, Feb 21, 2014 at 3:27 PM, Lieven Moors <lievenmoors(a)gmail.com> wrote:
>
> > Aren't most clients checking for
> > the sample rate in the process callback anyway?
>
>
> if they are, then they are doing it wrong.
That would be me ;-)
I probably did this because I thought it could change at period
boundaries. Could you explain why it is wrong?
This is an exceptional announcement.
You may ask why announce a FVWM-Crystal release on the LAA,
fvwm-crystal being a desktop. That's simple, fvwm-crystal was improved
in 3.3.0 with a key modifier editor which let you change its key
modifiers.
This will affect only the extensive set of fvwm-crystal own
key-bindings, and the key bindings of other applications will remain
fully unaffected. That's a very easy and fast way to have the extensive
key-bindings set of applications like ardour or emacs to not collide
with the desktop.
During the last 2 years, a lot of bug fixes was done, the existing
features was improved and unified between the recipes, and new features
was added. The list of changes is so huge that it is better to try it
for yourself, if you don't already have done it. During the last few
months, a particular effort was made to fix some nasty bashisms. That
should make fvwm-crystal to work much better with distributions using
dash as default shell, and fix one hopefully unnoticed security issue.
A short and very partial story of the last releases:
3.3.2 bring 2 new recipes with ACPI support (battery, cpu speed and
temperature).
3.3.1 bring a new and complete Dutch translation and a Preference
Editor for the preferences that don't have menu options.
It bring too a pot file for easy translations in new languages.
3.2.6 see an updated Russian translation and x-terminal-emulator
support (Debian).
3.2.4 add mount/umount/pmount/pmount-gui support with the built-in
desktop icons.
3.2.1 finally succeed to remove the restart with all preference
changes but one.
3.2 see a complete rewrite of the Thunar desktop icons manager. Not
only the buttons was redone from the scratch into a single button,
which fix the flickering, but also a new implementation of the
associated actions was done. Now it's possible to associate any file
manager you can think about with these icons, 2 are supported at the
same time, as well than custom commands.
...
For a complete list, see the ChangeLog file.
Download:
https://sourceforge.net/projects/fvwm-crystal/files/?source=navbar
Website:
http://fvwm-crystal.sourceforge.net/
Project site:
https://sourceforge.net/projects/fvwm-crystal/?source=navbar
Enjoy,
Dominique
Hi all,
Let's say I have a client that introduces an amount of latency that's
variable at runtime and potentially unbounded. From JACK's docs it
seems that you need to recompute the min/max latencies in the latency
callback that's called "by the server" whenever it feels like, but you
can force that by calling jack_recompute_total_latencies (right?).
The problem is, you are advised to call this last function only after
calling jack_port_set_latency_range(), which you should only call in
the latency callback, which may be called next month... am I dumb
(probably) or is there a deadly loop?
I couldn't find code handling dynamic latencies around and I'm way too
lazy to try to understand JACK internals or to make silly tests etc.
(also because they would tell nothing since we have multiple
implementations of the same JACK API).
Stefano
Hi,
For those of you who are interested real world results for ffmpeg with
opencl we have run some benchmarking tests across our cluster. At the end
of last year there was a flurry of activity integrating opencl with
ffmpeg. The work was undertaken by multicorewareinc who is also the
official keeper of the code for AMD's proprietary version of ffmpeg.
We have found that leveraging opencl with the latest development version
of ffmpeg gives us upto 4566 DP-MFLOP on a single machine.
Adding in the OpenCL component (GPUs) gives us around a 64% speed boost on
AMD A4's. We got upto 400% increase on our intel machines (with alot of
NVidia CUDA cores).
We also noticed that essentially the same AMD/ATI card on a different bus
(AGP-8 versus PCI-E) only picked up an extra 6% in speed.
So clearly the recent work on the opencl integration with ffmpeg has
provided some real world dividends.
Just for the record our local cluster is clocking in around 20GFlops with
the opencl code in the mix. We haven't added in the cloud servers though
so that number is low.
While we are not a not a threat to the big players, combining resources
within the wider open source community creates a very serious competitor
that shouldn't be ignored.
Cheers
--
Patrick Shirkey
Boost Hardware Ltd
