Tascam US1800. any way to get it working?

[allan]

Hello there,
This is my first post in the forum, although i have been a lurker for some time now, using the wealth of knowlege hosted here, i'm hoping someone might have some information i've not yet managed to locate.

My problem is simple, my us1800 doesn't work, i bought this hardware as it gave me the most inputs for the price, but it seems the overall cost was higher than i expected, i'm at risk of having to return to M$ to do all my audio work :shudders:

syslog says:
Jul 12 15:08:46 Allan-Desktop kernel: [12870.559123] usb 2-1: new high-speed USB device number 5 using ehci_hcd
Jul 12 15:08:46 Allan-Desktop mtp-probe: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:13.2/usb2/2-1"
Jul 12 15:08:46 Allan-Desktop mtp-probe: bus: 2, device: 5 was not an MTP device

lsusb says:
Bus 009 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 1397:01b0 BEHRINGER International GmbH (my UMX610)
Bus 004 Device 003: ID 046d:c051 Logitech, Inc. G3 (MX518) Optical Mouse
Bus 002 Device 005: ID 0644:8030 TEAC Corp.

aplay -l says
card 0: CA0106 [CA0106], device 0: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 1: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 2: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: CA0106 [CA0106], device 3: ca0106 [CA0106]
Subdevices: 1/1
Subdevice #0: subdevice #0

even if its a complete negative "no this will never work", any answer to this problem will be greatly appreciated.
thanks in advance
allan

[AutoStatic]

Hello allan,

Afaics it is unsupported. The USB drivers apparently recognize the device ID (lsusb shows a TEAC device) but then ALSA (the sound driver stack for Linux) doesn't see anything. So I fear that at the moment it just doesn't work. What distro are you using?

[allan]

im using ubuntu studio 12.04 with KXstudio PPA, on the stock kernel 3.2.0-23-lowlatency #31-Ubuntu SMP PREEMPT x86_64

If i got in touch with the ALSA devs, would there be any way i could help out remotely, or do you thing they would need the hardware in front of them to to the work of writing/reverse engineering a driver?

[Pablo]

If i got in touch with the ALSA devs, would there be any way i could help out remotely, or do you thing they would need the hardware in front of them to to the work of writing/reverse engineering a driver?

I read the alsa users list and recently one guy had his USB card working, thanks to the alsa dev Clemens Ladisch. He asked for the output of "lsusb -v" for that device and then told the guy to add some lines to the driver and recompile. After confirmation that it worked, the patch was sent to the mainline kernel.

It won't be so easy for every device, but you never know until you try.

[AutoStatic]

Yeah if Clemens wants to help out and the device resembles the US-800 there might be a chance you could get it to work.

But don't get your hopes up high

[allan]

well i managed to get in touch with clemens, he echoed the need for lsusb -v.
the info has been sent, time to wait for his response and hope there's not too much work involved for him to be put off! i'll bend over backwards to help out however i can, but im no programmer, so i feel kind of useless at the moment.

im sure there would be a great many people happy to see this hardware working with linux, i think it's an awesome piece of kit for a home user price tag. perfect for bands who wish to do their own recordings.

edit: i know i shouldn't get my hopes up, but im itching to unplug that old SB Audigy from its pci slot and have rid.

[AutoStatic]

Let's hope for the best and keep us posted!

[allan]

still waiting for a reply to the lsusb info i sent. it's been two weeks, but it seems like eternity!
if I have any news, i'll be sure to post.

[allan]

A little update, i managed to get a response from daniel mack, he offered a glimpse of hope, but one that is technically, beyond my knowledge.

The descriptors don't tell anything about class compliance, and it also
doesn't look like there are any interfaces that are compliant but marked
vendor specific. Hence, I have litte hope the generic driver can do
anything useful here.

The protocol implemented by the hardware might be related to what the
other Tascam interfaces speak, namely those which are supported by
sound/usb/usx2y/ - you could try adding the IDs of your device to the
match table (sound/usb/usx2y/usbusx2y.c, snd_usX2Y_usb_id_table).

this was the only suggestion he could afford me other than reverse engineering the windows driver. ive spent a bit of time trying to figure out what to do, but have stumbled into a cul de sac, and don't want to use their time by asking silly (for them) questions. So, does anyone know if these tables he mentioned are actual files, or if they are hidden within files. i've used the locate command

Code: Select all

locate sound/usb/usx2y/
/lib/modules/3.2.0-23-lowlatency/kernel/sound/usb/usx2y/snd-usb-us122l.ko
/lib/modules/3.2.0-23-lowlatency/kernel/sound/usb/usx2y/snd-usb-usx2y.ko
/usr/src/linux-headers-2.6.35-32/sound/usb/usx2y/Makefile
/usr/src/linux-headers-3.2.0-23/sound/usb/usx2y/Makefile


and thas is the output, the .ko files are not plain text and so can't be opened in text editor, and the kernel source is not applicable to the kernel i run, i use the lowlatency, but the makefiles are only in the generic source tree.
quite frankly i have no confidence in what to do next, whether or not, i need to compile a new kernel, and if so, how to find out what the IDs' of my device are, and how to correctly add them to the makefile.
is there anyone perhaps willing help an old noob, and hold my hand a little on this?

[j_e_f_f_g]

the .ko files are not plain text

No, those are the compiled binary drivers. Those are what you're going to replace.

You need to download the alsa drivers source code. (If you're using Debian, there's a package listed in synaptics of those sources. Make sure you download the driver sources-- not the alsa userspace sources). You also need the kernel headers and symbol files. For most distros, the only way to get a working environment for kernel dev is to download the linux kernel sources and compile the kernel. But if using debian, there is already a package with the headers/symbols. Use debian.

Then Dan says to load the c source file snd_usX2Y_usb_id_table.c into your text editor. This file contains one huge array of C structs (defined using some funky gnu c syntax, rather than standard c). Each struct in the array contains info about a particular usb product. For example, one struct contains info for a Roland UA1010. Another struct contains info for a M-audio Pro tracks. There's probably 100 products there. Search the array for any Tascam product. Hope that it's so similiar that all you need do is paste a copy of that struct definition, change the usb vendor and product ID numbers to your tascam product, compile the new changes into a new snd-usb-usx2y.ko driver. Reboot and hope the new driver works.

how to find out what the IDs' of my device are

Run "lsusb -v" from a root term. It will display info on all your usb devices. Look through until you see anything made by tascam. Jot down the VendorID and ProdID.

how to correctly add them to the makefile.

No, don't touch the makefile. Add the info in a new C struct you paste into that big array in snd_usX2Y_usb_id_table.c. Read the source comments for the proper format. You'll need to have some C programming skills.

If I've made any of this sound easy, it ain't. I went through all of this myself when I added alsa support for an Opcode MidiPort 32 usb interface I own. Kernel programming is the hardest job a programmer faces. I never would have tried if I didn't already have years of low level C and asm programming, written drivers before (Windows, OS/2), read the book "Linux Device Drivers" (because every OS is different), and first wrote some simple linux drivers before tackling a major subsystem like alsa. If you're not ready for this, you're in for a world of hurt, and probably will succeed only in trashing your OS. Even if you do everything right, your unit may be different from the unit you copied, and the new driver still won't work.

Let me suggest a different approach. That Dan guy did a lot of work recently on alsa's usbaudio driver. He knows that code. And Clem is currently a major alsa dev. You're in contact with the two guys probably most capable of adding your support. If you were to email one and say "If I were to loan you my tascam for however long you needed it to add alsa support, would you be interested in doing that?", the odds of you getting support are as good as it gets. (They may say no. They're working for free). paying to ship your unit is a real bargain for this level of support.

[AutoStatic]

If you were to email one and say "If I were to loan you my tascam for however long you needed it to add alsa support, would you be interested in doing that?", the odds of you getting support are as good as it gets. (They may say no. They're working for free). paying to ship your unit is a real bargain for this level of support.

Maybe they're also ok with SSH access to a box with this device attached.

[allan]

If you're not ready for this, you're in for a world of hurt, and probably will succeed only in trashing your OS. Even if you do everything right, your unit may be different from the unit you copied, and the new driver still won't work.

i did about 5 years programming with pascal back in the 90's, but i fear, having not used it in about 15 years, all that has knowledge has long since gone :sobs
i'll investigate the clues you kindly gave me, and im not worried about borking my system, i have /home on another partition, i have my dpkg --get-selections log file tucked safely away, and all my music is separate to the OS, on a different physical disk, a reinstall in not a problem if the worst happens.

paying to ship your unit is a real bargain for this level of support.

this is true, but im not willing to ship my baby overseas (or even within france metropole), i do use it every day. luckily i used reaper in WINE, and so shifting to the evil OS wasn't too much of a challenge, all my work was easily transferred.
the ssh suggestion was much more feasible, and i guess a possibility. if i fail (which i know i probably will) in doing the above, i'll suggest this to the Devs, see what they think.

Jot down the VendorID and ProdID.

i had a feeling it might be that, thanks for the confirmation.

No, those are the compiled binary drivers.

Ok, i thought binary drivers in linux were always ".so", learn something new everyday

i'll see how i get on, and i'll post any results here, although i'm not too sure when i'll get round to it, i have a new job starting monday, and a baby due any day now, so my schedule for tinkering is about to take a massive hit! thanks for your replies everyone, they're very much appreciated.

[j_e_f_f_g]

Run synaptics package manager and search for "linux headers" to find the kernel headers. There is a package for the real-time kernel, whose name ends with rt.

The "alsa-source" package installs all the alsa drivers C source code. I forget where Debian dumps those files, but you need root permission to get to them. Look for usbusy2y.c since that's for the tascam us428. And that snd_usX2Y_usb_id_table array you need to edit is at the bottom of "usbusy2y.c".

Make sure the "build-essential" package is installed.

[Barton]

I'm willing to help in any way possible. I'm thinking about purchasing one of these and would really like to see native Linux support. I'm currently running Gentoo, so source modification and kernel compiling will be no problem. Since I currently don't have one of these devices to work with, however, I'm afraid at present I can't do anything helpful. I've already taken a look at the mentioned alsa sound files, and believe I would be able to make the modifications, but I don't have the ID info provided by the output of

Code: Select all

lsusb -v

If I could get the info I might even be able to compile a kernel that I could pass along for testing.

[allan]

I'm willing to help in any way possible.

if you could, that would be great, the relevent output is

Code: Select all

Bus 002 Device 002: ID 0644:8030 TEAC Corp.
Couldn't open device, some information will be missing
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass       255 Vendor Specific Subclass
  bDeviceProtocol       255 Vendor Specific Protocol
  bMaxPacketSize0        64
  idVendor           0x0644 TEAC Corp.
  idProduct          0x8030
  bcdDevice            1.00
  iManufacturer           1
  iProduct                2
  iSerial                 3
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           80
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x40
      (Missing must-be-set bit!)
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x009c  1x 156 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               4
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            5
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               4
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x86  EP 6 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               1


if you were to compile a kernel, am i right in thinking that they are distro specific, and so therefore, not interchangeable? i run ubuntu studio.

i would still highly recommend this card, despite the lack of support for linux, it's a great bit of kit for the price. the lack of pre-amps in the TRS inputs is quite apparent, but overdubs are generally done with mics through XLRs.