On Sun, Dec 30, 2012 at 5:50 PM, Len Ovens <len(a)ovenwerks.net> wrote:
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.
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.
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.
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/