Since the new URB interface has been implemented and everything has stabilised in the linux USB drivers, I've put together a driver for the empeg. There appears to be issues with the device closing before its buffer has been fully written (e.g using echo blah >/dev/empeg-car), but removing and reinstalling the driver seems to resurrect it. Otherwise, it seems to work fine and rather quickly. I think this problem actually resides in the underlying OHCI controller driver - either that or it also affects the ACM driver, which my code is based off.

You need to be running the latest development linux kernel on your PC - 2.3.39 is what I tested with. You also need to be aware that running this driver is at your own risk, as with all development kernel source. It's distributed as source, under the GPL. Because of the very beta nature of the driver, it's not going on the official downloads yet... you'll need to mail me (john@empeg.com) and I'll attach it in a reply.


- John.

(The above may not represent the views of empeg :)

Thanks very much for releasing this. Can you tell me what sort of transfer
speeds you have been achieving? I tried it on my UHCI laptop and only got about
30KB/s, which is only three times faster than the serial interface. Funnily
enough the emptool reported the first 20% going almost instantaneously and then
the upload slowing down.

Additionally, I can't try to run PPP over this, it would be nice if you could
supply us with a PPP kernel again, or even better, put PPP in all the development kernels.

Would it not perhaps be better to make the interface look more like an ACM device
and supply any required modifications to the standard linux acm device driver?

Paul

> Thanks very much for releasing this. Can you tell me what sort of transfer
> speeds you have been achieving? I tried it on my UHCI laptop and only
> got about 30KB/s, which is only three times faster than the serial interface.
> Funnily enough the emptool reported the first 20% going almost
> instantaneously and then the upload slowing down.

You should expect to get about 10 times that data rate. I've only tested it on an OHCI controller so far - I'll have to grab an empeg and try it on my home computer (UHCI based). Creating the file is counted as the first 20% of the upload, and isn't that bad an estimate when the USB transfer goes at the right speed.

> Additionally, I can't try to run PPP over this, it would be nice if you could
> supply us with a PPP kernel again, or even better, put PPP in all the
> development kernels.

This is true. I'll see what everyone suggests towards this.

> Would it not perhaps be better to make the interface look more like an ACM
> device and supply any required modifications to the standard linux acm
> device driver?

It's funny you should say this, because empeg-car.c IS basically acm.c :)
I've just removed all the control endpoint stuff (which doesn't exist) and make the buffers a lot larger, and put the right detection code in. I thought it would be better supplied externally rather than a patch to the kernel.

Out of interest, if you do a "time dd if=/dev/zero of=/dev/empeg-car bs=1048576 count=1" on the PC, and a "cat /dev/usb0 >/dev/null" on the empeg (do this first!), how fast does it transfer the 1MB? If this is also about 30-50KB/sec, then something's wrong with the UHCI layer.

Problems I know about are:

- cat'ing (or dd'ing) over about 3MB of data will make the PC's usb driver stop working. rmmod, insmod empeg-car will restart it. Looking at linux-kernel mailing list, some people are experiencing this with ACM too.

- doing an "echo hello >/dev/empeg-car" will work once, then the usb driver stops working. It appears there's something odd happening when the device is closed before the USB blocks are actually submitted (1ms later). I bet this also happens with ACM.

It is, basically, exactly the same as an ACM driver, but with all the ioctl's for modem lines removed. I suppose I could put them back in as dummy functions.


- John.

(The above may not represent the views of empeg :)

>> Would it not perhaps be better to make the interface look more like an ACM
>> device and supply any required modifications to the standard linux acm
>> device driver?

>It's funny you should say this, because empeg-car.c IS basically acm.c :)
>I've just removed all the control endpoint stuff (which doesn't exist) and make
>the buffers a lot larger, and put the right
>detection code in.

I realised that, that's why I made the suggestion. i.e. wouldn't it make more
sense to have an interfaceclass of 2 and interfaceprotocol of 1, etc, if it
indeed is a standard(ish) ACM device? I'd imagine that acm.c would need to
be adjusted not to require only one endpoint on the device too.

>Out of interest, if you do a "time dd if=/dev/zero of=/dev/empeg-car bs=1048576
>count=1

I did several variations on that and never achieved more than 30KBytes/s. All
the reads on the empeg were 32 bytes too, presumably they aren't buffered on
the empeg side?

I think I've got OHCI on my desktop so I'll try it on there. Any other suggestions?

Cheers,

Paul

Hi,

FWIW, I'm also running a UHCI interface and also noticed the "quick 20%, then slow transfer" thing. Tried timing dd with several block sizes and never got over 30K/s either.

Brandt

The USB is buffered on the empeg end - ISTR it's 64k receive and 16k transmit. You're probably seeing 32 byte reads as your PC USB is sending so slowly that the empeg is pulling individual usb packets (32 bytes) out of the buffer as soon as they arrive from the PC.

No suggestions except the problem does look like it's the UHCI driver in linux.

Hugo

Just some feedback for anyone who's interested in linux USB support. John posted
a message on the linux-usb mailing list which generated some useful feedback:

1. It's possible to communicate with the empeg if you have installed generic
USB serial support even without the empeg driver:

modprobe usb-serial vendor=0x084f product=1
mknod /dev/ttyUSB0 c 188 0
emptool --usb /dev/ttyUSB0
(helps if you commment out DEBUG in usb-serial.c...)

2. Communications over UHCI are currently limited "by UHCI's scheduling
of bulk transfers (one 32/64-byte packet per millisecond)"

3. The empeg/acm driver creates one interrupt per millisecond whereas the
usb-serial one does one interrupt per packet (due to usb-serial limiting
the buffer size to the packet size), thus it runs about half the speed
of the empeg/acm driver.

I presume the 1 packet/ms problem will be addressed at some point in the
near future, but it has nothing to do with the empeg.

Paul

Seems to be some bugs in usb-serial.c.

- You'll need to do a tty->low_latency = 1 in serial_open for a start.
- You'll need to allocate at least 512 bytes for the in/out bulk transfer buffers, not 32/64 bytes.
- The tty_flip buffers can still overflow, so you'll need to use the hack I put into empeg-car.c :)

I can't get it working reliably on my OHCI based machine - it seems to drop pretty much half of the packets coming from the empeg, and I have no idea why because the resulting code is almost the same as mine.

Hopefully somebody will figure out how to get UHCI working in a nice way, and figure out what the strange bugs are in USB at the moment.


- John.

(The above may not represent the views of empeg :)

Haven't had much response from other channels so i thought i'd try here.

I've been trying to get the empeg-usb from the beta9 release to go.

Tried it under 2.3.45 and .46

I've compiled the module and made the device. Then i insmod /lib/modules/2.3.46/usb/usbcore.o and then insmod the empeg-usb.o All appears to go well. (though i can't seem to modprobe usbcore or empeg-usb, have to manually insmod)

When i try to run emptool i get :
4001 Failed to open device /dev/empeg-car, errno:22

> Then i insmod /lib/modules/2.3.46/usb/usbcore.o and then insmod the
> empeg-usb.o All appears to go well. (though i can't seem to modprobe
> usbcore or empeg-usb, have to manually insmod)

You don't appear to have loaded a host controller. You need a modprobe
uhci or modprobe usb-uhci or modprobe usb-ohci in there somewhere. That
should also autoload the usbcore module.

Paul

170KB/s with UHCI on 2.3.46

>You don't appear to have loaded a host controller.

Thanks for the pointer. Now i've got something i can work on. Odd that it works under win98, i guess the win98 usb driver is able to do more initialisation than the linux one
[root@danski usb]$ insmod usb-uhci
./usb-uhci.o: init_module: Device or resource bus
From syslog:
Feb 23 00:51:30 danski kernel: usb-uhci.c: version v1.184 time 11:31:36 Feb 21 2
000
Feb 23 00:51:30 danski kernel: usb-uhci.c: Found UHCI device with no IRQ assigne
d. Check BIOS settings!


OK, changed that in the BIOS and got the uhci driver installed now. Odd that the empeg-car driver will install if it depends on a host controller and no host controller is installed.

Anyway, still no luck, same error message

[root@danski empeg-car]$ emptool /dev/empeg-car
Failed to open device /dev/empeg-car, errno:22


Also, i can't rmmod the empeg driver
[root@danski usb]$ rmmod empeg-car
rmmod: empeg-car: Device or resource busy

Is that expected?

> Odd that the empeg-car driver will install if it
> depends on a host controller and no host controller is installed.

The Linux USB stuff is quite new and very dynamic. I don't think
the process of nailing down module dependencies is very high on anyone's
list at the moment.

It sounds like you're not installing the modules in the correct order.
First of all install usb-uhci (or uhci, different version of driver),
this should autoload usbcore, then load empeg-car.o. Since empeg-car
depends on a host controller, you could argue that it should load one,
however it doesn't know which one you need (uhci/ohci). Since this
dependency on a variable is quite recent, there doesn't seem to be
a convention to do it yet. You can do something like this if you
want to automate it, add to /etc/conf.modules:
pre-install empeg-car modprobe usb-uhci

(untested).

Paul

So that there is no confusion, i'm running linux-2.3.47 and modutils-2.3.9.
I've got these lines in my modules.conf file:

alias usb usb-uhci
above usb-uhci empeg-car
below usb-uhci usbcore

this allows:

modprobe empeg-car

to load the modules in the order; usbcore, usb-uhci, empeg-car. Here's snippet from lsmod:

empeg-car               3092   1
usb-uhci               20552   0 (unused)
usbcore                54464   0 [empeg-car usb-uhci]

An ls -l of the device node is:

lrwxrwxrwx   1 root     root            6 Jan 17 20:24 /dev/empeg-car -> empeg-car0
crw-r--r--   1 root     root     240,   0 Feb 22 12:49 /dev/empeg-car0

For what it's worth; the sym-link is not required, but may become useful when a second Empeg becomes necessary. :) emptool is currently running to /dev/empeg-car at the moment and I just finished uploading. So it's time to go! It's always a good excuse to leave when you've got 'new' music in the Empeg! ... Testing is such an important step. :)