Linux-kernel mailing list archive 1999-37,: Re: Turning lucent winmodem into soundcard

# Re: Turning lucent winmodem into soundcard

Rogier Wolff (R.E.Wolff@BitWizard.nl)
Fri, 17 Sep 1999 10:59:53 +0200 (MEST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Chipzz: "Re: Linux 2.3.18ac5"
- Previous message: Matti Aarnio: "Re: no data from /dev/random on udb alpha"

Pavel Machek wrote:
> Hi!
>
> I've driver which essentially turns lucents winmodem into
> soundcard. So - hardware interface was guessed and "only" remaining
> part is doing v34 in software.

Neat!

> See discuss@linmodems.org archives for details.
>
> 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 :-)]

Jep.

> Then, there's v34 stack. It is not written yet, but it will eventually
> get written. It needs sort of realtime guarantees. Should it go into
> kernel?

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

I take it the kernel has some sort of buffer. How far do you expect to
fill the buffer each "write"? 8 bytes? -> 1ms repeat rate -> needs to
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.

That's the technical view.

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.

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.

(For the software modems to talk to each other over a "pipe" I think
you should do something like:

cat /dev/ptyqf > /dev/ptyqe & cat /dev/ptyqe > /dev/ptyqf

except that the double open won't be allowed. So you'll end up writing
a small application:

main (int argc, char **argv)
{
int fd1, fd2, n;
char buf[1024];

fd1 = open (argv[1], O_RDWR);
fd2 = open (argv[2], O_RDWR);
if (fork ()) {n=fd2;fd2=fd1;fd1=n;}
do {
n = read (fd1, buf, 1024);
write (fd2, buf, n);
} while (n > 0);
exit (0);
}

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

Roger.

    --
    ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
    *-- BitWizard writes Linux device drivers for any device you may have! --*
    ------ Microsoft SELLS you Windows, Linux GIVES you the whole house ------

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

- Next message: Chipzz: "Re: Linux 2.3.18ac5"
- Previous message: Matti Aarnio: "Re: no data from /dev/random on udb alpha"