Messages in this thread | | | Date | Fri, 17 Sep 1999 21:44:12 +0200 | From | Jamie Lokier <> | Subject | Re: Turning lucent winmodem into soundcard |
| |
Rogier Wolff wrote: > > Now, question is where should it go. That winmodem uses interrupts so > > little that it can be nicely done using polling+userspace with zero > > performance lost. Still it is device driver. Should it go into kernel? > > [Well, drivers/sound/modem would be cool :-)]
Personally I prefer drivers/modem, as we may well need to include ADSL support eventually. Then again, current sound & modem hardware is increasingly integrated.
> The question is how strong are those "real-time" requirements. Will > you have to reply in 1ms? 10? 100? Even if the feedback loop will > break down with a 1 second delay, it is a "real-time" requirement.
It's soft real time if you don't mind the line possibly being dropped. I suspect you don't, because it might get dropped anyway.
> However, it is pretty likely that a userspace mlocked, real-time > priority process can meet that requirement. In fact you can probably > meet the 10ms requirement that way. The 1ms will be hard. Even in the > kernel. On the other hand, missing the "deadline" once every minute > isn't all that bad. You'll loose a few bits.
No, missing the deadline once every minute means a buffer underrun, and a sudden loss of signal. (Unless the kernel fills in with idle frames, but that is not so easy with V34 if the main modulation is in user space). A sudden loss of signal should simply stall some modems including ours, but will probably make cheaper modems at the other end drop the line.
> be done in-kernel. 80 bytes? -> 10ms repeat rate -> Either > way. Kernel implementation is more reliable (less retrains, just > because you miss a deadline). 800 bytes? -> 100ms repeat rate -> can > easily be done in userspace.
I'm thinking 10-20ms should be ok so long as the low latency kernel patches can make that reliable. I've read that one chipset has special hardware support so that 20ms delay in the OS responding is acceptable. Apparently this is a feature. So maybe there is hardware that must get a faster interrupt response. But a faster interrupt requirement should be ok with the low latency patch -- 2-4ms has been mentioned on this list.
> From a conceptual viewpoint I'd recommend the in-kernel approach > too. I recommend thinking about structuring the V34 source to allow > both approaches, which will facilitate debugging in the beginning, > because you would run it in userspace most of the time.
I've been planning a framework that uses two RT tasks for the critical stuff, the Tx one having slightly higher priority than Rx. Ingo's low latency patch seems to provide us with reliably low jitter. Smaller buffers reduce latency which is important for Quake players, but I don't think <20ms latency is critical. Not underrunning is, however. So my code will estimate the typical latency and jitter to decide how long the buffers should be.
What is critical is knowing exactly when each sample is sent and received. But that is relatively easy with the right interface.
I would like to use the DSP where available.
Basically we do need some kernel code, but modulation & demodulation _probably_ do not need to go there, and none of the higher protocols need to.
> You should be able to have two software modems talk to each other > using a pipe... These should survive some distortion on the line, > which can also be simulated in software.
Yes, we need to do a lot of work on line simulation if we're to tune the modem to work well.
Real lines not only add noise: they add other sounds, echos, frequency distortion, nonlinear distortion, exchange quantisation noise and clamping, and mismatched sample rates with unknown DAC/ADC characteristics. At least.
> If you forget the "rate limiting" like this, and you write the > software to do its timing based on the number of bytes recieved, we > will easily be able to do V34 at 5 times the normal speed over a hifi > audio cable in the future....
Heh. Or at 5 times the normal speed (10 if you can use stereo) over a sound card with greater dynamic range and sample rate :-)
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |