29 Dec
2012
29 Dec
'12
12:43 p.m.
Hi all,
Having recently acquired a second Delta 1010 for my setup I've been trying
to run the two in tandem using the alsa Multi hack. I'm getting the xruns
that I understand are expected but harmless[1] but I'm also getting some
audible ones, which are obviously more of a problem. They're synched via the
S/PDIF link and running either card on its own seems pretty solid.
I've seen on various mailing lists people talking about digging into this
but not found any conclusions. Is anyone here running dual Delta 1010s
who can double check I'm running the latest recommended settings?
I'm on a dual core 2.3GHz Athlon (4450e), running linux 3.2.0-2-rt with
cpu scaling disabled, and the cards have exclusive use of IRQs 17 and 18.
Jack is running at 44.1KHz with 6 frames and 64 periods, audio IRQs at
rtprio 85 and Jack at rtprio 82.
bjb
[1] http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
29 Dec
29 Dec
7:23 p.m.
On Sat, December 29, 2012 3:43 am, Ben Bell wrote:
Hi all,
Having recently acquired a second Delta 1010 for my setup I've been trying
to run the two in tandem using the alsa Multi hack. I'm getting the xruns
that I understand are expected but harmless[1] but I'm also getting some
audible ones, which are obviously more of a problem. They're synched via
the
S/PDIF link and running either card on its own seems pretty solid.
I've seen on various mailing lists people talking about digging into this
but not found any conclusions. Is anyone here running dual Delta 1010s
who can double check I'm running the latest recommended settings?
I'm on a dual core 2.3GHz Athlon (4450e), running linux 3.2.0-2-rt with
cpu scaling disabled, and the cards have exclusive use of IRQs 17 and 18.
Jack is running at 44.1KHz with 6 frames and 64 periods, audio IRQs at
rtprio 85 and Jack at rtprio 82.
bjb
[1] http://www.jrigg.co.uk/linuxaudio/ice1712multi.html
This page you mentioned lists RT kernels as a possible problem and
suggests using a kernel without the RT patch, but with preempt (a
lowlatency kernel) as the best way to go. I also suspect the latency may
need to be a bit higher with two cards, but I have not tested that.
Remember that John Rigg's setup has/had a hard wired clock setup (he seems
to have removed the link that shows it). He installed high quality clocks
in the PC case and wired them in place of the D1010 PCI board clock. So
all three of his D1010s were hard synced without using wordclock or
s/pdif. (he also used off board voltage regulation... in anycase his was
not an "out of the box" setup)
As with all Jackd projects, you need to analyze your latency needs for the
part of the project you are working on. For example, I use a low latency
for tracking (jackd started with -p64 on my old P4) and try to track
without effects and mute tracks I don't need to hear to do a track. Then I
increase the latency for mixdown and add whatever effects I want/need to
make it sound right. Some musicians need some effects to get the feel for
what they are playing, so each project is different.
In your case, I would recommend a higher latency if recording a live
performance (where you need lots of inputs) with all monitoring done
before the signal gets to the D1010 inputs. This would also be true if
recording "live in the studio". I would use only one D1010 for doing
single tracks with the lower latency (I find I rarely need more than two
tracks at a time, but I have no drums to record). That is, only use the
two D1010s synced when you need it and accept their limitations. The idea
of one setup works for everything leads to frustration ... at least with
what I have to work with.
--
Len Ovens
www.OvenWerks.net
11:31 p.m.
On Sat, Dec 29, 2012 at 10:23:46AM -0800, Len Ovens wrote:
This page you mentioned lists RT kernels as a possible
problem and
suggests using a kernel without the RT patch, but with preempt (a
Yes, I tried that
to no avail.
As with all Jackd projects, you need to analyze your
latency needs for the
part of the project you are working on. For example, I use a low latency
for tracking (jackd started with -p64 on my old P4) and try to track
I've tried
running all the way up to -p 1024 -n 4 with no appreciable
difference. I can't go higher than that -- jack won't start.
bjb
7:29 p.m.
On Saturday 29 December 2012 06:43:49 Ben Bell wrote:
Hi all,
Having recently acquired a second Delta 1010 for my setup I've been trying
to run the two in tandem using the alsa Multi hack. I'm getting the xruns
that I understand are expected but harmless[1] but I'm also getting some
audible ones, which are obviously more of a problem. They're synched via
the S/PDIF link and running either card on its own seems pretty solid.
I've seen on various mailing lists people talking about digging into this
but not found any conclusions. Is anyone here running dual Delta 1010s
who can double check I'm running the latest recommended settings?
I'm on a dual core 2.3GHz Athlon (4450e), running linux 3.2.0-2-rt with
cpu scaling disabled, and the cards have exclusive use of IRQs 17 and 18.
Jack is running at 44.1KHz with 6 frames and 64 periods, audio IRQs at
rtprio 85 and Jack at rtprio 82.
Suggesting from ignorance here.
Have you tried using one via jack and the other one via an alsa<->jack bridge
and then sync the two via the wordclock?
I actually have two but the first died before the second got here so I have
never been able to try out more than one at once.
bjb
all the best,
drew
11:35 p.m.
On Sat, Dec 29, 2012 at 01:28:47PM -0500, drew Roberts wrote:
Have you tried using one via jack and the other one
via an alsa<->jack bridge
and then sync the two via the wordclock?
No, that might be worth a go actually. Not
ideal, but if it works then it
might be a solution. I suppose I should also try sync via wordclock rather
than S/PDIF on the offchance it works better.
30 Dec
30 Dec
3:22 p.m.
Actually, I've just spotted that this topic has been raised again on the
jack mailing list so perhaps this would be better followed up over there.
http://comments.gmane.org/gmane.comp.audio.jackit/26610
That said:
On Sat, Dec 29, 2012 at 01:28:47PM -0500, drew Roberts wrote:
OK, well I've tried this morning and the news on this is mixed. Sitting idle,
and clocked from S/PDIF everything works fine with alsa_in.
Running with my large ardour session which is, frankly, on the limits of
what this machine will cope with results in loads of clicks during playback.
I suppose the graph is just too big at that point.
Running with a more modest session hovering at 30% normally, pulling the
alsa_in channels (just into jack -- no connections) raises the CPU to ~55%
but there are no xruns.
So it seems that the problem is most likely in the alsa multi plugin. As an
aside I'm surprised at the extent of resource usage caused by simply having
alsa_in running. Normal, or suspicious? jack_netsource doesn't cause this
sort of load, and tweaking sample rate and the like doesn't seem to affect
things. A side-effect of it expecting to need to resample everything?
bjb
Having
recently acquired a second Delta 1010 for my setup I've been trying
to run the two in tandem using the alsa Multi hack. I'm getting the xruns
Have
you tried using one via jack and the other one via an alsa<->jack bridge
and then sync the two via the wordclock? 
3:46 p.m.
On Sun, Dec 30, 2012 at 02:22:51PM +0000, Ben Bell wrote:
Running with a more modest session hovering at 30%
normally, pulling the
alsa_in channels (just into jack -- no connections) raises the CPU to ~55%
but there are no xruns.
So it seems that the problem is most likely in the alsa multi plugin. As an
aside I'm surprised at the extent of resource usage caused by simply having
alsa_in running. Normal, or suspicious? jack_netsource doesn't cause this
sort of load, and tweaking sample rate and the like doesn't seem to affect
things. A side-effect of it expecting to need to resample everything?
You could try zita-a2j instead of alsa-in. On my old 2G P4 machine
adding 8 channels that way takes 10% CPU. Sound quality is vastly
better than alsa-in.
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)
4:52 p.m.
On Sun, Dec 30, 2012 at 9:46 AM, Fons Adriaensen <fons(a)linuxaudio.org>wrote;wrote:
On Sun, Dec 30, 2012 at 02:22:51PM +0000, Ben Bell
wrote:
it seems as if it may be wise to "replace" alsa_(in|out) with zita-a2j.
what do you think?
Running with a more modest session hovering at
30% normally, pulling the
alsa_in channels (just into jack -- no connections) raises the CPU to
~55%
but there are no xruns.
So it seems that the problem is most likely in the alsa multi plugin. As
an
aside I'm surprised at the extent of resource
usage caused by simply
having
alsa_in running. Normal, or suspicious?
jack_netsource doesn't cause this
sort of load, and tweaking sample rate and the like doesn't seem to
affect
things. A side-effect of it expecting to need to
resample everything?
You could try zita-a2j instead of alsa-in. On my old 2G P4 machine
adding 8 channels that way takes 10% CPU. Sound quality is vastly
better than alsa-in.
5:26 p.m.
On Sun, Dec 30, 2012 at 10:52:03AM -0500, Paul Davis wrote:
On Sun, Dec 30, 2012 at 9:46 AM, Fons Adriaensen
<fons(a)linuxaudio.org>wrote;wrote:
It would be an improvement. But note that they are written in C++,
and depend on two libraries (zita-resampler, zita-alsa-pcmi) which
are also C++. I'm _not_ going to support a C rewrite of all of that
(or any modified versions).
Network versions (i.e. jacktrip but with resampling) will be added,
supporting both LAN (multicast) and WAN (TCP) operation.
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)
You could try zita-a2j instead of alsa-in. On my
old 2G P4 machine
adding 8 channels that way takes 10% CPU. Sound quality is vastly
better than alsa-in.
it seems as if it may be wise to "replace" alsa_(in|out) with zita-a2j.
what do you think?
8:27 p.m.
On Sun, Dec 30, 2012 at 02:46:11PM +0000, Fons Adriaensen wrote:
You could try zita-a2j instead of alsa-in. On my old
2G P4 machine
adding 8 channels that way takes 10% CPU. Sound quality is vastly
better than alsa-in.
It's a vast improvement in terms of CPU usage. About 6% cpu vs about 24%.
Thanks!
31 Dec
31 Dec
12:33 a.m.
On Sun, Dec 30, 2012 at 07:27:11PM +0000, Ben Bell wrote:
On Sun, Dec 30, 2012 at 02:46:11PM +0000, Fons
Adriaensen wrote:
I *could* add a no-resample option, to be used only if the cards
have the same sample clock... Would probably reduce CPU use to
less than 1%.
But normally in that case you don't need a2j or j2a, the
ALSA layer should be able to handle it by merging the two
cards, and without any added latency as not only the sample
clocks but also the periods would be synchronized.
I've no idea why this fails as you mentioned in the
message that started this thread.
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)
You could try zita-a2j instead of alsa-in. On my
old 2G P4 machine
adding 8 channels that way takes 10% CPU. Sound quality is vastly
better than alsa-in.
It's a vast improvement in terms of CPU usage. About 6% cpu vs about 24%. 
12:50 a.m.
On Sun, Dec 30, 2012 at 3:33 PM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
On Sun, Dec 30, 2012 at 07:27:11PM +0000, Ben Bell
wrote:
We were discussing this on the JACK mailing list for a while, and I
eventually brought this up with the ALSA developers, but the
discussion didn't really go anywhere.
The (not-working) solution in ALSA is to use a 'multi' device. The
problem is that the multi device returns poll descriptors for only one
device, and makes the assumption that when a period of data is
available on one device, there is a period of data available on the
other synced devices as well. Unfortunately, in practice, this isn't
the case. While snd_pcm_link() links the start, stop, drain, pause,
suspend, resume, reset, and prepare operations, it doesn't make the
readiness of the master device's poll descriptor depend on the
readiness of the poll descriptors of the slave devices.
So, you get a situation where poll() returns because there's data on
the master device, but then the 'multi' device indicates there's no
data because it checks all of the devices and returns the minimum
value for the amount of data available, which JACK thinks is an xrun
because the ALSA driver's wait function returns 0 when anything less
than a period's worth of data is available, and a 0 result is
interpreted as an xrun. This results in tons and tons of xruns, as
JACK essentially busy waits until there is actually a period of data
available on all of the devices that make up the multi device.
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
On Sun, Dec 30, 2012 at 02:46:11PM +0000, Fons
Adriaensen wrote:
I *could* add a no-resample option, to be used only if the cards
have the same sample clock... Would probably reduce CPU use to
less than 1%.
But normally in that case you don't need a2j or j2a, the
ALSA layer should be able to handle it by merging the two
cards, and without any added latency as not only the sample
clocks but also the periods would be synchronized.
I've no idea why this fails as you mentioned in the
message that started this thread. You could try zita-a2j instead of alsa-in. On my
old 2G P4 machine
adding 8 channels that way takes 10% CPU. Sound quality is vastly
better than alsa-in.
It's a vast improvement in terms of CPU usage. About 6% cpu vs about 24%.
2:50 a.m.
On Sun, December 30, 2012 3:50 pm, Devin Anderson wrote:
We were discussing this on the JACK mailing list for a
while, and I
eventually brought this up with the ALSA developers, but the
discussion didn't really go anywhere.
The (not-working) solution in ALSA is to use a 'multi' device. The
problem is that the multi device returns poll descriptors for only one
device, and makes the assumption that when a period of data is
available on one device, there is a period of data available on the
other synced devices as well. Unfortunately, in practice, this isn't
the case. While snd_pcm_link() links the start, stop, drain, pause,
suspend, resume, reset, and prepare operations, it doesn't make the
readiness of the master device's poll descriptor depend on the
readiness of the poll descriptors of the slave devices.
Is there any guarantee that the master device would still be ready long
enough to wait for the slave to be ready? I would think that if they are
both "started" at the same time (but if jackd only deals with the master
maybe they don't "start at the same time) there would be less than a
sample period between readiness of master and slave. If they don't then
the master could over fill (overrun) waiting for the slave to fill the
buffer. I don't know how well the hardware deals with things like this.
Having Jack deal with two devices in sync would be better. In fact jack
could have a lower load to deal with if the buffer readiness was
interleaved on purpose by Jack setting the second device half a buffer
length after the first. (just guessing there are probably reasons why I am
wrong)
When jack sets the device up (sends sample rate and buffer size) doesn't
the multi device have to send that info to both devices? Wouldn't that
start both at the same time? Making the difference between readiness
within a sample? (I ask because I don't know) When the master restarts, is
there any indication sent to the slave via s/pdif?
So, you get a situation where poll() returns because there's data on
the master device, but then the 'multi' device indicates there's no
data because it checks all of the devices and returns the minimum
value for the amount of data available, which JACK thinks is an xrun
because the ALSA driver's wait function returns 0 when anything less
than a period's worth of data is available, and a 0 result is
interpreted as an xrun. This results in tons and tons of xruns, as
JACK essentially busy waits until there is actually a period of data
available on all of the devices that make up the multi device.
Thank you for the best explanation I have heard/read so far. I am glad I
don't have to resort to this at this time. I have yet to use all 6 inputs
of my D66 at once.
As a side note for anyone else with one of these devices, jack spends just
as much CPU on this device as the 1010 because the ice1712 shows all 12
inputs and 10 outputs if they are used or not. I wonder if I was to make a
fake device with fewer ports if that would make any difference. (8 in 4
out is all I can use)
--
Len Ovens
www.OvenWerks.net
3:03 a.m.
On Sun, Dec 30, 2012 at 8:50 PM, Len Ovens <len(a)ovenwerks.net> wrote:
so they can be off by 1 sample (for example) and this can happen. ALSA
needs to wait for the slowest/last of the linked devices, not the first. or
so it appears.
ck sets the device up (sends sample rate and buffer
size) doesn't
the multi device have to send that info to both devices? Wouldn't that
start both at the same time? Making the difference between readiness
within a sample? (I ask because I don't know) When the master restarts, is
there any indication sent to the slave via s/pdif?
s/pdif won't carry that information.
when i studied the ALSA code for this years ago, it looked to me as though
even on a late 1990's CPU, you could still expect both devices to start
*within* 1 sample of each other.
the problem as it been described here, seems more to be:
So, you get a situation where poll() returns because there's data on
the master device, but then the 'multi' device indicates there's no
data because it checks all of the devices and returns the minimum
value for the amount of data available, which JACK thinks is an xrun
because the ALSA driver's wait function returns 0 when anything less
than a period's worth of data is available, and a 0 result is
interpreted as an xrun. This results in tons and tons of xruns, as
JACK essentially busy waits until there is actually a period of data
available on all of the devices that make up the multi device.
3:39 a.m.
On Sun, Dec 30, 2012 at 6:03 PM, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
the problem as it been described here, seems more to
be:
Right.
Doing this in the multi device at the *userspace* level, AFAICT, is
either very hard or not possible due to the way poll descriptors are
handled within ALSA. With the multi's implementation of
snd_pcm_poll_descriptors(), there are basically three choices:
1.) Return the master device's poll descriptors (the current implementation).
We know this doesn't work.
2.) Return the poll descriptors of all of the devices (the old
implementation, IIUC).
This would lead to the same issue, and possibly make it worse if the
slave devices are sometimes ready before the master device.
3.) Return a custom file descriptor (eventfd, maybe). Do the device
polling in separate thread, and signal the file descriptor when enough
data is available on both devices.
I'm not even sure this is really doable in a way that could reliably
play well with all the applications that depend on this functionality.
I can't see any other way to do this at the userspace level.
At the kernel level, this problem might be able to be fixed by having
snd_pcm_link() sync the file descriptors of the master and slave
devices. I have absolutely no idea what the ramifications would be.
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
>
> So, you get a situation where poll() returns because there's data on
> the master device, but then the 'multi' device indicates there's no
> data because it checks all of the devices and returns the minimum
> value for the amount of data available, which JACK thinks is an xrun
> because the ALSA driver's wait function returns 0 when anything less
> than a period's worth of data is available, and a 0 result is
> interpreted as an xrun. This results in tons and tons of xruns, as
> JACK essentially busy waits until there is actually a period of data
> available on all of the devices that make up the multi device.
so they can be off by 1 sample (for example) and this can happen. ALSA needs
to wait for the slowest/last of the linked devices, not the first. or so it
appears.
10:24 a.m.
On Sun, Dec 30, 2012 at 06:39:57PM -0800, Devin Anderson wrote:
1.) Return the master device's poll descriptors
(the current implementation).
We know this doesn't work.
2.) Return the poll descriptors of all of the devices (the old
implementation, IIUC).
Why was this changed ?
This would lead to the same issue, and possibly make
it worse if the
slave devices are sometimes ready before the master device.
That depends. In that case snd_pcm_poll_descriptors_revents()
can be expected to combine the events in the correct way, e.g.
only return a POLLOUT if all playback devices are ready. I guess
this is how things worked before the change.
Since this should happen within at most a few samples of the first
device being ready, things would work. Even if the device periods
are not exactly synced the only consequence would be that the
available processing time per period would be a few samples shorter.
AFAIK, Jack's ALSA backend uses snd_pcm_poll_descriptors_revents(),
as does zita-alsa-pcmi. The two wait() functions are very similar
but differ in some details, so it could be a good idea to test
zita-alsa-pcmi with a multi device.
You could use the alsa_loopback app that comes with the library.
Just add some debug options in alsa_loopback.cc, line 55:
D = new Alsa_pcmi (playdev, captdev, 0, fsamp, frsize, nfrags,
Alsa_pcmi::DEBUG_STAT | Alsa_pcmi::DEBUG_WAIT);
to see what's happening.
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)
4:12 a.m.
On Sun, Dec 30, 2012 at 5:50 PM, Len Ovens <len(a)ovenwerks.net> wrote:
IIUC, snd_pcm_link() links the start, stop, drain, pause, suspend,
resume, reset, and prepare operations of two devices. However, I'm
not sure this means that the interrupts for the two devices are going
to be in sync.
You're very welcome. :)
--
Devin Anderson
surfacepatterns (at) gmail (dot) com
blog - http://surfacepatterns.blogspot.com/
midisnoop - http://midisnoop.googlecode.com/
psinsights - http://psinsights.googlecode.com/
synthclone - http://synthclone.googlecode.com/
The
(not-working) solution in ALSA is to use a 'multi' device. The
problem is that the multi device returns poll descriptors for only one
device, and makes the assumption that when a period of data is
available on one device, there is a period of data available on the
other synced devices as well. Unfortunately, in practice, this isn't
the case. While snd_pcm_link() links the start, stop, drain, pause,
suspend, resume, reset, and prepare operations, it doesn't make the
readiness of the master device's poll descriptor depend on the
readiness of the poll descriptors of the slave devices.
Is there any guarantee that the master device would still be ready long
enough to wait for the slave to be ready? I would think that if they are
both "started" at the same time (but if jackd only deals with the master
maybe they don't "start at the same time) there would be less than a
sample period between readiness of master and slave. If they don't then
the master could over fill (overrun) waiting for the slave to fill the
buffer. I don't know how well the hardware deals with things like this.
Having Jack deal with two devices in sync would be better. In fact jack
could have a lower load to deal with if the buffer readiness was
interleaved on purpose by Jack setting the second device half a buffer
length after the first. (just guessing there are probably reasons why I am
wrong)
JACK *could* deal with this issue, but:
1.) It would be better if the functionality was independent of JACK.
2.) I don't think the issue is JACK's responsibility.
So, you get a
situation where poll() returns because there's data on
the master device, but then the 'multi' device indicates there's no
data because it checks all of the devices and returns the minimum
value for the amount of data available, which JACK thinks is an xrun
because the ALSA driver's wait function returns 0 when anything less
than a period's worth of data is available, and a 0 result is
interpreted as an xrun. This results in tons and tons of xruns, as
JACK essentially busy waits until there is actually a period of data
available on all of the devices that make up the multi device.
Thank you for the best explanation I have heard/read so far. I am glad I
don't have to resort to this at this time. I have yet to use all 6 inputs
of my D66 at once.
3:47 p.m.
On Sun, December 30, 2012 7:12 pm, Devin Anderson wrote:
JACK *could* deal with this issue, but:
1.) It would be better if the functionality was independent of JACK.
2.) I don't think the issue is JACK's responsibility.
Quite honestly, it does not seem to be something that _should_ be done by
ALSA either, because properly joining two devices would mean an extra
buffer (and latency). It seems that the reality is that each device needs
to be dealt with as a separate device. So if it is not Jack's problem then
a second jacklike server that exposes the ports as jack clients is needed
and expected. So using something like zita-a2j would be the "correct" way
of doing things. It certainly seems more stable. I enabled my (junk AC97)
internal sound card (16 bit in and 18 bit out) just for fun and ran jack
on it. Then used the zita-bridge tools to add an ensoniq (normally used as
a midi port)... at a lower latency than jack would run that card alone. I
ran it overnight and yes there are some xruns, but then the internal card
is sharing irqs so 75 xruns in 6 hours at -p 32 on this machine is very
good, even without the bridging.
--
Len Ovens
www.OvenWerks.net
3:58 p.m.
On Mon, Dec 31, 2012 at 9:47 AM, Len Ovens <len(a)ovenwerks.net> wrote:
On Sun, December 30, 2012 7:12 pm, Devin Anderson wrote:
this is not true, if they are clock-synced.
JACK *could* deal with this issue, but:
1.) It would be better if the functionality was independent of JACK.
2.) I don't think the issue is JACK's responsibility.
Quite honestly, it does not seem to be something that _should_ be done by
ALSA either, because properly joining two devices would mean an extra
buffer (and latency). It seems that the reality is that each device needs
to be dealt with as a separate device. So if it is not Jack's problem then
a second jacklike server that exposes the ports as jack clients is needed
and expected. So using something like zita-a2j would be the "correct" way
of doing things.
if they are not clock synced, then yes.
11:32 p.m.
On Mon, December 31, 2012 6:58 am, Paul Davis wrote:
It seems if they are not phase synced then yes...
--
Len Ovens
www.OvenWerks.net
On Mon, Dec 31, 2012 at 9:47 AM, Len Ovens
<len(a)ovenwerks.net> wrote:
Well there is sync and sync. It seems the cards are in "sync" in that they
are exactly the same frequency, but not in "sync" phase wise in the
transfer of data. That is why there is a problem. Even though the cards
are "clock-synced" they are not in sync and Jack does not know how to deal
with that... In fact it can't know how because it is seeing one interface
where there is actually two out of sync cards that are clock-synced.
On Sun, December 30, 2012 7:12 pm, Devin Anderson wrote:
this is not true, if they are clock-synced.
JACK *could* deal with this issue, but:
1.) It would be better if the functionality was independent of JACK.
2.) I don't think the issue is JACK's responsibility.
Quite honestly, it does not seem to be something that _should_ be done
by
ALSA either, because properly joining two devices would mean an extra
buffer (and latency). It seems that the reality is that each device
needs
to be dealt with as a separate device. So if it is not Jack's problem
then
a second jacklike server that exposes the ports as jack clients is
needed
and expected. So using something like zita-a2j would be the "correct"
way
of doing things.
if they are not clock synced, then yes.
1 Jan
1 Jan
5:05 a.m.
On Mon, Dec 31, 2012 at 5:32 PM, Len Ovens <len(a)ovenwerks.net> wrote:
On Mon, December 31, 2012 6:58 am, Paul Davis wrote:
"startup" of linked PCM devices should take less than a handful of
milliseconds. if it doesn't then i suggest that its a driver-specific
issue, not an ALSA one. the internal driver design has this in mind. if
they are <<1 sample "out of phase" it should not make any difference *if*
ALSA waits for the last/slowest device.
On Mon, Dec 31, 2012 at 9:47 AM, Len Ovens
<len(a)ovenwerks.net> wrote:
Well there is sync and sync. It seems the cards are in "sync" in that they
are exactly the same frequency, but not in "sync" phase wise in the
transfer of data.
On Sun, December 30, 2012 7:12 pm, Devin Anderson wrote:
this is not true, if they are clock-synced.
JACK *could* deal with this issue, but:
1.) It would be better if the functionality was independent of JACK.
2.) I don't think the issue is JACK's responsibility.
Quite honestly, it does not seem to be something that _should_ be done
by
ALSA either, because properly joining two devices would mean an extra
buffer (and latency).
3 Jan
3 Jan
12:35 a.m.
On Sun, December 30, 2012 7:12 pm, Devin Anderson wrote:
IIUC, snd_pcm_link() links the start, stop, drain,
pause, suspend,
resume, reset, and prepare operations of two devices. However, I'm
not sure this means that the interrupts for the two devices are going
to be in sync.
After some thought, I am thinking this may be the issue, at least with
delta series IFs. They use phase locked loops for both word clock and
S/pdif. From some of the comments I have heard/read these are medium
quality devices and "in sync" may mean some wandering on the slave device
(voltage regulation is poor and heats the card for example). This could
mean that the interrupt timing on the slave could move from preceding the
master to lagging at the phase lock hunt rate. I don't know if the same
problems are there with higher quality equipment... John, with his RME
cards does not seem to be having the same trouble, but then those cards
are wired together inside the case and may be "hard clocked" together with
no phase lock loop.
So the delta series sync (or lack there of) may be a hardware issue rather
than software. The zita-a2j solution makes sense in this case though it
may still work using a resample bypass mode as well.
I think that depending on the two cards in question, the lock may be
acceptable with some card pairings and not with others depending on if the
errors add or subtract just right.
I may just need a bigger shovel too :)
--
Len Ovens
www.OvenWerks.net
1:05 a.m.
On Wed, Jan 02, 2013 at 03:35:17PM -0800, Len Ovens wrote:
After some thought, I am thinking this may be the
issue, at least with
delta series IFs. They use phase locked loops for both word clock and
S/pdif. From some of the comments I have heard/read these are medium
quality devices and "in sync" may mean some wandering on the slave device
(voltage regulation is poor and heats the card for example). This could
mean that the interrupt timing on the slave could move from preceding the
master to lagging at the phase lock hunt rate.
Rather improbable. If the PLL on the SPDIF wouldn't work OK, you
wouldn't be able to input SPDIF in the first place. It takes more
than sample accuracy to clock and read the bits correctly.
Imagine that the counter and logic that define a period already start
running on the card when ALSA sets the HW parameters (i.e. before the
start command). And then, instead of resetting that logic and starting
a period exactly when the start command is given, the card simply enables
the interrupt to the PC. There will be a random delay between the start
command and the actual start of the first period.
For a single card things would just work. But it would be impossible
to sync two of them properly.
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)
4:15 a.m.
On Wed, January 2, 2013 4:05 pm, Fons Adriaensen wrote:
On Wed, Jan 02, 2013 at 03:35:17PM -0800, Len Ovens
wrote:
Right, That should have been obvious. Bit rate is much higher than sample
rate.
After some thought, I am thinking this may be the
issue, at least with
delta series IFs. They use phase locked loops for both word clock and
S/pdif. From some of the comments I have heard/read these are medium
quality devices and "in sync" may mean some wandering on the slave
device
(voltage regulation is poor and heats the card for example). This could
mean that the interrupt timing on the slave could move from preceding
the
master to lagging at the phase lock hunt rate.
Rather improbable. If the PLL on the SPDIF wouldn't work OK, you
wouldn't be able to input SPDIF in the first place. It takes more
than sample accuracy to clock and read the bits correctly.
Imagine that the counter and logic that define a period already start
running on the card when ALSA sets the HW parameters (i.e. before the
start command). And then, instead of resetting that logic and starting
a period exactly when the start command is given, the card simply enables
the interrupt to the PC. There will be a random delay between the start
command and the actual start of the first period.
For a single card things would just work. But it would be impossible
to sync two of them properly.
I would think in that case no two of them would work...Well maybe.
Assuming that the cabling is done with power off, they should be pretty
close on power up... though it is probably easy to poke holes in that too.
The device is designed to sync with a second one, I wonder how they make
it work in windows.
--
Len Ovens
www.OvenWerks.net
6:04 a.m.
On Wed, 2 Jan 2013 19:15:05 -0800, Len Ovens wrote:
On Wed, January 2, 2013 4:05 pm, Fons Adriaensen
wrote:
It must work well enough for external converters synchronised by
word clock, where, it would seem to me, the problems are much worse
because of all the different designs and temperature variations.
I'm new to all this, but I kind of expect those devices to be
synchronisable. So I don't understand why there seems to be extra
difficulty doing so with ~identical cards. Does the quality of the
CPU clock have any bearing at all?
(I made a pretty good ntp server by running a Soekris 4501 with a
clock derived from GPS some time ago. PC clocks aren't (weren't)
particularly good: http://www.febo.com/pages/soekris/index.html)
I noticed, while fitting the 9652s, there are two quite large crystals
on board, which may say something about the clock quality.
--
John.
On Wed, Jan 02, 2013 at 03:35:17PM -0800, Len
Ovens wrote:
Imagine that the counter and logic that define a period already start
running on the card when ALSA sets the HW parameters (i.e. before the
start command). And then, instead of resetting that logic and starting
a period exactly when the start command is given, the card simply enables
the interrupt to the PC. There will be a random delay between the start
command and the actual start of the first period.
For a single card things would just work. But it would be impossible
to sync two of them properly.
I would think in that case no two of them would work...Well maybe.
Assuming that the cabling is done with power off, they should be pretty
close on power up... though it is probably easy to poke holes in that too.
The device is designed to sync with a second one, I wonder how they make
it work in windows. 
1:26 a.m.
On Wed, 2 Jan 2013 15:35:17 -0800
"Len Ovens" <len(a)ovenwerks.net> wrote:
So the delta series sync (or lack there of) may be a
hardware issue rather
than software. The solution makes sense in this case though it
may still work using a resample bypass mode as well.
I've been following this with interest, as I have two Delta 1010s, and I've
shared what I know at http://delta.brainiac.com/deltasync.html It's really
not much more than a rehash of John Rigg's work and my own experience with
it. I'm really interested in how zita-a2j will work for me - time to dive
in!
I think that depending on the two cards in question,
the lock may be
acceptable with some card pairings and not with others depending on if the
errors add or subtract just right.
I don't often need more than 8 channels in, but when I have and run the
aggregate device, I've had no issues. If there's a slip of a clock
cycle anywhere, it's not evident in any of the test (or actual)
recordings I've done. Maybe I've been lucky, but the S/PDIF lock has
always worked for me.
--
======================================================================
Joe Hartley - UNIX/network Consultant - jh(a)brainiac.com
Without deviation from the norm, "progress" is not possible. - FZappa
30 Dec
30 Dec
5:55 p.m.
On Sun, December 30, 2012 6:22 am, Ben Bell wrote:
On Sat, Dec 29, 2012 at 01:28:47PM -0500, drew Roberts
wrote:
OK, well I've tried this morning and the news on this is mixed. Sitting
idle,
and clocked from S/PDIF everything works fine with alsa_in.
Running with a more modest session hovering at 30% normally, pulling the
alsa_in channels (just into jack -- no connections) raises the CPU to ~55%
but there are no xruns.
So it seems that the problem is most likely in the alsa multi plugin. As
an
aside I'm surprised at the extent of resource usage caused by simply
having
alsa_in running. Normal, or suspicious? jack_netsource doesn't cause this
sort of load, and tweaking sample rate and the like doesn't seem to affect
things. A side-effect of it expecting to need to resample everything?
That seems pretty good actually. Using pulseaudio for the same job pretty
much triples the cpu load. That is, if jack is using 10% on it's own,
bridging pulse to jack raises CPU to about 28%. (over using pulse and jack
separately, don't bother ranting about pulse please, I am NOT suggesting
it's use in this case... or any other, just relating my experience) If you
think about it at all though, connected or not, each port/channel needs to
be fed silence at 48k all the time. Jack needs alsa-in to run at the same
latency as jack is too.
In my mind, the problem is that jack only deals with one device. Jack is
for pro or semmipro IFs which do have the possibility of sync. This seems
to be a common use so Jack _should_ handle it. It would seem that if jack
was aware there were two devices it would initialize both correctly when
it started rather than initializing one and hoping the other followed.
Certainly the user would then be able to tell jack which of two devices
was the master (for example) which _should_ be able to make a more stable
system. Maybe there are other problems that I am not aware of that keeps
this from being a reality as audio signal coding is not something I have
dealt with... or maybe in jackd3?
Really, Jackd is a great tool that just works for me. I am glad we have it.
BTW one more thing with the "multi" setup from before. If you are using
the setup from J Rigg's page. hw0 should be the clock master, I think. If
hw1 is the clock master then the:
ctl.playback24 {
type hw
card 0
}
(and similar section in capture) should reflect that, would be my guess.
--
Len Ovens
www.OvenWerks.net
Having
recently acquired a second Delta 1010 for my setup I've been
trying
to run the two in tandem using the alsa Multi hack. I'm getting the
xruns
Have you tried using one via jack and the other one via an
alsa<->jack
bridge
and then sync the two via the wordclock?
4142
days inactive
4147
days old
linux-audio-user@lists.linuxaudio.org
26 comments
8 participants
participants (8)
-
Ben Bell -
Devin Anderson -
drew Roberts -
Fons Adriaensen -
Joe Hartley -
John Murphy -
Len Ovens -
Paul Davis