14 Jul
2015
14 Jul
'15
11:04 p.m.
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]
30 Aug
30 Aug
12:03 p.m.
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-tp96678p101…
Sent from the linux-audio-dev mailing list archive at Nabble.com.
8:54 p.m.
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-tp96678p101…
Sent from the linux-audio-dev mailing list archive at Nabble.com.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
!DSPAM:57c55a0e316809058321121!
11:47 p.m.
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&cm_re=PCI…
For something more expensive that has OHCI in the spec:
http://www.newegg.ca/Product/Product.aspx?Item=N82E16815114048&cm_re=PC…
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-tota…
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
31 Aug
31 Aug
9:22 a.m.
On 08/30/2016 11:47 PM, Len Ovens wrote:
On Tue, 30 Aug 2016, Greg wrote:
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-…
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.
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&cm_re=PCI…
For something more expensive that has OHCI in the spec:
http://www.newegg.ca/Product/Product.aspx?Item=N82E16815114048&cm_re=PC…
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-tota…
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
2794
days inactive
3208
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
5 participants
participants (5)
-
Clemens Ladisch -
Greg -
Jeremy Jongepier -
Len Ovens -
OnkelDead