[LAU] Portable/Touch devices Linux friendly

Len Ovens len at ovenwerks.net
Sat Dec 1 16:20:24 UTC 2012

On Sat, December 1, 2012 1:04 am, david wrote:
> On 11/30/2012 06:47 AM, Paul DeShaw wrote:
>> Have you seen the ZaTaB  (http://zareason.com/shop/zatab.html )?  Open
>> bootloader, made for hacking.
> At the moment, I'm not interested in hacking. I'm willing to root
> another vendors product if I need to. ;-)

How easy is it to get things with "micro" USB plugs on them? Taking
adapters everywhere I go sounds like something I don't want to do. Only
two USB ports? Assuming an external Audio IF and a keyboard (or MIDI
IF)... nothing left.

>> I haven't seen one in person.
> I've looked at it, haven't seen one in person. I'm disappointed with the
> low resolution and the weak processor compared to the Kindle Fire HD or
> the Nook HD+ 9 tablets. Both of those tablets can be rooted and have

For Audio, my question is are the USB ports on their own IRQ? On any of
these? In fact we should be writing to the manufactures and asking which
model USB ports on their own irq. (same with PCI(e) slots) Maybe if they
thought it was something people were not buying their stuff because of...
that would be something they look into. The new irq controllers seem to
have way more irqs than are used.

As an example, I have an Acer aspire netbook with 3 USB ports. The left
side port is USB2 and shares its IRQ (16 I think) with lots of things. The
other two plugs are both USB3, but USB3 has it's own IRQ. If I plug my
Audio IF into USB2, forget low latency work... Jack still get xruns once
in a while at -p1024. However, if I plug it into USB3 (on its own) I can
run -p64 without xruns (till I over use the cpu). This is a USB1.1 device,
so it is not asking for much bandwidth... (ART USB Dual Tube Preamp)
However, USB 2.0 might handle this better.

In general, it seems that the computer world (hardware and software) has
decided to maximize throughput at the expense of latency. I was looking at
the spec for PCIe transfer (version 1 - 4) and it seems optimized for
throughput as the version increases. The early versions sent fewer/smaller
packets through for each header and so the header itself was smaller. The
later versions seem to have larger packet sizes, and send more packets
through per header (great for throughput), but the header is now bigger.
In low latency audio work, the idea is to get a small packet of data
rather often but that small packet would be burdened with padding to make
up minimum packet size plus a large header packet to go with it. I am not
sure the the minimum number of packets per header may need to be used as
well (all zeroed out if we don't need them) I have not looked at the USB
specs for transfer to see if there is a similar trend or not.

In the hardware world, there seems to be the idea that sharing irqs is
fine if the buffer size(read latency) for peripherals kept large.

Len Ovens

More information about the Linux-audio-user mailing list