On Thu, 1 Nov 2001, martijn sipkema wrote: > > On Thu, 1 Nov 2001, stef wrote: > > > > > [EMAIL PROTECTED] wrote: > > > > > > > I have an emagic AMT 8 midi patch bay. (Similar to Unitor 8). > > > > > > I have this one, too. Works great with our apple macintosh. > > > > > > > 1) Is anyone working on a driver for this? > > > > > > Don't know. But it would be great. > > > > > > > 2) If not, is there a FAQ on how to approach a manufacturer for > > > > documentation on their hardware for purposes of developing a > > > > driver for them for free? (I should have to beg?) > > > > > > Emagic HQ is about 20 kilometers away from our studio at > > > Hamburg, Germany. Maybe i should visit them. > > > > > > > 3) This is a USB to MIDI device. Is there any support in ALSA for > > > > USB, or do we roll our own support? > > > > > > If you manage to get the protocol documentation, it should be no > > > problem to use the USB lowlevel kernel drivers. The alsa driver > > > would be in fact a usb device driver, which gets loaded by the > > > kernel when you plug in the amt8. > > > > > > As far as i know the AMT8/Unitor devices use hardware timestamping > > > at the inputs and hardware queuing for the outputs. > > > But usually this is alsa's job. So don't know if it's possible > > > to use these hardware features together with alsa. > > > > Take a look at > > > > http://www.math.tu-berlin.de/~sbartels/unitor/ > > > > You'll also find the complete unitor/amt8 documentation there (in german). > > > > I'm too very interested in a working amt8 driver, serial or USB doesn't > > matter to me - as long as it works. > > > > It would be very interesting to see ALSA implementing device-specific > > hardware queuing for multiport MIDI devices - lot's of the "professional" > > ones have it nowadays. With different top-secret protocols of course. > > i don't think the driver is being worked on much. i also have an amt8 > and i have already written a 'driver' for it for beos (serial only). i don't > know how the usb works, i think it uses the same protocol. i mailed > emagic if they would supply me with the amt protocol so the > timestampig and scheduling functions of the device can be used but > they would not give it to me.
Oh, you too =) That makes two of us already. Wonder how many people have asked for it so far. My guess is that AMT is very simple tho, would it be "illegal" to reverse-engineer such a thing? > it will work without it but the timing > won't be as good when using all ports. if using only one port you can > just send a midi stream to the serial port (115200 8data 1stop and no > parity iirc). ports are changed using midi 'cable' messages. > > i am reading 'linux device drivers, 2nd edition' right know because i'm > not an experienced (linux) driver programmer, but i will start on an emagic > midi interface driver and maybe if that's finished they might reconsider > giving the amt protocol specifications. This is good news. It looks like there are potential beta-testers around here too (me included), so feedback won't be a problem. BTW, if you are starting a driver from scratch: please do the serial part of it first - USB on i386 is still too flaky for serious MIDI use (or is that a win32 problem?). > which brings up the alsa drivers. rawmidi doesn't support timestamping > and scheduling right? perhaps this could be added to provide better > support for multiport interfaces, but then again we don't know their > capabilities so designing the right api might be hard. > > anyone comments on this? would something like with sgi's midi api and > openml's UST be good? the ability to sync audio to midi using a single > system wall-clock would be a good thing i think. I know nada about the internals of ALSA midi/rawmidi. I have browsed through the high-level sequencer interface, and to me it seemed that the "correct" place for a hardware queueing implementation would be right below the high-level sequencer API. So events placed in the sequencer queue would be hardware enqueued by the sequencer a bit in advance. Am I totally lost here? -- Manush _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
