[LAD] Tascam US-16x08 0644:8047
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
Re: [LAD] Tascam US-16x08 0644:8047
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] Polyphonic normal guitar to midi: Jam Origins' MIDI-Guitar
On Tue, Jun 26, 2018 at 04:25:27PM -0400, Tim wrote: "The method consists of a computational model of the human auditory periphery, followed by a periodicity analysis mechanism where fundamental frequencies are iteratively detected and canceled from the mixture signal." Neat. Sounds like the Progressive Interference Cancellation my team patented for CDMA years ago. Hear a signal, reconstruct it based on what you think you heard, subtract the synthesized signal from the input, drop the noise floor. Lather, rinse, repeat. (We got ~3x channel capacity from it in a CDMA context...) Of course, it's a bit easier to reconstruct a CDMA signal than an analog guitar signal, but we'll get there some day. I can't wait! ;) -g ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] MIDI granularity
What Will said. Numbers: For a hypothetical controller and MIDI device that speaks USB 2... USB 2 has a minimum latency of ~.125ms and a bandwidth of 480 Mbps. Note on/off = 3 bytes; 24/480M = .5ms, which we can round to 0. Even on USB 1.1, that's only 24/12M = .002ms. (I ignored any other bits that may have to be transmitted.) It seems like <1ms for a note message is pretty reasonable expectation. In fact, it sure seems like <1ms total for 100 messages might be reasonable. :) I figure most of the meaningful delays will come from the driver and OS scheduling, but I think the hardware is more than capable. cheers, Greg On Thu, Jun 16, 2022 at 10:38:11PM +0200, Fons Adriaensen wrote: On Thu, Jun 16, 2022 at 08:37:49PM +0100, Will Godfrey wrote: Over a hardware DIN port this is of course approx. 1mS, but does anyone know if it's the same over a USB link? Presumably, it would have to be if the source was also sending to the DIN route. Not really, it could be much faster. When the source starts transmitting the first byte on the standard MIDI port, it probably has the complete message (3 bytes for a note on/off) ready. There is no reason why the USB message should be derived from the serial MIDI data. Following on from that, what about the multiport adaptors that have 4 hardware ports going down one USB cable. I would guess that these could be interleaved so that (assuming the 1mS granularity holds) the overall rate is still 1mS with the ports spaced up to 250uS apart. AFAIK, USB transfers are not interleaved at byte level, doing that would create a lot of overhead. So even if you have a note event on all four ports at the same time, that would probably be 4 separate USB transfers, one after the other. Still this could take less than 1 ms, it just depends on the USB data rate. Ciao, -- FA ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
