[lkml]   [1999]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Turning lucent winmodem into soundcard
    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.


    > See 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 :-)]


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


    ** ** ** +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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:54    [W:0.022 / U:9.000 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site