Messages in this thread | | | Subject | Re: Turning lucent winmodem into soundcard | Date | Fri, 17 Sep 1999 10:59:53 +0200 (MEST) | From | (Rogier Wolff) |
| |
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.
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.
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/
| |