lkml.org 
[lkml]   [1999]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.035 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site