On Sun, Dec 30, 2012 at 5:50 PM, Len Ovens <len@xxxxxxxxxxxxx> 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/ _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
