full duplex audio and why its a 'potential' problem with jack...

No replies
ice1712berg
User offline. Last seen 5 years 13 weeks ago. Offline
Joined: 2008-12-26
Posts:

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...

alex stone
User offline. Last seen 3 years 17 weeks ago. Offline
Joined: 2008-03-02
Posts:

Good post. Using F8 and Ubstudio (32 and 64bit boots) my delta44 (ice1712) performs well with playback only, and slightly less well with both C and P enabled.

I've taken notes here, thanks for the info.

Alex.

ice1712berg
User offline. Last seen 5 years 13 weeks ago. Offline
Joined: 2008-12-26
Posts:

Have you been able to run your card in capture only? I had to modify jackd to get mine to work in capture only without jack bombing with 'impossible sample width (1) discovered'
'P' mode worked fine, as did 'D' apart from the xruns...

GMaq
GMaq's picture
User offline. Last seen 3 days 22 hours ago. Offline
Joined: 2007-12-11
Posts:

ice,

Well I won't even pretend to be as knowledgeable as you are regarding this, I'm wondering if there is a chip revision number that comes into play?

I am using an M-Audio 1010LT which also has the ice1712 chip, I have had great full duplex performance with JACK .109.2 and have recently updated to JACK .116.1 and have not yet had time for in depth testing. For the record I usually use 44100 for a sample rate.

If I missed this I'm sorry but which JACK version are you using?

ice1712berg
User offline. Last seen 5 years 13 weeks ago. Offline
Joined: 2008-12-26
Posts:

There may be a chip revision number.. I have quite an old board, I use jack.116.1 but I also regressed to jack .109.2 - and still can't get playback and capture in sync. I'm experimenting with running multiple jack servers at the moment as a kind of 'diagnostic' - one in capture only and one in playback only, both set to the same rate. So far there are no xruns, but if I measure the time from the audio process callback in the capture jackd to the audio process callback in the playback jackd I can see they are 'phasing' in and out as if they are running on two very similar but slightly different clock frequencies. The drift is very slow, but it inevitably leads to an xrun when trying to run in full duplex mode. The datasheet for the ice1712 shows that both playback and capture DMAs on the device run from the same clock signal (not just two clocks of the 'same' frequency) so its hard to see how they can drift unless there's some mechanism like I described previously.

My main concern is that if its not possible to guarantee lock between capture and playback on cards that use seperate DMA and IRQs for each (which seems to be 'a lot' of cards) then it's difficult to know whether a particular card will work or not. I've had this card for a few years - I think it worked in windows but that was on a different machine, but at about £400 new its alot to pay for a card which at the moment is virtually useless to me, and I don't feel comfortable buying a replacement until I've solved this problem...