24 Oct
2014
24 Oct
'14
10:46 a.m.
Hello,
I have a situation in mind : in a LAN a central computer running jack server with a lot of
audio I/O, and lightweight clients with stereo I/O.
I'd like those clients to be able to send a receive 2 channels of audio to the central
jack server, lowest latency possible.
With the zita-njbridge and jack server running on the lightweight clients, it works, but
considering i don't need the jack server on the lightweight clients (no effect
plugins, no routing, no synths...) could a zita-nabridge exist to capture/override the
streams from the client's embedded alsa device ?
Raphaël
http://www.jerashmusic.fr
24 Oct
24 Oct
8:58 p.m.
On Fri, Oct 24, 2014 at 10:46:28AM +0200, raf wrote:
I have a situation in mind : in a LAN a central
computer running jack server with a lot of audio I/O, and lightweight clients with stereo
I/O.
I'd like those clients to be able to send a receive 2 channels of audio to the
central jack server, lowest latency possible.
With the zita-njbridge and jack server running on the lightweight clients, it works, but
considering i don't need the jack server on the lightweight clients (no effect
plugins, no routing, no synths...) could a zita-nabridge exist to capture/override the
streams from the client's embedded alsa device ?
In theory such a thing could exist, it would be an ALSA device
that receives and/or sends audio using the njbridge protocol.
No resampling would be needed as it would be the 'master'
device on the local system.
In practice that is not very likely to happen, the reason
being that interfacing to Jack is so much more easy than
writing an ALSA driver. Also, passing via Jack does not
add any latency, and in most cases users will want the
flexibility it provides.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
9:10 p.m.
I have a
situation in mind : in a LAN a central computer running jack server with a lot of audio
I/O, and lightweight clients with stereo I/O.
I'd like those clients to be able to send a receive 2 channels of audio to the
central jack server, lowest latency possible.
With the zita-njbridge and jack server running on the lightweight clients, it works, but
considering i don't need the jack server on the lightweight clients (no effect
plugins, no routing, no synths...) could a zita-nabridge exist to capture/override the
streams from the client's embedded alsa device ?
In theory such a thing could exist, it would be an ALSA device
that receives and/or sends audio using the njbridge protocol.
No resampling would be needed as it would be the 'master'
device on the local system.
In practice that is not very likely to happen, the reason
being that interfacing to Jack is so much more easy than
writing an ALSA driver. Also, passing via Jack does not
add any latency, and in most cases users will want the
flexibility it provides. 
25 Oct
25 Oct
5:34 p.m.
2014-10-24 21:10 GMT+02:00 raf <rmouneyres(a)gmail.com>om>:
I've thought about a similar idea sometime in the past: A distributed audio
network with thin clients/raspberrys for a home studio or distributed via
some network. I'd be interested in following whatever progress you make.
About that of "distributed band" I red a little about programs to jam via
internet: Netjack, Ninjam, Midikit.
--
C. sanchiavedraZ:
* NEW / NUEVO: www.sanchiavedraZ.com
* Musix GNU+Linux: www.musix.es
> I have a situation in mind : in a LAN a
central computer running jack
server with a lot of audio I/O, and lightweight
clients with stereo I/O.
> I'd like those clients to be able to send
a receive 2 channels of audio
to the central jack server, lowest latency possible.
>
> With the zita-njbridge and jack server running on the lightweight
clients, it
works, but considering i don't need the jack server on the
lightweight clients (no effect plugins, no routing, no synths...) could a
zita-nabridge exist to capture/override the streams from the client's
embedded alsa device ?
In theory such a thing could exist, it would be an ALSA device
that receives and/or sends audio using the njbridge protocol.
No resampling would be needed as it would be the 'master'
device on the local system.
In practice that is not very likely to happen, the reason
being that interfacing to Jack is so much more easy than
writing an ALSA driver. Also, passing via Jack does not
add any latency, and in most cases users will want the
flexibility it provides.
thanks for the answer, I was expecting this, but hadn't measures the
difference between the jack client and alsa driver.
So now it looks like I need to learn how to cross compile jack for various
ARM devices to have it on the lightweight clients :/
Raphaël
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
11:07 p.m.
The boards of main concern are two arcom viper boards with a PXA255
processor running a 2.4 kernel. They are upgradable to 2.6 but I have not
worked on it yet.
The arcom provided alsa driver is working without effort with the onboard
chipset.
Le 25 oct. 2014 21:23, "Jeremy Jongepier" <jeremy(a)autostatic.com> a écrit
:
On 10/24/2014 09:10 PM, raf wrote:
So now it looks like I need to learn how to cross
compile jack for
various ARM devices to have it on the lightweight clients :/
What kind of ARM devices are you using and what is running on them?
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3686
days inactive
3687
days old
linux-audio-user@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Carlos sanchiavedraz -
Fons Adriaensen -
Jeremy Jongepier -
raf -
Raphaël Mouneyres