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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
