Re: [LAD] Tascam US-16x08 0644:8047

[OnkelDead]

On my UbuntuStudio 16.04 (4.4.0-36-lowlatency) the streaming interfaces
(16xin & 8xout) works perfect with the stock driver / JACK.
The intention of my custom snd-usb-audio is to offer the build-in DSP
features of the US-16x08.
So I didn't made changes to the streaming interfaces but added some mixer
quirks to the stock driver.
Add. I did coded a custom mixer application (QT5) to control the EQ and
compressor function via those new mixer interfaces.


ranokio wrote
> With JAck capture only works fine on Playback only mode, I have 8
> independent neat outputs

If you have problems with the streaming interfaces, I guess my driver wont
help you.

You may investigate the diff-file based on my changes in Ubuntu 16.04 which
you'll find  here   .

Note! Because I'd never investigate Fedora sources, I assume you should NOT
apply the patch to your kernel source directly.

Greets
Detlef



--
View this message in context: 
http://linux-audio.4202.n7.nabble.com/Tascam-US-16x08-0644-8047-tp96678p101226.html
Sent from the linux-audio-dev mailing list archive at Nabble.com.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tascam US-16x08 0644:8047

[Jeremy Jongepier]

On 08/30/2016 11:47 PM, Len Ovens wrote:
> On Tue, 30 Aug 2016, Greg wrote:
> 
>> I suspect the previous USB chipset was causing me more problems than
>> typical,
>> as I am now very much enjoying the OOTB experience. I did see updates
>> to the
>> driver as well (workarounds/adding delays) in the time that had elapsed.
> 
> I am told that all motherboard chipsets are less than they could be.
> Intel or VIA usb chipsets generate more interrupts than NEC (or maybe
> SIS). The defining factor it seems is the USB 1.1 part of things. There
> are two of them intel/via use the UHCI driver which expects the MB CPU
> to do lots of the work. Other chips use the OHCI protocol which does as
> much work as possible in the chipset. This one uses a NEC chipset but is
> USB3 so I don't know what the control protion is:
> http://www.newegg.ca/Product/Product.aspx?Item=9SIAA0D4C34273_re=PCIe_USB_card-_-9SIAA0D4C34273-_-Product

I can recommend this one, almost the same chipset:
http://www.dx.com/p/ake-007-2-port-usb-3-0-high-speed-pci-e-expansion-card-for-desktop-blue-silver-208899

Used it with a RME Babyface and it performed way better than the onboard
USB ports. So I reckon the Newegg one will do  a good job too.

> 
> For something more expensive that has OHCI in the spec:
> http://www.newegg.ca/Product/Product.aspx?Item=N82E16815114048_re=PCIe_USB2_card-_-15-114-048-_-Product
> 
> I do not know where things fall in the OHCI/UHCI with USB3 chipsets...
> but I think we can be pretty sure Intel/VIA go the cheap way. Thing is,
> even if USB3 doesn't use the O/UHCI part of things, almost all
> multichannel USB audio interfaces do. It might be worth while having a
> list of known good chipsets/PCIe USB cards.
> 
> BTW, even with uhci drivers, I found it made a big difference to:
> a) make sure the irq that goes with that driver/usb port is not shared.
> b) rtirq lists that usb port separately from the rest (IE. usb3 usb, not
> just usb)
> c) nothing else is plugged into that port via a bridge/hub whatever.

+1.

> 
> This meant for me (on my netbook) only using the USB port on the right
> side, not using the second USB port on the right side... adding a hub to
> the left side USB port for everything else (I was running from a USB
> hard drive at the time). I was able to run the (USB 1.1) audio device
> with jack at 64/2 with no xruns with this set up. (Atom single core at
> 1.6Ghz) Test duration being overnight so 6 to 8 hours. (cron turned off,
> ht off(well told Linux only one core), CPU gov performance (also tried
> userspace at 800MHz with success), setting rtirq RTIRQ_NAME_LIST="usb3
> snd usb".
> 
> For someone who has done some real world testing:
> http://crimeandtheforcesofevil.com/blog/2016/07/25/so-hey-usb-chipsets-totally-matter/

Some people did bother:
https://www.forum.rme-audio.de/viewtopic.php?id=19940

> 
> 
> Point seems to be, that those going portable who rely on onboard USB...
> you may want to load linux onto a Mac which I am told will have good
> chipset, or expect to have higher latency. This is ok for recording, not
> for softsynth or effects. Otherwise add a new USB card.
> 
> I do not know if the UHCI and OHCI drivers can run side by side or if
> the internal USB would have to be disabled.

That shouldn't be necessary.

Jeremy



signature.asc
Description: OpenPGP digital signature
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tascam US-16x08 0644:8047

[Len Ovens]

On Tue, 30 Aug 2016, Greg wrote:


I suspect the previous USB chipset was causing me more problems than typical,
as I am now very much enjoying the OOTB experience. I did see updates to the
driver as well (workarounds/adding delays) in the time that had elapsed.


I am told that all motherboard chipsets are less than they could be. Intel 
or VIA usb chipsets generate more interrupts than NEC (or maybe SIS). The 
defining factor it seems is the USB 1.1 part of things. There are two of 
them intel/via use the UHCI driver which expects the MB CPU to do lots of 
the work. Other chips use the OHCI protocol which does as much work as 
possible in the chipset. This one uses a NEC chipset but is USB3 so I 
don't know what the control protion is:

http://www.newegg.ca/Product/Product.aspx?Item=9SIAA0D4C34273_re=PCIe_USB_card-_-9SIAA0D4C34273-_-Product
For something more expensive that has OHCI in the spec:
http://www.newegg.ca/Product/Product.aspx?Item=N82E16815114048_re=PCIe_USB2_card-_-15-114-048-_-Product
I do not know where things fall in the OHCI/UHCI with USB3 chipsets... but 
I think we can be pretty sure Intel/VIA go the cheap way. Thing is, even 
if USB3 doesn't use the O/UHCI part of things, almost all multichannel USB 
audio interfaces do. It might be worth while having a list of known good 
chipsets/PCIe USB cards.


BTW, even with uhci drivers, I found it made a big difference to:
a) make sure the irq that goes with that driver/usb port is not shared.
b) rtirq lists that usb port separately from the rest (IE. usb3 usb, not 
just usb)

c) nothing else is plugged into that port via a bridge/hub whatever.

This meant for me (on my netbook) only using the USB port on the right 
side, not using the second USB port on the right side... adding a hub to 
the left side USB port for everything else (I was running from a USB hard 
drive at the time). I was able to run the (USB 1.1) audio device with jack 
at 64/2 with no xruns with this set up. (Atom single core at 1.6Ghz) Test 
duration being overnight so 6 to 8 hours. (cron turned off, ht off(well 
told Linux only one core), CPU gov performance (also tried userspace at 
800MHz with success), setting rtirq RTIRQ_NAME_LIST="usb3 snd usb".


For someone who has done some real world testing:
http://crimeandtheforcesofevil.com/blog/2016/07/25/so-hey-usb-chipsets-totally-matter/

Point seems to be, that those going portable who rely on onboard USB... 
you may want to load linux onto a Mac which I am told will have good 
chipset, or expect to have higher latency. This is ok for recording, not 
for softsynth or effects. Otherwise add a new USB card.


I do not know if the UHCI and OHCI drivers can run side by side or if the 
internal USB would have to be disabled.


--
Len Ovens
www.ovenwerks.net

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tascam US-16x08 0644:8047

[Greg]

That's awesome!

I went back to using windows 7 for a bit with my audio device, until eventually
I became fed up with the driver problems (not to mention windows in general) and
tried linux again, this time on a different machine... and it worked!

I suspect the previous USB chipset was causing me more problems than typical,
as I am now very much enjoying the OOTB experience. I did see updates to the
driver as well (workarounds/adding delays) in the time that had elapsed.

As far as 'nice features', I believe that they are mostly useless to me as on
windows they are 'printed', eg, compressor/eq are applied not only to the
monitored output, but also to the bitstream received by the computer. I very
much prefer to be able to capture the raw data and adjust compression/eq after
the fact. In my case with an i5 and Ardour, I am able to run those same fx
and push data back out to the device with usable roundtrip latency. (I use
my US16x08 for live sound during music practice/rehearsal).

However, for certain situations (less processor power - imagine controlling
this device with your tablet!, or an application that is even more sensitive to
latency?) I could see this being immensely helpful. Not only
that, if we crack open this egg, there's the possibility that we could improve
or pave the way to improving the signal chain within the device itself!

I'm happy to test if you'd like to take this off-list. Please document and
share what you have found!

-g


On Tue, Aug 30, 2016 at 01:45:47AM -0700, OnkelDead wrote:

Hi Greg,

if your request is still relevant I think I may help.

On my PC the common alsa driver worked OOTB.
I did process what you've mentioned and analyzed USB communication of Tascam
US-16x08 in a Windows 7 VM, but my intention was to get access to all this
nice features (compressors, EQs) the device offers from my Ubuntu Studio
14.04.
As also an USB noob, several smoking heads and 2 weeks later I was able to
patch my snd-usb-audio kernel driver to support all mixer interfaces of that
device.

Interested?

Greets
Detlef



--
View this message in context: 
http://linux-audio.4202.n7.nabble.com/Tascam-US-16x08-0644-8047-tp96678p101024.html
Sent from the linux-audio-dev mailing list archive at Nabble.com.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


!DSPAM:57c55a0e316809058321121!

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tascam US-16x08 0644:8047

[Clemens Ladisch]

OnkelDead wrote:
> I was able to patch my snd-usb-audio kernel driver to support all
> mixer interfaces of that device.

Please don't keep that information a secret.


Regards,
Clemens
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] Tascam US-16x08 0644:8047

[OnkelDead]

Hi Greg,

if your request is still relevant I think I may help.

On my PC the common alsa driver worked OOTB.
I did process what you've mentioned and analyzed USB communication of Tascam
US-16x08 in a Windows 7 VM, but my intention was to get access to all this
nice features (compressors, EQs) the device offers from my Ubuntu Studio
14.04.
As also an USB noob, several smoking heads and 2 weeks later I was able to
patch my snd-usb-audio kernel driver to support all mixer interfaces of that
device.

Interested?

Greets 
Detlef 



--
View this message in context: 
http://linux-audio.4202.n7.nabble.com/Tascam-US-16x08-0644-8047-tp96678p101024.html
Sent from the linux-audio-dev mailing list archive at Nabble.com.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

[LAD] Tascam US-16x08 0644:8047

[Greg]

Greetings,

I am fairly new to USB dev (in linux in particular, but also in general), but I
would very much like to try to get support for the above device working in
snd-usb-audio.

- Is this an appropriate place to discuss snd-usb-audio?
- Are there any recommended reading pointers for behavior of the quirk table?

I patched parse_audio_format_rates_v2(), get_sample_rate_v2(), and
set_sample_rate_v2(), and through some sort of beginner luck was able to get
aplay audio out of the first two channels. That was incomplete hackery though
(eg fixed sample rate), and I would like to learn how to properly add quirk
support. There have been other reports that this device worked OOTB, but I
fail to see how!

I've also been examining the traffic to the device with wireshark and a
win7 vm, but the learning curve for USB is a bit steep, so I am digesting. (:

If anyone can provide suggestions on lsusb output alone, here's what I have:
http://pastebin.com/pA9MLQet

cheers,
Greg

[x-post from alsa-devel due to empty thread -
see: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094682.html]

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev