21 Mar
2005
21 Mar
'05
12:49 a.m.
jack.udp for me means many underrun in this configuration:
x86 pc
jackd -d alsa -d hw:0
jack.udp recv
^
| (FastEthernet network (100mbps))
|
|
powerpc pc
jackd -d dummy
jack.udp -r IP send
the first thing that came in my mind was some network troubles like
mtu.. further investigation (like involving two x86 hosts, or working
directly without the switch, working with 802.11b networks...) made me
think that jack.udp uses the audiocard driver for some kind of timing.
now, i've some troubles running an audiocard with jack in the powerpc
(my main computer) there is a way to make this system usable with dummy
driver? i've noticed that this dummy driver has a "delay in microsecs"
parameter, now i think if i can calculate the right number the problem
will fade away, but i dont know how to do the math :(
some one has an idea on this? or has solved a similar trouble?
another question out of this trouble: someone knows how to raise the IRQ
priority of the USB controller to an usable value? possibly not
involving the use of the realtime patch, inusable on ppc-powermac,
thanks for attention and eventual replies, and keep the good work on
this audio software :)
willy
21 Mar
21 Mar
3:48 p.m.
Hi Antonio,
On Monday 21 Mar 2005 05:48, Antonio "Willy" Malara wrote:
jack.udp for me means many underrun in this
configuration:
x86 pc
jackd -d alsa -d hw:0
jack.udp recv
^
| (FastEthernet network (100mbps))
powerpc pc
jackd -d dummy
jack.udp -r IP send
the first thing that came in my mind was some network troubles like
mtu.. further investigation (like involving two x86 hosts, or working
directly without the switch, working with 802.11b networks...) made me
think that jack.udp uses the audiocard driver for some kind of timing.
now, i've some troubles running an audiocard with jack in the powerpc
(my main computer) there is a way to make this system usable with dummy
driver? i've noticed that this dummy driver has a "delay in microsecs"
parameter, now i think if i can calculate the right number the problem
will fade away, but i dont know how to do the math :(
some one has an idea on this? or has solved a similar trouble?
I have no real answers but as I've been thinking about using jack.udp (in
exactly this setup) in a while I realize I'm up for the same problems.
I think Jack uses the sound card as timing source and that is the pipe that
all other apps have to dance to.
With two different computers with two different jack instances, both operating
with this precondition, I can't see how it can possibly work... Is anyone
successfully using two jack instances like this?
One use case I've been thinking about myself is offloading for example
linuxsampler and brutefir (or the other IR reverb wosname) to a second
computer. In case of the reverb I'd like to send data both ways.
Would it be possible to change something in jack to allow one of the instances
to "slave" from the other?
Interesting stuff, thanks for the heads up!
Regards,
Robert
another question out of this trouble: someone knows how to raise the IRQ
priority of the USB controller to an usable value? possibly not
involving the use of the realtime patch, inusable on ppc-powermac,
thanks for attention and eventual replies, and keep the good work on
this audio software :)
willy
--
http://spamatica.se/musicsite/
10:35 p.m.
On Mon, 2005-03-21 at 05:48 +0100, Antonio "Willy" Malara wrote:
jack.udp recv
^
| (FastEthernet network (100mbps))
|
|
powerpc pc
When you say "FastEthernet network" do you mean a good network or do you
mean cheap switches?
When I was an ISP sysadmin we went through several different ethernet
phone systems, a Nortel something and then the new Cisco stuff. Someone
had the bright idea to save a few bucks by using a Netgear or Linksys
switch for the internal network rather than Cisco Catalysts like we used
for the carrier grade production network.
Terrible idea. We never could get the phones to work right until we got
a real switch.
Of course home users can't afford to just buy a Cisco, but it's still a
problem people should look out for. When in doubt test it with a
crossover cable. For these purposes a crossover cable is not one you
made yourself.
Lee
22 Mar
22 Mar
2:43 a.m.
On Mon, 2005-03-21 at 21:35 -0500, Lee Revell wrote:
On Mon, 2005-03-21 at 05:48 +0100, Antonio
"Willy" Malara wrote:
> jack.udp recv
> ^
> | (FastEthernet network (100mbps))
> |
> |
> powerpc pc
[...]
Of course home users can't afford to just buy a
Cisco, but it's still a
problem people should look out for. When in doubt test it with a
crossover cable. For these purposes a crossover cable is not one you
made yourself.
If the PowerPC is a recent Apple, it will autodetect the kind of cable
and switch internal wirings. A cheap PCI card I bought a year ago will
do the same.
--
(
)
c[] // Jens M Andreasen
7 a.m.
Lee Revell wrote:
On Mon, 2005-03-21 at 05:48 +0100, Antonio
"Willy" Malara wrote:
the switch is a Catalyst which i dont remember the mode, it has 48 FE
plus two optic fiber, the two hosts are on the same subnet so no routing
is required, btw i've tried without any switch and the issue is still there
for the records i've been able to set up a working (but i've not
stressed it) configuration like this
jackudp recv (the same x86 computer) with alsa driver
^
|
| (cable, 100mbps)
|
router: powerpc laptop (the same)
|
| (802.11b ad-hoc network)
|
jackudp send (a sony vaio of a couple of years ago) with alsa driver
with this i started alsaplayer on the vaio and the other x86 host was
correctly playing music with no xruns due to network transport or, btw,
no artifacts on the audio
that was only a 3 minute test, just the time of the song i've listened
:P dont know if in this short time can occour an audible clock drift or
anything like that,
so it seems jack needs some timing information from the soundcard/driver
subsystem. i wonder if that can be abstracted at jack level (nor at
driver level)
wil
---
jack.udp recv
^
| (FastEthernet network (100mbps))
|
|
powerpc pc
When you say "FastEthernet network" do you mean a good network or do you
mean cheap switches? 
8:10 a.m.
On Tue, 22 Mar 2005 12:00:04 +0100, Antonio Willy Malara
<behappy(a)maialone.com> wrote:
with this i started alsaplayer on the vaio and the
other x86 host was
correctly playing music with no xruns due to network transport or, btw,
no artifacts on the audio
that was only a 3 minute test, just the time of the song i've listened
:P dont know if in this short time can occour an audible clock drift or
anything like that,
Shouldn't it be possible to do on the fly samplerate-conversion to
make up for the timing differences?
Propably some timestamps need to be introduced to the network protocol?
Alternatively the needed adjustments could be calculated by the rate
on which packets arrive.
-Richard
7:05 a.m.
Lee Revell wrote:
Of course home users can't afford to just buy a
Cisco, but it's still a
problem people should look out for.
i think that i'm on one of the few person that live in a house where the
network is fully cisco driven :D
my housemate is a cisco-addict :P so we got a 3600 for the domestic
640adsl and two catalyst in trunking running only for four clients, and
one AP (always down) and the "DMZ server" (an xbox) :) (ofcourse all 2nd
hand hardware)
wil
---
6984
days inactive
6986
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Antonio "Willy" Malara -
Jens M Andreasen -
Lee Revell -
Richard Spindler -
Robert Jonsson