Ok, for anyone who’s interested, I think I’ve found out why the ews88mt doesn’t work for me in full duplex mode, so here’s why and also why this represents a problem for doing full duplex sample accurate audio with jack. This is not a problem with jack as such (I think jack and ardour are fantastic - far better than anything else in the PC audio world) - but more a combination of quite common factors and a bit of bad luck:
The ews88 uses the ice1712 chip, as do a lot of other sound cards. This chip has two halves (DMA channels) both running from the same clock, one for play and one for capture.
In each half of the chip there’s a counter for the DMA channel that counts down from the period size -1 to zero and then sets a status flag and signals an interrupt. The counter resets and begins counting again once the interrupt flag is cleared.
The alsa driver responds to the interrupt and checks the flag to see if it was playback or capture or both that require attention. This also wakes up jackd
If the time taken to respond to the interrupt is less than one sample period (about 20us at 48K) then the capture and playback will stay in sync with each other (offset by a fixed (ish) number of uS). However, if it takes longer than a sample period to respond then the record and capture interrupts will begin to drift (the minimum interrupt period is buffer_size * sample_period + some_error, given that some_error can never be negative as we can’t process the interrupt before it’s happened, there is never a way to catch up, eventually the capture and playback interrupts drift so far out that there is an xrun and the driver resets, and the drifting process begins again.
In half duplex mode this is not a problem since there is an entire buffer (the -p setting in jackd) * sample_period in which to respond to the interrupt since we don’t care about being in sync with the other half of the chip, and while we’re waiting for the interrupt to signal processing of one half of the buffer, the adcs/dacs are busy filling the other half. There will only be a problem if we take more than an entire ‘-p’ to respond.
If I get jackd to report the time spent in poll for capture and playback I can see this happening, the sum of the capture and playback poll times always= buffer_size * sample_period uS, with the difference between the playback and capture times being ‘fixed_offset + random_dither’ once the ‘random_dither’ part goes over 20uS the ‘fixed_offset’ becomes another sample period longer. And so it goes on until they drift apart enough to cause an xrun.
This explains why I can get full duplex with no xruns at up to 22050Hz sample rate but progressively worse performance above that, yet I can do ‘capture or record only’ at up to 96K.
Simply switching to a higher prority interrupt is not really practical (mine and most modern BIOSes no longer let you manually configure stuff like that grrrrr) and relying on the realtime aspects of the kernel is a bit hit and miss it seems, and not really where the problem should be solved (I think).
- It is resonable to expect the kernel + realtime patches to respond to an interrupt within a buffer period but the critical thing here is getting everything done in a sample period e.g. 1/48000 S not 1/48000 * (-p setting) S
Putting the card in another slot and ‘hoping for the best’ is not really a proper solution either - especially when most modern boards only have one PCI slot if you’re lucky… Mine has two but it doesnt work in either…
I can only assume those of you who have had this card working at full duplex, full sample rate have been lucky or skillful with your choice of hardware / kernel / system configuration etc. For the moment, I’ll have to look at alternative solutions which may include building a modified jackd or modified alsa driver…