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 www.OvenWerks.net _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user