getting ews88MT to work in full duplex mode with jackd

Installation & Configuration Linux
#1

Has anyone managed to get a terratech EWS88MT (ICE1712 chipset) to work in full duplex with jackd? I’ve been having a spot of bother with it…

Works fine in playback only, no xruns even down to latencies of 64 samples.

Works fine in capture only, no xruns (but I had to hack the jackd alsa_driver.c to stop it failing due to ‘impossible sample size (1) detected’

full duplex, I get xruns even at -p2048 -n2 (can’t go any higher due to hardware limits)

I can minimize the number and frequency of xruns by increasing the ‘n’ setting and reducing the ‘p’ so that combined they approach the record buffer size of 65536/12(ish)

This card seems to have a capture buffer of 65536/10 (6553) and a record buffer of 65536/12 (5461). Is it simply not possible to duplex this in a way that jack can work with due to the 10outs 12ins?

My system:

Athlon X2 64 (running in 32 bit mode) 1Gb RAM 2.4GHz, nvidia geforce graphics (with nvidia drivers) EWS88MT sound (onboard sound disabled) alsa 1.0.18a (latest), have tried earlier versions, jackd 0.116.1 have tried earlier versions… realtime settings enabled…

typical jackd invocation:

jackd -R -d alsa -D -n 2 -p 2048 -d hw:0,0

minimal xruns:

jackd -R -d alsa -D -n 21 -p 256 -d hw:0,0

#2

Still having problems with ews88mt, could anyone who has had this card working in full duplex advise as to what clock/sync source they were using? I can get mine to work from the internal clock at 22050Hz full duplex with no xruns, switching on debug_wakeup in jackd shows that the capture and record interrupts appear to drift relative to each other with any sample rate above 22050 until an xrun occurs. I’ve added debug messages to the alsa driver to make absolutely sure I’m setting the sample rate correctly and I can guarantee the hardware is always being told to set to the same rate as jack, but it seems very much as if the capture and record clocks are drifting relative to each other (but they should be derived from the same XTAL on the board). Also, if I start two jackd’s, one in capture only and one in playback only I get no xruns at -p 64 -n 2 up to 96000Hz so I’m sure there’s nothing ‘bad’ with my system performance it just seems to be a problem running the capture and record together in one jackd (maybe some boards work and some don’t).

#3

It sounds as though your problems are slightly different, to those I was having, I had an onboard AC97 codec which I disabled, there are a few things you may or may not know regarding running multiple cards (which is in effect whats happening with an on board controller and a second card like the ews88).

If you disable the onboard codec in the BIOS, there’s a good chance it will still be detected, its been my experience that operating systems such as windows query the BIOS to discover the existance of onboard audio and ignore it if the BIOS says it isn’t there. Linux tends to find it whatever you set in the BIOS since it tends to query the hardware on the PCI bus directly without using the BIOS (I may be wrong but that’s my experience as I say).

The ‘aliases’ to the hardware cards that alsa uses will be dynamically asigned depending on the order in which modules get ‘probed’ into the kernel, this means that you may find hw:0,0 refers to your on board audio some times and other times hw:0,0 is the ew88MT and hw:1,0 is the onboard audio. This can cause problems, I had this happen alot. The ‘fix’ is to edit your /etc/modprobe.conf (backup your orignal one first incase it goes wrong) and add something like this:

#module options go here
options snd major=116 cards_limit=4
options snd-emu10k1 index=0
options snd_intel8x0 index=1

Here I’m using an intel AC97 codec (on board) as card one (hw:1,0) and an emu0404(snd-emu10k1) (I gave up with the ews) as card 0 (hw:0,0)

The problems I was having getting the ews88 to work in full duplex mode were I believe more to do with the hardware architecture and the interrupt latency (I posted in some detail about this - again, I’m happy to be proved wrong but I’m just going on my own experience). I also posted a possible workaround suggestion but was told in no uncertain terms that this was not the place to discuss that, so I’m reluctant to enter into that discussion again. I would be interested to know if you have success with your card. Have you tried in playback or capture only. e.g.

jackd -R -d alsa -n2 -p256 -r48000 -P -d hw:0,0

for playback

or

jackd -R -d alsa -n2 -p256 -r48000 -C -d hw:0,0

for capture.

check the jackd man pages but I think the above is correct. Obviously hw:0,0 may need to change to reference your card (see above)

#4

I no longer have the cards, but I had three of them, all working great with Jack. I did not have to do anything special, other than having the realtime kernel installed.

#5

There’s obviously something strangley ‘unique’ about my combination of cards + PC + kernel + drivers + jack + ardour + etc etc. If I run jack in ‘soft’ mode

jackd -R -d alsa -s -n 2 -p 2048 -d hw:0,0

I get no xruns (obviously), playback is fine but if I record at the same time then I get garbled recorded audio after a few minutes so its a buffer overrun on the capture side. Have looked at the ice1712 data sheet and added some printk messages to the alsa 1712 driver to check that the hardware is being sent the correct configuration and its all fine. arecord and aplay running simultaneously cause no alsa xruns so it looks like the problem is in jack somewhere. I guess I’ll have to start taking jack apart to see where its going wrong… :frowning: I used to have problems like this years ago using a 486DX33 and ISA soundblaster with windows - now I have 2 CPUs running at 2.4GHz and I’m still ‘waiting for the next click or pop’ in my audio, still its better than windows… But I hoped audio on PCs might ‘just work’ by now Grrr.

#6

Works fine in capture only, no xruns (but I had to hack the jackd alsa_driver.c to stop it failing due to ’impossible sample size (1) detected’

Not normal. I have an EWS88MT and there is nothing special to make it work like a charm in full duplex with low latency.

I suspect you don’t have a proper RT configuration or there is a hardware/software trouble somewhere.

Check with “cat /proc/interrupts” if there is no sharing but it should’nt be that of a problem anyway. I would recommand trying the card on another PC with linux or windows to be sure everything is working properly.

Verify that the samplerate matchs both in envy24ctl clock panel and with the jackd argument.

#7

Thanks for the suggestions:

I checked interrupt sharing etc, no problems as far as I can see. I would expect to get xruns in capture only and playback only as well if there was a general ‘system timing’ problem like low priority irqs etc. I can turn the latency down to 64 samples in playback only or capture only and I can run it for hours with no xruns (while doing graphically intensive stuff too - and cpu intensive stuff as well) - whatever I do I can’t provoke an xrun in capture only or playback only, but as soon as I switch to duplex (-D option) it happens very regularly (modified the jackd code to tell me how many processes since the last xrun and its always about 2000), When it happens it gets triggered in jackd alsa_driver_wait by poll() returning POLLERR and then subsequently -EPIPE which I suppose is caused because the alsa driver is stopped in SNDRV_PCM_XRUN. Its very much as if the input and output are slightly out of sync although the sample rate for each side has to be the same since the hardware uses the same clock and my sample rate in jackd -r 48000 matches that in alsamixer. I’m beginning to think it can’t really work in this mode reliably since it uses different numbers of channels, interleaved on the capture and playback side which must lead to differences in the timing since the interrupts are generated by a down count of dwords in the capture and playback DMAs

#8

forgot to mention in my previous post that the ews88MT works in windows, as far as I remember, it was a while ago on a much lower spec machine - can’t remember if I used the asio or direct sound drivers which makes a difference to the way the data is DMA’d so it might explain why/if it worked…

#9

Hi,

I am experiencing strange behaviour like you.
Unfortunately the box it’s not connected to the internet so I can not report from there but after a little try saw lot of xruns.

My guess is that onboard ac97 related modules create a kinda of conflict, putting ac97-codec kernel module in the modprobe black list finally allowed to see envy24mixer and the card while if the module is loaded I see the onboard card even if it’s not enabled in the bios (?!).

I am going to investigate and feedback to you if still interested.

I must say that a DMX fire works fine at home.

#10

Terratec EWS88MT

I understood you were getting a lot of xruns running in duplex mode, isn’t it? Well, my jackd freezes completely after start and the xruns indicator grows up exponentially.

So your suggestion is to work on modprobe options in order to load both cards letting ews88mt to be addressed as hw:0 without taking care of the ac97 being the hw:1. I’ll try.

Did you asked about this on LAU? (even if I think many users on this forum are in LAU too)

regards

ps …the BIOS, what’s the need for it if we can’t use it to turn features on/off?! :slight_smile: