From: Jonathan W. <jw...@ph...> - 2007-10-21 23:45:12
|
> The 8pre would not switch to interface mode after initially trying to > negotiate interface mode when it's first powered up. I tried running > motutest both before I powered the 8pre up to see what it would report > with nothing on the wire and it did what I thought it would do - reported > there were no MOTU interfaces on the firewire bus. I tried running > motutest at various points while the device was powering up, including the > point where it was trying to negotiate interface vs. converter mode (at > this point, both the INTERFACE and CONVERTER LEDs are lit on the front > panel. After the negotiation is done, only one of them is lit. Ok, obviously the device does some handshaking with the PC at startup and switches to interface mode only if it finds an active MOTU driver on the PC which responds in the way it expects. > I don't know exactly what the 8pre is expecting to see from the host > machine to determine it will go into interface mode, but I'd imagine it > would either require a machine to sniff on the firewire bus as mentioned > on the FFADO user list, or some way to peek into the MOTU firewire driver > process on a Windows machine. The sniffing would be by far the easiest way of doing this. > Would daemonizing motutest possibly help? Almost certainly not. The only thing motutest can do is send stuff we tell it to. The problem here is that we don't know what the 8pre is expecting, so the best we can do is send random data to random ports. The chances of hitting the magic sequence is almost 0 (not to mention the significant risk there is in random probing. Sniffing (as discussed on ffado-user recently) is really the only way forward here. > As a followup to my last email, I looked over the MOTU 8pre docs and they > state very emphatically that the install CD needs to be run before the > 8pre is connected to the machine's firewire port and powered up, so it > would seem that the 8pre is expecting to see a certain response or > sequence of responses from the host machine before it goes into interface > mode. Yes and no. The Traveler documentation states something similar, but in the case of the Traveler there is no concept of "converter" or "interface" mode and there is no magic exchange needed before the PC can control the Traveler. However, based on your previous comment I agree that there is a magic sequence we would need to uncover before we can control this device from FFADO. > This negotiation is only done at power-on, as far as I know. >From what you're reported that appears to be the case. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2007-10-22 00:19:23
|
Here's an attempt at responding to various comments over the weekend. > > The 8pre would not switch to interface mode after initially trying to > > negotiate interface mode when it's first powered up. ... > : > 828mkII and Traveler switch from standalone mode to interface mode when the > stream is started (writing 0xc0c10000 to register 0x0b00). I hope it's the > same for the 8pre. It doesn't sound like it is. It sounds to me like the 8pre sticks in converter mode until the driver tells it otherwise. Unfortunately it seems that this isn't as straight-forward as enabling streaming. The other thing is that the Traveler at least doesn't really have a concept of "converter" and "inferface" modes. Enabling the streaming on the Traveler doesn't really change any other aspect of the device's operation. For the Traveler, enabling streaming mode just enables streaming mode. Nothing else about the device's operation really changes. The 828MkII might be different in this respect - I don't know. The Traveler also doesn't have any LEDs to differentiate the two "modes", which further shows that the device doesn't really care whether it's streaming or not. >From the evidence presented thus far it seems to me that the 8pre operates in a somewhat different way to the 828/Traveler family. > I tried that and motutest would would hang right after it probed the > devices on the firewire bus. I was able to get it to dump some output > once, but unfortunately I didn't buffer the output. > I'll try it again this weekend. The "hang" might have been a wait for iso traffic which never came. > I'll also test on whether the 8pre will switch to interface mode on a > Windows box with the MOTU drivers loaded even after being powered up and > going into converter mode. That would be interesting to know. > > This negotiation is only done at power-on, as far as I know. > A FireWire interface has no way to spontaneously "ask" something to the > host. That's actually not strictly true. Any firewire device can in fact write to any register on any other device. A PC can watch specified registers for incoming writes and respond accordingly - under Linux libraw1394 this is done using the ARM infrastructure. Whether this is what the 8pre is doing I cannot say (I suspect not - see below). My point is that such "reverse" communication is allowed by the firewire spec. > Except for audio stream itself, the only discussion between the host and > the interface can't be anything else than register being read or written > by the host. That's certainly how the 828/Traveler work but it's not something we can assume at this point. Having said that I would be surprised if the interface did write to the PC, but it would not surprise me if the "negotiation" involved the PC writing a specific stream to the device to pop it into interface mode. The only way to resolve this is to sniff the traffic and see. > I imagine that the interface wait for a few seconds (that you call > "negotiation") to let window$ detect the 8pre and run the driver. At this > point the driver will tell the interface to switch to interface mode or the > 8pre will stay in converter mode. I agree, this is what I suspect is happening. > >> I tried that and motutest would would hang right after it probed the > >> devices on the firewire bus. I was able to get it to dump some output > >> once, but unfortunately I didn't buffer the output. > > What do you mean by "hang"? > motutest generated no more output after it listed the devices on the bus. > On occasion it would not exit after hitting ctrl-c. I had to force it to > exit by powering the 8pre off. Hmm, that's interesting. I wouldn't have expected it to hang as such. You are running libraw1394 v1.2.1 or later, aren't you? If not, please ensure you upgrade libraw1394 to at least version 1.2.1 before continuing. Earlier libraw1394 versions had issues with the iso data system which could cause interesting effects. > I tested the 8pre's behavior on a Windows (XP Pro service pack 2) box > today and it will switch from converter to interface mode within 1-2 > seconds of the firewire cable being connected to the PC, even if the 8pre > was first powered on without being connected. Ok, so there's some interaction between the PC and the 8pre which switches the 8pre into what it calls interface mode. I suspect this amounts to a special datastream (of as yet unknown length) being sent to the 8pre. This almost certainly confirms that we'll need to sniff some data to work out what's going on. > Now, the only thing I need is the motutest log. All I require is in that > log. If you don't send me this log, I can't work on the 8pre support. I'm not certain motutest is going to tell us much more than what we already know (short of GUIDs and the like, but I think we already have that info). If the device isn't switched into interface mode then I would not expect it to respond to efforts by motutest to do anything with it (otherwise what's the point of it having an "intereface" mode)? Seriously, I think we're going to have to sniff the 8pre to work out how to drive it. We've just about found out as much as we can with the more passive methods. It seems clear that although similiar in concept it's quite different to the 828/Traveler family of products. Regards jonathan |
From: Francois.ernoult <fra...@pa...> - 2007-10-22 01:11:19
|
> > > The 8pre would not switch to interface mode after initially trying to > > > negotiate interface mode when it's first powered up. ... > > : > > 828mkII and Traveler switch from standalone mode to interface mode when > the > > stream is started (writing 0xc0c10000 to register 0x0b00). I hope it's > the > > same for the 8pre. > > It doesn't sound like it is. It sounds to me like the 8pre sticks in > converter mode until the driver tells it otherwise. Unfortunately it > seems > that this isn't as straight-forward as enabling streaming. Yes, you're right. If I remember well, the Traveler/828mkII switches to "interface" mode by writing to CueMix registers (not enabling the stream). That goes in the same way than my intuition that is the 8pre "converter" mode is a "stand alone" mode with special CueMix setting. Moreover MotU claims on his web site that the CueMix is in charge of mapping Analog_in to ADAT_out in "converter" mode. > > The other thing is that the Traveler at least doesn't really have a > concept > of "converter" and "inferface" modes. Enabling the streaming on the > Traveler doesn't really change any other aspect of the device's operation. > For the Traveler, enabling streaming mode just enables streaming mode. > Nothing else about the device's operation really changes. The 828MkII > might > be different in this respect - I don't know. > > The Traveler also doesn't have any LEDs to differentiate the two "modes", > which further shows that the device doesn't really care whether it's > streaming or not. Note that the 828mkII panel says "Use Computer" for many settings in "interface" mode. We don't really need a led anyway because none of the setting is affected; which is not the case for the 8pre (CueMix reconfiguration). > > From the evidence presented thus far it seems to me that the 8pre operates > in a somewhat different way to the 828/Traveler family. > > > I tried that and motutest would would hang right after it probed the > > devices on the firewire bus. I was able to get it to dump some output > > once, but unfortunately I didn't buffer the output. > > I'll try it again this weekend. > > The "hang" might have been a wait for iso traffic which never came. > > > > This negotiation is only done at power-on, as far as I know. > > A FireWire interface has no way to spontaneously "ask" something to the > > host. > > That's actually not strictly true. Any firewire device can in fact write > to > any register on any other device. A PC can watch specified registers for > incoming writes and respond accordingly - under Linux libraw1394 this is > done using the ARM infrastructure. Whether this is what the 8pre is doing > I > cannot say (I suspect not - see below). My point is that such "reverse" > communication is allowed by the firewire spec. > > > Except for audio stream itself, the only discussion between the host and > > the interface can't be anything else than register being read or written > > by the host. > > That's certainly how the 828/Traveler work but it's not something we can > assume at this point. > > Having said that I would be surprised if the interface did write to the > PC, > but it would not surprise me if the "negotiation" involved the PC writing > a > specific stream to the device to pop it into interface mode. The only way > to resolve this is to sniff the traffic and see. It would be easy to know without sniffing. I think we can read PC registers before and after the 8pre was attached? (Not sure). But I also suspect this is not the way the 8pre communicates with the driver. > > >> I tried that and motutest would would hang right after it probed the > > >> devices on the firewire bus. I was able to get it to dump some > output > > >> once, but unfortunately I didn't buffer the output. > > > What do you mean by "hang"? > > motutest generated no more output after it listed the devices on the > bus. > > On occasion it would not exit after hitting ctrl-c. I had to force it > to > > exit by powering the 8pre off. > > Hmm, that's interesting. I wouldn't have expected it to hang as such. > You > are running libraw1394 v1.2.1 or later, aren't you? If not, please ensure > you upgrade libraw1394 to at least version 1.2.1 before continuing. > Earlier > libraw1394 versions had issues with the iso data system which could cause > interesting effects. The motutest log would have said that... :) > > > I tested the 8pre's behavior on a Windows (XP Pro service pack 2) box > > today and it will switch from converter to interface mode within 1-2 > > seconds of the firewire cable being connected to the PC, even if the > 8pre > > was first powered on without being connected. > > Ok, so there's some interaction between the PC and the 8pre which switches > the 8pre into what it calls interface mode. I suspect this amounts to a > special datastream (of as yet unknown length) being sent to the 8pre. > This > almost certainly confirms that we'll need to sniff some data to work out > what's going on. I still suspect the same mechanism for "stand alone"/"interface" and "converter"/"interface" switch. > > > Now, the only thing I need is the motutest log. All I require is in that > > log. If you don't send me this log, I can't work on the 8pre support. > > I'm not certain motutest is going to tell us much more than what we > already > know (short of GUIDs and the like, but I think we already have that info). > If the device isn't switched into interface mode then I would not expect > it > to respond to efforts by motutest to do anything with it (otherwise what's > the point of it having an "intereface" mode)? We don't know exactly where motutest hangs (writing to register? Which one? Enabling the stream?). We don't know the libraw1394 version. Perhaps there's something evident in it. I just would like to see it, for information. > > Seriously, I think we're going to have to sniff the 8pre to work out how > to > drive it. We've just about found out as much as we can with the more > passive methods. It seems clear that although similiar in concept it's > quite different to the 828/Traveler family of products. > > Regards > jonathan |
From: Jonathan W. <jw...@ph...> - 2007-10-22 01:55:10
|
Hi > > > > The 8pre would not switch to interface mode after initially trying to > > > > negotiate interface mode when it's first powered up. ... > > > : > > > 828mkII and Traveler switch from standalone mode to interface mode > > > when the stream is started (writing 0xc0c10000 to register 0x0b00). I > > > hope it's the same for the 8pre. > > > > It doesn't sound like it is. It sounds to me like the 8pre sticks in > > converter mode until the driver tells it otherwise. Unfortunately it > > seems that this isn't as straight-forward as enabling streaming. > > Yes, you're right. If I remember well, the Traveler/828mkII switches to > "interface" mode by writing to CueMix registers (not enabling the stream). Perhaps we're using different definitions here, but on the Traveler "interface" mode is not activated by writing to CueMix registers. After writing to Cuemix registers the device remains in the same state as it did before except of course for any side effects of the cuemix write. Note that to me a "CueMix register" is a register which controls the on-board matrix mixer and associated controls - send values, output mappings and the like - potentially anything which appears on in the "mixer" GUI of the CueMix application. Other things like sample rate control is IMHO not Cuemix since it doesn't really have anything to do with the on-board Cuemix DSP. > That goes in the same way than my intuition that is the 8pre "converter" > mode is a "stand alone" mode with special CueMix setting. Moreover MotU > claims on his web site that the CueMix is in charge of mapping Analog_in to > ADAT_out in "converter" mode. That would make sense, but I'm still puzzled as to why the 8pre makes such an obvious distinction between these two modes. > > The other thing is that the Traveler at least doesn't really have a > > concept of "converter" and "inferface" modes. Enabling the streaming on > > the Traveler doesn't really change any other aspect of the device's > > operation. For the Traveler, enabling streaming mode just enables > > streaming mode. Nothing else about the device's operation really > > changes. The 828MkII might be different in this respect - I don't know. > > > > The Traveler also doesn't have any LEDs to differentiate the two "modes", > > which further shows that the device doesn't really care whether it's > > streaming or not. > > Note that the 828mkII panel says "Use Computer" for many settings in > "interface" mode. The only setting I get "use computer" for when a computer is connected is the sample rate (and possibly the ADAT modes - I haven't explicitly tested that). Beyond that, the computer's connection has no effect on the Traveler's front panel configuration options. Maybe the 828 is less flexible in this respect. I should also emphasise that the "Use computer" thing only appears *after* one has written to the sample rate control register. Writing just to the cuemix registers (as defined above) does not do it. > We don't really need a led anyway because none of the setting is affected; > which is not the case for the 8pre (CueMix reconfiguration). In terms of the mix values I'm surprised the 8pre is so inflexible when there's a PC attached. Then again, perhaps the "cuemix" system in the 8pre is a cut-down version tailored to the 8pre's situation. > > Having said that I would be surprised if the interface did write to the > > PC, but it would not surprise me if the "negotiation" involved the PC > > writing a specific stream to the device to pop it into interface mode. > > The only way to resolve this is to sniff the traffic and see. > > It would be easy to know without sniffing. In the former scenario yes, it could be done (although it would still be messy - see below). If instead it's done by the PC writing to the MOTU then the only way you can see this traffic is with a sniffer. > I think we can read PC registers before and after the 8pre was attached? > (Not sure). But I also suspect this is not the way the 8pre communicates > with the driver. You could but it might not tell you anything meaningful because you don't know what the PC driver was doing before or indeed right after the interface was attached. It could for instance set the registers to something *after* the device was plugged in and then wait to see if the device changed those. Similarly (for the case where the PC writes to the MOTU), you could do a dump of all the MOTU registers from Linux, plug your bus into a winPC, wait, then dump again and compare. However, this isn't necessary reliable either because the device might not echo the written register values when the same register is re-read (the ieee1394 spec does not require that this be done). In addition, if the "switch" is done by writing a stream to a single register you again won't see the earlier quadlets. > > [motutest hang] > > Hmm, that's interesting. I wouldn't have expected it to hang as such. > > You are running libraw1394 v1.2.1 or later, aren't you? ... > > The motutest log would have said that... :) True. > > > I tested the 8pre's behavior on a Windows (XP Pro service pack 2) box > > > today and it will switch from converter to interface mode within 1-2 > > > seconds of the firewire cable being connected to the PC, even if the > > > 8pre was first powered on without being connected. > > > > Ok, so there's some interaction between the PC and the 8pre which switches > > the 8pre into what it calls interface mode. I suspect this amounts to a > > special datastream (of as yet unknown length) being sent to the 8pre. > > This > > almost certainly confirms that we'll need to sniff some data to work out > > what's going on. > > I still suspect the same mechanism for "stand alone"/"interface" and > "converter"/"interface" switch. If we say the relatively rare "Use computer" condition on the Traveler is "interface" mode, then this should be easy enough to test. As mentioned previously, the "Use computer" thing crops up on the Traveler only after the sample rate register is written to (is it different on the 828?). Therefore if this is indeed the trigger on the 8pre all we need to do is arrange for motutest to write something to the sample rate control register we know about and see if the LED state toggles. So at line 760 of motutest-20071017.c add something like this: motufw_reg_write(motus, 0x0b14, 0x07000008); If this works as expected the device should switch to internally clocked 48kHz. If it also triggers this "interface" mode the LED should toggle as well. If nothing happens all we can say is that this by itself doesn't toggle the 8pre's mode. This is because the failure to respond to this register could be due either to the unit not being in interface mode (and requiring some other sequence to do the switch) or that the clock control register isn't at 0x0b14 in the 8pre. Working out which situation is the reality would require more work. > > > Now, the only thing I need is the motutest log. All I require is in that > > > log. If you don't send me this log, I can't work on the 8pre support. > > > > I'm not certain motutest is going to tell us much more than what we > > already know (short of GUIDs and the like, but I think we already have > > that info). If the device isn't switched into interface mode then I > > would not expect it to respond to efforts by motutest to do anything > > with it (otherwise what's the point of it having an "intereface" mode)? > > We don't know exactly where motutest hangs (writing to register? Which one? > Enabling the stream?). We don't know the libraw1394 version. Perhaps there's > something evident in it. > I just would like to see it, for information. For sure. It would be interesting to know, but at the same time it's unlikely to lift the veil on the mystery. Regards jonathan |
From: Francois.ernoult <fra...@pa...> - 2007-10-22 02:35:52
|
> > > > > The 8pre would not switch to interface mode after initially trying > to > > > > > negotiate interface mode when it's first powered up. ... > > > > : > > > > 828mkII and Traveler switch from standalone mode to interface mode > > > > when the stream is started (writing 0xc0c10000 to register 0x0b00). > I > > > > hope it's the same for the 8pre. > > > > > > It doesn't sound like it is. It sounds to me like the 8pre sticks in > > > converter mode until the driver tells it otherwise. Unfortunately it > > > seems that this isn't as straight-forward as enabling streaming. > > > > Yes, you're right. If I remember well, the Traveler/828mkII switches to > > "interface" mode by writing to CueMix registers (not enabling the > stream). > > Perhaps we're using different definitions here, but on the Traveler > "interface" mode is not activated by writing to CueMix registers. After > writing to Cuemix registers the device remains in the same state as it did > before except of course for any side effects of the cuemix write. You're right, it's definitely too late. The 828mkII changes from "standalone" to "interface" when the Clock Register is set. > > Note that to me a "CueMix register" is a register which controls the > on-board matrix mixer and associated controls - send values, output > mappings > and the like - potentially anything which appears on in the "mixer" GUI of > the CueMix application. Other things like sample rate control is IMHO not > Cuemix since it doesn't really have anything to do with the on-board > Cuemix > DSP. > > > That goes in the same way than my intuition that is the 8pre "converter" > > mode is a "stand alone" mode with special CueMix setting. Moreover MotU > > claims on his web site that the CueMix is in charge of mapping Analog_in > to > > ADAT_out in "converter" mode. > > That would make sense, but I'm still puzzled as to why the 8pre makes such > an obvious distinction between these two modes. "converter" -> no PC; analog->adat "interface" -> stream to/from PC enabled; analog<->CueMix<->adat I think those two modes are different enough to justify two different mode names. > > > > The other thing is that the Traveler at least doesn't really have a > > > concept of "converter" and "inferface" modes. Enabling the streaming > on > > > the Traveler doesn't really change any other aspect of the device's > > > operation. For the Traveler, enabling streaming mode just enables > > > streaming mode. Nothing else about the device's operation really > > > changes. The 828MkII might be different in this respect - I don't > know. > > > > > > The Traveler also doesn't have any LEDs to differentiate the two > "modes", > > > which further shows that the device doesn't really care whether it's > > > streaming or not. > > > > Note that the 828mkII panel says "Use Computer" for many settings in > > "interface" mode. > > The only setting I get "use computer" for when a computer is connected is > the sample rate (and possibly the ADAT modes - I haven't explicitly tested > that). Beyond that, the computer's connection has no effect on the > Traveler's front panel configuration options. Maybe the 828 is less > flexible in this respect. For the 828mkII, Clock source, and ADAT are noted "Use Computer" after FFDO start. The sample rate can be changed using the clock source setting in standalone mode. Out-of-topic: FFADO doesn't restore the "standalone" when it quits; you have to power cycle the interface the go back to a usable "standalone" mode. I thing this point was part of your protocol analysis. > > I should also emphasise that the "Use computer" thing only appears *after* > one has written to the sample rate control register. Writing just to the > cuemix registers (as defined above) does not do it. > > > We don't really need a led anyway because none of the setting is > affected; > > which is not the case for the 8pre (CueMix reconfiguration). > > In terms of the mix values I'm surprised the 8pre is so inflexible when > there's a PC attached. Then again, perhaps the "cuemix" system in the > 8pre > is a cut-down version tailored to the 8pre's situation. The CueMix does work the same as the 828mkII/Traveler when a PC is attached. The hard connections between analog and ADAT out only occur in "converter" mode (without PC attached). > > > > > I tested the 8pre's behavior on a Windows (XP Pro service pack 2) > box > > > > today and it will switch from converter to interface mode within 1-2 > > > > seconds of the firewire cable being connected to the PC, even if the > > > > 8pre was first powered on without being connected. > > > > > > Ok, so there's some interaction between the PC and the 8pre which > switches > > > the 8pre into what it calls interface mode. I suspect this amounts to > a > > > special datastream (of as yet unknown length) being sent to the 8pre. > > > This > > > almost certainly confirms that we'll need to sniff some data to work > out > > > what's going on. > > > > I still suspect the same mechanism for "stand alone"/"interface" and > > "converter"/"interface" switch. > > If we say the relatively rare "Use computer" condition on the Traveler is > "interface" mode, then this should be easy enough to test. As mentioned > previously, the "Use computer" thing crops up on the Traveler only after > the > sample rate register is written to (is it different on the 828?). No, it's the same. > Therefore > if this is indeed the trigger on the 8pre all we need to do is arrange for > motutest to write something to the sample rate control register we know > about and see if the LED state toggles. So at line 760 of > motutest-20071017.c add something like this: > > motufw_reg_write(motus, 0x0b14, 0x07000008); Here we are! The motutest version I sent to Justin does have such a line. The motutest log should say if motutest hangs before or after this line. (Perhaps I have to add some debug print to locate this more accurately in the log). If motutest hangs before this line (for a reason still unknown) it's probably why nothing happen on the 8pre. > > If this works as expected the device should switch to internally clocked > 48kHz. If it also triggers this "interface" mode the LED should toggle as > well. Yes. If not, we will need a sniffer. And a don't have clear information about that a this time. > > If nothing happens all we can say is that this by itself doesn't toggle > the > 8pre's mode. This is because the failure to respond to this register > could > be due either to the unit not being in interface mode (and requiring some > other sequence to do the switch) or that the clock control register isn't > at > 0x0b14 in the 8pre. Working out which situation is the reality would > require more work. I'm agree. > > > > > Now, the only thing I need is the motutest log. All I require is in > that > > > > log. If you don't send me this log, I can't work on the 8pre > support. > > > > > > I'm not certain motutest is going to tell us much more than what we > > > already know (short of GUIDs and the like, but I think we already have > > > that info). If the device isn't switched into interface mode then I > > > would not expect it to respond to efforts by motutest to do anything > > > with it (otherwise what's the point of it having an "intereface" > mode)? > > > > We don't know exactly where motutest hangs (writing to register? Which > one? > > Enabling the stream?). We don't know the libraw1394 version. Perhaps > there's > > something evident in it. > > I just would like to see it, for information. > > For sure. It would be interesting to know, but at the same time it's > unlikely to lift the veil on the mystery. Regards, Francois |
From: Jonathan W. <jw...@ph...> - 2007-10-22 03:59:02
|
Hi Francois > > > Yes, you're right. If I remember well, the Traveler/828mkII switches to > > > "interface" mode by writing to CueMix registers (not enabling the > > > stream). > > > > Perhaps we're using different definitions here, but on the Traveler > > "interface" mode is not activated by writing to CueMix registers. After > > writing to Cuemix registers the device remains in the same state as it did > > before except of course for any side effects of the cuemix write. > > You're right, it's definitely too late. :-) I would imagine so - it's now after 1pm over here. > The 828mkII changes from "standalone" to "interface" when the Clock > Register is set. Thanks for confirming. > > > That goes in the same way than my intuition that is the 8pre "converter" > > > mode is a "stand alone" mode with special CueMix setting. Moreover MotU > > > claims on his web site that the CueMix is in charge of mapping Analog_in to > > > ADAT_out in "converter" mode. > > > > That would make sense, but I'm still puzzled as to why the 8pre makes such > > an obvious distinction between these two modes. > > "converter" -> no PC; analog->adat > "interface" -> stream to/from PC enabled; analog<->CueMix<->adat > > I think those two modes are different enough to justify two different mode > names. On the 8pre, certainly. However (as per my previous email), the Traveler/828 has no equivalent to the special "analog->adat" mode automatically selected by the 8pre when the PC is unplugged. This would be the major difference between these interfaces. > > > Note that the 828mkII panel says "Use Computer" for many settings in > > > "interface" mode. > > > > The only setting I get "use computer" for when a computer is connected is > > the sample rate (and possibly the ADAT modes - I haven't explicitly tested > > that). Beyond that, the computer's connection has no effect on the > > Traveler's front panel configuration options. Maybe the 828 is less > > flexible in this respect. > > For the 828mkII, Clock source, and ADAT are noted "Use Computer" after FFDO > start. The sample rate can be changed using the clock source setting in > standalone mode. That sounds much like the Traveler to me. > Out-of-topic: FFADO doesn't restore the "standalone" when it quits; you have > to power cycle the interface the go back to a usable "standalone" mode. > I thing this point was part of your protocol analysis. That's true - currently it does not. In addition to power cycling I *think* unplugging the firewire cable works to restore the configurability of the clock source for me though - I have to check. In any case I seem to recall looking into this briefly and not coming up with an adequate solution. It's been a while ago, but I seem to recall that the same thing happened under windoze - once the device was plugged in it was not possible to set the clock details until you unplugged the interface. For that reason I concluded that there many not be any sequence FFADO can send to do restore this - there possibly isn't anything like this implemented because it's "not needed" under windoze. A forced bus reset might do it, but that seems a bit extreme. > > In terms of the mix values I'm surprised the 8pre is so inflexible when > > there's a PC attached. Then again, perhaps the "cuemix" system in the > > 8pre is a cut-down version tailored to the 8pre's situation. > > The CueMix does work the same as the 828mkII/Traveler when a PC is attached. > The hard connections between analog and ADAT out only occur in "converter" > mode (without PC attached). Right - that's the major difference between the interface behaviours and explains why the mode LED is present on the 8pre. > > Therefore if this is indeed the trigger on the 8pre all we need to do is > > arrange for motutest to write something to the sample rate control > > register we know about and see if the LED state toggles. So at line 760 > > of motutest-20071017.c add something like this: > > > > motufw_reg_write(motus, 0x0b14, 0x07000008); > > Here we are! > The motutest version I sent to Justin does have such a line. The motutest > log should say if motutest hangs before or after this line. (Perhaps I have > to add some debug print to locate this more accurately in the log). > If motutest hangs before this line (for a reason still unknown) it's > probably why nothing happen on the 8pre. I can honestly not see why motutest would hang at any point unless there's a buggy library or kernel in use, there's a problem on the firewire bus itself or the firewire card itself is acting strangely. Perhaps there's scope for an apparent hang in the iso part of the code, but even then there's nothing there which isn't interruptible. It's all rather strange. It might we worthwhile to find out what kernel version Justin is using and whether he's using RT-preempt. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2007-10-22 23:36:04
|
> Here is what motutest generated. As the log notes, I'm running libraw1394 > 1.3.0. Good - that rules out any libraw1394-related oddities. > I'm not sure if motutest is leaving something in an unhappy state, but I > can reproduce the issue reliably. The first run of motutest after a > reboot produces output similar to the first logfile. Subsequent runs look > like the second logfile. What if you power-cycle the 8pre - does that then allow a subsequent motutest run to find the 8pre once more? I would expect so. > Using first MOTU fw audio interface found: port 0 node 0 > Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 > Write 0xff004000 to reg 0x4000): 0 > Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 This tends to indicate that the cuemix control registers are similar on the 8pre to the other interfaces. This is a good thing. > Starting iso send test. Note: code currently assumes MOTU is set to 48 kHz with ADAT on. > Other settings may result in suboptimal (or no) output. > id=0xff: 0xf8 (was 0xd2) > id=0x00: 0x00 (was 0x40) > id=0x00: 0x5d (was 0x00) : Interesting. The code which outputs this is looking at the part of the received stream which communicates Cuemix settings back to the PC, which in turn allows the PC to reamin in sync with the device if the front panel is used to change cuemix settings while the PC's Cuemix application is active. There's quite a number of changes being reported here even though (presumedly) no changes were being made via the front panel, and the IDs being reported bear no relation to those observed on the Traveler. This leads me to believe that the streaming format from the 8pre might be slightly different to the Traveler/828. The good news here is that the presence of the "id=" lines shows that some iso data was coming from the device, which means we were at least able to start the streaming system. > stop > Error doing motu write to register 0x000b00 Register 0x000b00 is the iso control register. The fact it couldn't be written means the iso streaming couldn't be stopped at this point, which in turn leads me to believe that the interface is actually unreachable at this point in time. This assumes that the additional register writes in main() aren't active in the motutest version used for this test. > -------------- next part -------------- > libraw1394 version is 1.3.0 > Running with RT scheduling, priority=50 > : > No MOTU firewire audio interfaces found No real surprises here - since the iso control register (and presumedly all others) couldn't be written to at the end of the previous run of motutest this is kind of expected. >From this I conclude that it isn't actually the second run of motutest which causes the problem - I think the problem crops up during the first run, probably when we enable iso streaming. From that point on, for whatever reason, the device no longer accepts incoming register writes and therefore appears invisible on the bus. As to what causes this, I have no idea. My money is on the iso control register though - I suspect that maybe there are some additional bits in there on the 8pre which need to be set appropriately. If this is true and we're not doing that it possibly explains the symptoms we're seeing. > Ok, it seems everything works fine until the stream is supposed to stop. > There's many unneeded writes to register 0x000b00 so it's difficult to say > which one is the cause of the error (last line of the first log). There are only additional writes to register 0x0b00 if the ifdef'ed lines in main() have been commented out. Were these commented out in the version you got Justin to run? If not, it might be instructive to revert to motutest-20071017.c on my site and test with that. This has only one write to 0x0b00 to shut down the streaming and should provide a definitive answer on this point. Actually, I would recommend that you leave the additional writes inactive during these tests. They are only present to assist me in confirming some of the more obscure aspects of the protocol and aren't needed for the purposes that motutest exists for. If active, they also make it difficult to work out the precise point of failure. > What's happening on the second log is not a motutest hang. The 8pre seems to > be in a blocked state and doesn't answer to anything. So motutest can't > access to it at all. Agreed. I suspect however that the lockup occurs during the first motutest run. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2007-10-22 23:52:23
|
Earlier I wrote: > > Ok, it seems everything works fine until the stream is supposed to stop. > > There's many unneeded writes to register 0x000b00 so it's difficult to say > > which one is the cause of the error (last line of the first log). > > There are only additional writes to register 0x0b00 if the ifdef'ed lines in > main() have been commented out. Were these commented out in the version you > got Justin to run? I've just checked the source that you emailed to Justin and the ifdefs are still active. Therefore I can't quite work out where all these "unneeded writes to register 0x000b00" are. As far as I can tell the only active write to 0x0b00 after streaming is started is motufw_reg_write(motus, 0x0b00, 0x80810000); under the final ifdef block, which is designed to stop the streaming. Since this returns an error (after seemingly working fine in order to start the streaming earlier) I would say that the device stops responding on the firewire bus at the point we use 0x0b00 to enable streaming. Regards jonathan |
From: Francois.ernoult <fra...@pa...> - 2007-10-23 01:26:40
|
> > > Ok, it seems everything works fine until the stream is supposed to > stop. > > > There's many unneeded writes to register 0x000b00 so it's difficult to > say > > > which one is the cause of the error (last line of the first log). > > > > There are only additional writes to register 0x0b00 if the ifdef'ed > lines in > > main() have been commented out. Were these commented out in the version > you > > got Justin to run? I asked to Justin to disable #ifdef lines a few mails ago. Just to be sure all vital registers are writable. > > I've just checked the source that you emailed to Justin and the ifdefs are > still active. Therefore I can't quite work out where all these "unneeded > writes to register 0x000b00" are. As far as I can tell the only active > write to 0x0b00 after streaming is started is > > motufw_reg_write(motus, 0x0b00, 0x80810000); > > under the final ifdef block, which is designed to stop the streaming. > Since > this returns an error (after seemingly working fine in order to start the > streaming earlier) I would say that the device stops responding on the > firewire bus at the point we use 0x0b00 to enable streaming. > Regards, Francois |
From: Jonathan W. <jw...@ph...> - 2007-10-23 02:19:57
|
Hi Francois > > > > Ok, it seems everything works fine until the stream is supposed to stop. > > > > There's many unneeded writes to register 0x000b00 so it's difficult to say > > > > which one is the cause of the error (last line of the first log). > > > > > > There are only additional writes to register 0x0b00 if the ifdef'ed lines in > > > main() have been commented out. Were these commented out in the version you > > > got Justin to run? > > I asked to Justin to disable #ifdef lines a few mails ago. Just to be sure > all vital registers are writable. That's actually quite interesting in itself - that means that of all the register writes which were attempted, only one 0x0b00 attempt failed. That's strange. It would be interesting to see what happens when he runs an unmodified motutest 20071022 or 20071023 since that has only one 0x0b00 write request. Alternatively, the problematic 0x0b00 write could be identified by interleaving each register write with an fprintf(). When coupled with the report that a Linux reboot was necessary to clear the problem the picture becomes rather cloudy. Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-10-23 02:22:52
|
Here is some information on the test machine: Dell Latitude D820/1 GB RAM/80 GB HDD built-in 4-wire Firewire port While I have an RME Hammerfall DSP cardbus interface and kernel drivers loaded for it, the card is not installed at the time, so that /shouldn't/ be muddying up the test results. That driver is snd_hdsp and friends in the lsmod log below. reverb ~ # uname -a Linux reverb 2.6.21-gentoo-r4 #1 SMP PREEMPT Sun Aug 5 17:42:09 EDT 2007 i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux I built this kernel when I was first tinkering with the latest FFADO SVN build trying to see if I could get the 8pre working. reverb ~ # lsmod Module Size Used by snd_pcm_oss 40352 0 snd_mixer_oss 16640 1 snd_pcm_oss snd_seq_oss 30336 0 snd_seq_midi_event 7936 1 snd_seq_oss snd_seq 46768 4 snd_seq_oss,snd_seq_midi_event raw1394 27900 0 snd_hdsp 47140 0 snd_rawmidi 23584 1 snd_hdsp snd_seq_device 7816 2 snd_seq_oss,snd_rawmidi snd_hwdep 9860 1 snd_hdsp tg3 99588 0 nvidia 7246068 26 ohci1394 33712 0 ipw3945 192420 1 snd_hda_intel 21272 0 snd_hda_codec 198912 1 snd_hda_intel snd_pcm 72196 4 snd_pcm_oss,snd_hdsp,snd_hda_intel,snd_hda_codec snd_timer 21764 2 snd_seq,snd_pcm snd 49252 12 snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_seq,snd_hdsp,snd_rawmidi,snd_seq_device,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer soundcore 8800 1 snd snd_page_alloc 10632 3 snd_hdsp,snd_hda_intel,snd_pcm These are the ieee1394 related settings from the kernel config. I took a quick peek in the ieee1394 kernel driver source tree and didn't see any references to juju or any other than Linux IEEE1394 drivers. A very quick look in the Gentoo forums didn't turn up any more information either, but I can look further into it if you want. reverb ~ # grep 1394 /usr/src/linux/.config # IEEE 1394 (FireWire) support CONFIG_IEEE1394=y # CONFIG_IEEE1394_VERBOSEDEBUG is not set # CONFIG_IEEE1394_EXTRA_CONFIG_ROMS is not set # CONFIG_IEEE1394_PCILYNX is not set CONFIG_IEEE1394_OHCI1394=m # CONFIG_IEEE1394_VIDEO1394 is not set # CONFIG_IEEE1394_SBP2 is not set # CONFIG_IEEE1394_ETH1394 is not set # CONFIG_IEEE1394_DV1394 is not set CONFIG_IEEE1394_RAWIO=m I did see some interesting notes from dmesg: ohci1394: fw-host0: Runaway loop while stopping context: ... ohci1394: fw-host0: isochronous cycle too long ieee1394: Node changed: 0-01:1023 -> 0-00:1023 ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0001f2000007e919] |
From: Jonathan W. <jw...@ph...> - 2007-10-23 02:46:40
|
Hi Justin > While I have an RME Hammerfall DSP cardbus interface and kernel drivers > loaded for it, the card is not installed at the time, so that /shouldn't/ > be muddying up the test results. Agreed. At some point it might be worth trying the motutest thing without the RME drivers loaded but I doubt they're in any way implicated. > reverb ~ # uname -a > Linux reverb 2.6.21-gentoo-r4 #1 SMP PREEMPT Sun Aug 5 17:42:09 EDT 2007 > i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux Ok, 2.6.21. That should be fine. About the only significant difference to my test setup is that you have SMP (my machine isn't dual-core). Again though I doubt that would be an issue - it hasn't been for others. > I built this kernel when I was first tinkering with the latest FFADO SVN > build trying to see if I could get the 8pre working. > > reverb ~ # lsmod > Module Size Used by > : > raw1394 27900 0 > : > ohci1394 33712 0 Ok, they're definitely the older firewire modules. That effectively strikes the new Juju stack from the list of suspects (and I don't think juju was in the Gentoo 2.6.21 kernel anyway - I think it was merged upstream in 2.6.22). > I did see some interesting notes from dmesg: > ohci1394: fw-host0: Runaway loop while stopping context: ... > ohci1394: fw-host0: isochronous cycle too long Hmm, this *is* interesting. Something is certainly not working correctly here. It shouldn't be capable of rendering the firewire stack inoperable so maybe there's a bug there. Even so, these should not be occurring. I will have to look in the kernel source to see what "Runaway loop while stopping context" actually means. Out of interest, do the "..." appear literally in the message, or is there something else displayed which you've omitted for brevity? If the latter could you tell me what the "..." was? The "isochronous cycle too long" could also mean a number of things. Perhaps the callback isn't finishing in time so data isn't being delivered when it should. Maybe for some reason too much data is being sent (although the data length sent by motutest is hard-wired so it's hard to see how that could be it). I'll ponder this, but it's definitely a clue. > ieee1394: Node changed: 0-01:1023 -> 0-00:1023 > ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0001f2000007e919] These are normal when a device is pulled out or shut off. Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-10-23 03:39:18
Attachments:
motutest-20071023.log
|
On Tue, 23 Oct 2007, Jonathan Woithe wrote: Ok, I've run motutest-20071023 and made some very interesting observations. The logfile is attached - it has two separate runs of the new motutest, one eith the 8pre manually set to 48k and one with the 8pre set to 44.1k and letting motutest reset to 48k. 1. The 'hang' problem I noted before appears to be related to the ohci1394 kernel module. Unloading and reloading that module allows me to run motutest successfully. At least I don't have to reboot every time now :) 2. Running motutest puts the 8pre into interface mode (a good sign). motutest-20071017 did not do this - I double checked. It remains in interface mode until the ohci1394 module is unloaded. 3. The new motutest also sets the 8pre to 48k even if it was manually set to something else before. It remains set to 48k even if the 8pre is power cycled, so it looks like motutest-20071023 is able to successfully write to that particular register. 4. I did not hear any test tone output on the headphone jack, or the Mix L/R jacks. There are no other 1/4" outputs on the unit. jms >> While I have an RME Hammerfall DSP cardbus interface and kernel drivers >> loaded for it, the card is not installed at the time, so that /shouldn't/ >> be muddying up the test results. > > Agreed. At some point it might be worth trying the motutest thing without > the RME drivers loaded but I doubt they're in any way implicated. Done. >> reverb ~ # uname -a >> Linux reverb 2.6.21-gentoo-r4 #1 SMP PREEMPT Sun Aug 5 17:42:09 EDT 2007 >> i686 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz GenuineIntel GNU/Linux > > Ok, 2.6.21. That should be fine. About the only significant difference to > my test setup is that you have SMP (my machine isn't dual-core). Again > though I doubt that would be an issue - it hasn't been for others. > >> I built this kernel when I was first tinkering with the latest FFADO SVN >> build trying to see if I could get the 8pre working. >> >> reverb ~ # lsmod >> Module Size Used by >> : >> raw1394 27900 0 >> : >> ohci1394 33712 0 > > Ok, they're definitely the older firewire modules. That effectively strikes > the new Juju stack from the list of suspects (and I don't think juju was in > the Gentoo 2.6.21 kernel anyway - I think it was merged upstream in 2.6.22). > >> I did see some interesting notes from dmesg: >> ohci1394: fw-host0: Runaway loop while stopping context: ... >> ohci1394: fw-host0: isochronous cycle too long > > Hmm, this *is* interesting. Something is certainly not working correctly > here. It shouldn't be capable of rendering the firewire stack inoperable > so maybe there's a bug there. Even so, these should not be occurring. > > I will have to look in the kernel source to see what "Runaway loop while > stopping context" actually means. Out of interest, do the "..." appear > literally in the message, or is there something else displayed which you've > omitted for brevity? If the latter could you tell me what the "..." was? The "..." was how it appeared in dmesg. All I did was chop out the duplicate lines, but I kept them in the order that dmesg listed them. jms > The "isochronous cycle too long" could also mean a number of things. > Perhaps the callback isn't finishing in time so data isn't being delivered > when it should. Maybe for some reason too much data is being sent (although > the data length sent by motutest is hard-wired so it's hard to see how that > could be it). I'll ponder this, but it's definitely a clue. |
From: Jonathan W. <jw...@ph...> - 2007-10-23 04:44:13
|
Hi Justin > Ok, I've run motutest-20071023 and made some very interesting > observations. The logfile is attached - it has two separate runs of the > new motutest, one eith the 8pre manually set to 48k and one with the 8pre > set to 44.1k and letting motutest reset to 48k. > > 1. The 'hang' problem I noted before appears to be related to the ohci1394 > kernel module. Unloading and reloading that module allows me to run > motutest successfully. At least I don't have to reboot every time now :) Ok, that's progress. Motutest is obviously doing something which is upsetting the kernel's firewire stack. This is almost certainly related to the error messages you noted in the dmesg output and indicates that there is some issue with the iso data stream being sent to the device. > 2. Running motutest puts the 8pre into interface mode (a good sign). > motutest-20071017 did not do this - I double checked. It remains in > interface mode until the ohci1394 module is unloaded. Right, progress at last. v20071017 did not explicitly write anything to the clock control register whereas v20071023 does. Therefore Francois' thought that the clock control register write triggers interface mode is correct. Some of the previous results are a little hard to reconcile with this, but perhaps the activation of some of the extra register writes along the way confused things somewhat. In any case this is a positive outcome. > 3. The new motutest also sets the 8pre to 48k even if it was manually set > to something else before. It remains set to 48k even if the 8pre is power > cycled, so it looks like motutest-20071023 is able to successfully write > to that particular register. Yep, that's good news too. At least that register isn't dramatically different on the 8pre. > 4. I did not hear any test tone output on the headphone jack, or the Mix > L/R jacks. There are no other 1/4" outputs on the unit. Given that the dmesg output indicates that there is an iso data streaming problem I'm not all that surprised by this outcome. > >> I did see some interesting notes from dmesg: > >> ohci1394: fw-host0: Runaway loop while stopping context: ... > >> ohci1394: fw-host0: isochronous cycle too long > > > > Hmm, this *is* interesting. Something is certainly not working correctly > > here. It shouldn't be capable of rendering the firewire stack inoperable > > so maybe there's a bug there. Even so, these should not be occurring. > > > > I will have to look in the kernel source to see what "Runaway loop while > > stopping context" actually means. Out of interest, do the "..." appear > > literally in the message, or is there something else displayed which you've > > omitted for brevity? If the latter could you tell me what the "..." was? > > The "..." was how it appeared in dmesg. All I did was chop out the > duplicate lines, but I kept them in the order that dmesg listed them. Ok, that's fine. It would seem the kernel guys were going to add something and then never got around to it. Oh well. > Observations: > 2. Unit went back to converter mode after I unloaded the ohci1394 > kernel module I'd expect that - removal of the module triggers a bus reset and the MOTU will take the opportunity to return to converter mode. That all makes sense. > 3. On a subsequent (see the second motutest-20071023 run in this logfile) > run I manually set the 8pre to 44.1k, left it powered on, unloaded > then reloaded the ohci1394 kernel driver, and re-ran > motutest-20071023. The unit went into interface mode and the > clock rate reset to 48k. The clock rate remained at 48k after > exiting motutest-20071023 as well as after unloading the ohci1394 > kernel module. This is good too - it confirms we can drive the clock selector. > [ First motutest-20071023 run ] > : > Using first MOTU fw audio interface found: port 0 node 0 > Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 > Write 0xff004000 to reg 0x4000): 0 > Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 > Starting iso streaming tests. > Note: code tries to set MOTU to 48 kHz and assumes ADAT is on. > If the frequency setting doesn't work and/or ADAT is not enabled, > operation of the iso test may not be as expected. > Setting clock to internal 48kHz... > Enabling iso streaming... > Error doing motu write to register 0x000b00 Hmm, here we have an error when we try to enable streaming. Despite this it would seem that streaming does in fact get started. Curious. Maybe it starts as soon as interface mode is activated. > Started > id=0xff: 0xe9 (was 0x61) > id=0x00: 0x49 (was 0x00) > : > id=0x00: 0x00 (was 0x40) > id=0x00: 0x5f (was 0x00) I think we can conclude that streaming has started. However, it seems likely that the streaming format used by the 8pre is slightly different to the other MOTUs. It's a minor detail we can deal with later on. > stop > Error doing motu write to register 0x000b00 Here again we are unable to write to the stream control register. Since it failed the first time it's really no surprise it fails again. > [ Second motutest-20071023 run ] > : > Using first MOTU fw audio interface found: port 0 node 0 > Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 > Write 0xff004000 to reg 0x4000): 0 > Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 > Starting iso streaming tests. > Note: code tries to set MOTU to 48 kHz and assumes ADAT is on. > If the frequency setting doesn't work and/or ADAT is not enabled, > operation of the iso test may not be as expected. > Setting clock to internal 48kHz... > Enabling iso streaming... > Started > id=0x00: 0x02 (was 0x00) > : Interestingly enough there was no error reported when writing to the iso control register when starting things going this time around. > stop > Error doing motu write to register 0x000b00 Despite no error before we have an error when trying to stop things. It seems that there might be slightly more to the iso control on this device. Could you try one more test procedure for me. Take the source of motutest-20071023 and apply the following patch. --- motutest-20071023.c 2007-10-23 10:13:22.000000000 +0930 +++ motutest-hack.c 2007-10-23 13:56:38.000000000 +0930 @@ -809,8 +809,19 @@ //printf("Write reg 0x0b14: %d\n", // motufw_reg_write(motus, 0x0b14, 0x04000008)); -//free(motus); -//return 0; +fprintf(stderr,"Setting clock to internal 48kHz...\n"); +motufw_reg_write(motus, 0x0b14, 0x07000008); +fprintf(stderr,"Enabling iso streaming...\n"); +motufw_reg_write(motus, 0x0b00, 0xc0c10000); +fprintf(stderr,"Started\n"); + +usleep(100000); + +fprintf(stderr,"stop\n"); +motufw_reg_write(motus, 0x0b00, 0x80810000); + +free(motus); +return 0; /* Now let's mess around trying to send data to the MOTU */ This will try to instruct the MOTU to start streaming, wait 0.1 seconds without doing anything with the streaming data, then try to stop the streaming again. Run this from a known good state - that is, after reloading the firewire modules or following a reboot. I'd be interested to see the result. After this, try running the program again (after resetting things as needed), but before doing so, run dumpiso (from libraw1394) in another terminal window and redirect its output to a file (which will get rather large): dumpiso > somefile.log When the modified motutest finishes put this up on a webpage or something and I'll grab it. This will help me work out the streaming format used by the 8pre and confirm what packet sizes are actually expected by the 8pre. Well done - we're getting there, albeit very slowly. :-) Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-10-24 03:07:27
|
On Tue, 23 Oct 2007, Jonathan Woithe wrote: > This will try to instruct the MOTU to start streaming, wait 0.1 seconds > without doing anything with the streaming data, then try to stop the > streaming again. Run this from a known good state - that is, after > reloading the firewire modules or following a reboot. I'd be interested to > see the result. You can grab it from http://www.cluebyfour.org/downloads/motu/dumpiso-20071023-r1.log.bz2 It's only about 9 kB compressed. Let me know if you have any issues downloading it. Thanks jms |
From: Jonathan W. <jw...@ph...> - 2007-10-24 03:31:21
|
Hi Justin > > This will try to instruct the MOTU to start streaming, wait 0.1 seconds > > without doing anything with the streaming data, then try to stop the > > streaming again. Run this from a known good state - that is, after > > reloading the firewire modules or following a reboot. I'd be interested to > > see the result. > > You can grab it from > http://www.cluebyfour.org/downloads/motu/dumpiso-20071023-r1.log.bz2 > > It's only about 9 kB compressed. Let me know if you have any issues > downloading it. I've got it - thanks. It's rather interesting; it does appear that the 8pre's iso format is different to that of the other interfaces. More on this after I've had a chance to digest it fully. With the modified motutest that you used to do this, did you have to reset the Linux firewire system before running it again, or were you able to run it multiple times in a row without a problem? Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-10-24 04:11:09
|
On Wed, 24 Oct 2007, Jonathan Woithe wrote: > I've got it - thanks. It's rather interesting; it does appear that the > 8pre's iso format is different to that of the other interfaces. More on > this after I've had a chance to digest it fully. > > With the modified motutest that you used to do this, did you have to reset > the Linux firewire system before running it again, or were you able to run > it multiple times in a row without a problem? The output I got directly from motutest this time around was a lot less verbose. This is what I got from when I generated the dumpiso log. The last line about register 0x000b00 came back immediately. I did not need to break out of motutest with a Ctrl-c or power off the 8pre. reverb tmp # ./motutest-20071023-r1 libraw1394 version is 1.3.0 Running with RT scheduling, priority=50 ieee1394 device successfully opened Found 1 port(s) Port 0: Number of nodes: 2 Port name: ohci1394 port 0 node 0: Bus info block length: 4 port 0 node 0: unit directory length is 3 quadlets Port 0 node 0: vendor ID: 0x000001f2 model ID: 0x00100800 GUID: 0x000000000007e919 sw version: 0x0000000f -> found MOTU 8Pre at port 0 node 0 port 0 node 1: Bus info block length: 4 Port 0 node 1: vendor ID: 0x00324fc0 model ID: 0x00000000 GUID: 0x00000000273a1161 sw version: 0x00000000 Using first MOTU fw audio interface found: port 0 node 0 Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 Write 0xff004000 to reg 0x4000): 0 Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 Setting clock to internal 48kHz... Enabling iso streaming... Started stop Error doing motu write to register 0x000b00 |
From: Jonathan W. <jw...@ph...> - 2007-10-24 04:15:36
|
Hi Justin > > With the modified motutest that you used to do this, did you have to reset > > the Linux firewire system before running it again, or were you able to run > > it multiple times in a row without a problem? > > The output I got directly from motutest this time around was a lot less > verbose. I would expect so, because part of the changes disabled motutest's iso data handlers. It basically started the iso streaming, waited for about 0.1 second and then attempted to stop it. > This is what I got from when I generated the dumpiso log. The last line > about register 0x000b00 came back immediately. I did not need to break > out of motutest with a Ctrl-c or power off the 8pre. That makes sense - it only waited 0.1 seconds after enabling the streaming so it would seem to finish up straight away. > Setting clock to internal 48kHz... > Enabling iso streaming... > Started > stop > Error doing motu write to register 0x000b00 Hmm, we still get an error when trying to stop the streaming. Interesting. I shall away answers to the questions in my other email before trying to conclude anything from this though. Regards jonathan |
From: Jonathan W. <jw...@ph...> - 2007-10-24 03:51:33
|
Hi again More on the iso data format from the 8pre. It seems the basic format has been preserved from the earlier interfaces. That is, a typical iso packet contains: ISO packet header (2 quadlets = 8 bytes) A CIP-like header (2 quadlets) The MOTU data (length determined by device configuration) At 1x rate (48 kHz) an iso data packet contains 8 "events", where each event consists of a timestamp, one sample from each of the active channels along with 6 bytes of extra information. Each channel is returned as a packed 24 bit number. With the test you did there were 18 active channels. Thus the total size of the MOTU data is expected to be 8 * [ 4 (timestamp) + 6 (extra data) + 18*3 ] = 512 bytes Adding the CIP header onto this we get an iso data block size of 520 bytes. This theory agrees with the iso data size being seen in the stream you sent. All this is good news. The difference between the 8pre's iso streaming format and that of the 828/Traveler would therefore appear to be confined to those extra 6 information bytes I mentioned. In the 828/Traveler this is where MIDI data is sent, along with Cuemix settings which might have been changed on the front panel (this is how the cuemix application keeps in sync with front panel changes). Based on output from motutest yesterday it seems that the way all this information is packed into these 6 bytes is slightly different. Motutest watches the cuemix update bytes and reports when they change. On the Traveler we don't see changes logged if nothing is done on the front panel. However, if the same format is applied to the 8pre stream there are some apparent control changes happening (as noted by the "id=" lines) when in fact things are static. I don't consider this to be bad though. Working this side of things out will probably not be too taxing once we're in a position to do so. The basic format of the iso data has now been verified to match that of the other interfaces, and this will ultimately make things easier. For now we've just got to work on deducing the correct way to control this beast. To that end, I have a few questions about the outcome of the motutest runs you did for me. 1) Did streaming stop after the modified motutest program finished? You can use dumpiso after motutest exits to verify this. 2) Did the modified motutest program report any errors when writing to registers? 3) Could you run the modified motutest again without having to first reset the PC or reinsert the ieee1394 kernel module? Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-10-24 04:21:24
|
On Wed, 24 Oct 2007, Jonathan Woithe wrote: > To that end, I have a few questions about the outcome of the motutest runs > you did for me. > > 1) Did streaming stop after the modified motutest program finished? You > can use dumpiso after motutest exits to verify this. I hate to say it, but I'm not sure. The output of dumpiso was not human-readable, so I couldn't really make any sense out of it :) > 2) Did the modified motutest program report any errors when writing to > registers? It did. I sent the output from the patched motutest-20071023 run in my last email. The errors were on writing to register 0x000b00 as before. > 3) Could you run the modified motutest again without having to first > reset the PC or reinsert the ieee1394 kernel module? I was able to get it to re-run once successfully (I'm guessing, since motutest's output is now less verbose), but subsequent runs without unloading and reloading the ohci1394 module produced this output: reverb tmp # ./motutest-20071023-r1 libraw1394 version is 1.3.0 Running with RT scheduling, priority=50 ieee1394 device successfully opened Found 1 port(s) Port 0: Number of nodes: 2 Port name: ohci1394 port 0 node 0: Bus info block length: 4 port 0 node 0: unit directory length is 3 quadlets Port 0 node 0: vendor ID: 0x000001f2 model ID: 0x00100800 GUID: 0x000000000007e919 sw version: 0x0000000f -> found MOTU 8Pre at port 0 node 0 port 0 node 1: Bus info block length: 4 Port 0 node 1: vendor ID: 0x00324fc0 model ID: 0x00000000 GUID: 0x00000000273a1161 sw version: 0x00000000 Using first MOTU fw audio interface found: port 0 node 0 Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 Write 0xff004000 to reg 0x4000): 0 Read reg 0x4000 (mix 1 analog 1 mix controls): 0xff004000 Setting clock to internal 48kHz... Enabling iso streaming... Error doing motu write to register 0x000b00 Started stop Error doing motu write to register 0x000b00 reverb tmp # ./motutest-20071023-r1 libraw1394 version is 1.3.0 Running with RT scheduling, priority=50 ieee1394 device successfully opened Found 1 port(s) Port 0: Number of nodes: 0 Port name: ohci1394 No MOTU firewire audio interfaces found reverb tmp # ./motutest-20071023-r1 libraw1394 version is 1.3.0 Running with RT scheduling, priority=50 ieee1394 device successfully opened Found 1 port(s) Port 0: Number of nodes: 2 Port name: ohci1394 Port 0 node 0: error reading config ROM offset 0x0 Resource temporarily unavailable Port 0 node 1: error reading config ROM offset 0x0 Resource temporarily unavailable No MOTU firewire audio interfaces found |
From: Jonathan W. <jw...@ph...> - 2007-10-24 05:18:17
|
> > To that end, I have a few questions about the outcome of the motutest runs > > you did for me. > > > > 1) Did streaming stop after the modified motutest program finished? You > > can use dumpiso after motutest exits to verify this. > > I hate to say it, but I'm not sure. The output of dumpiso was not > human-readable, so I couldn't really make any sense out of it :) All I really want to know is whether there's data flowing. Just run dumpiso after motutest exits and see if there's a continuous stream of data coming out of it. If it prints its header and then stops it means there's no iso data on the bus. > > 2) Did the modified motutest program report any errors when writing to > > registers? > > It did. I sent the output from the patched motutest-20071023 run in my > last email. The errors were on writing to register 0x000b00 as before. Yes, I saw that - thanks. Curiously enough the error was not on the first write - only on the one used to turn off the streaming. This is really starting to strongly point to there being more to the control of iso streaming on this device than on the other MOTU devices. > > 3) Could you run the modified motutest again without having to first > > reset the PC or reinsert the ieee1394 kernel module? > > I was able to get it to re-run once successfully (I'm guessing, since > motutest's output is now less verbose), but subsequent runs without > unloading and reloading the ohci1394 module produced this output: > : > Enabling iso streaming... > Error doing motu write to register 0x000b00 > Started > stop > Error doing motu write to register 0x000b00 > reverb tmp # ./motutest-20071023-r1 > : > No MOTU firewire audio interfaces found > reverb tmp # ./motutest-20071023-r1 > : > No MOTU firewire audio interfaces found Hmm, ok. Did you get the runaway loop errors in the dmesg output when using the modified motutest? Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-10-24 11:40:10
|
On Wed, 24 Oct 2007, Jonathan Woithe wrote: >>> To that end, I have a few questions about the outcome of the motutest runs >>> you did for me. >>> >>> 1) Did streaming stop after the modified motutest program finished? You >>> can use dumpiso after motutest exits to verify this. >> >> I hate to say it, but I'm not sure. The output of dumpiso was not >> human-readable, so I couldn't really make any sense out of it :) > > All I really want to know is whether there's data flowing. Just run dumpiso > after motutest exits and see if there's a continuous stream of data coming > out of it. If it prints its header and then stops it means there's no iso > data on the bus. No, it stopped right after motutest exited. >> Error doing motu write to register 0x000b00 >> reverb tmp # ./motutest-20071023-r1 >> : >> No MOTU firewire audio interfaces found >> reverb tmp # ./motutest-20071023-r1 >> : >> No MOTU firewire audio interfaces found > > Hmm, ok. Did you get the runaway loop errors in the dmesg output when using > the modified motutest? No. What I got from dmesg this time around was in the snippit below. The dmesg notes stopped when motutest exited, which makes sense. ohci1394: fw-host0: isochronous cycle too long ohci1394: fw-host0: isochronous cycle too long ohci1394: fw-host0: isochronous cycle too long ohci1394: fw-host0: isochronous cycle too long ohci1394: fw-host0: isochronous cycle too long ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission printk: 3633 messages suppressed. ohci1394: fw-host0: isochronous cycle too long jms |
From: Jonathan W. <jw...@ph...> - 2007-10-24 23:39:53
|
Hi Justin > >>> 1) Did streaming stop after the modified motutest program finished? You > >>> can use dumpiso after motutest exits to verify this. > >> > >> I hate to say it, but I'm not sure. The output of dumpiso was not > >> human-readable, so I couldn't really make any sense out of it :) > > > > All I really want to know is whether there's data flowing. Just run dumpiso > > after motutest exits and see if there's a continuous stream of data coming > > out of it. If it prints its header and then stops it means there's no iso > > data on the bus. > > No, it stopped right after motutest exited. That is very strange. The logs indicated that the command to stop the streaming failed, and yet the streaming still stopped. > >> Error doing motu write to register 0x000b00 > >> reverb tmp # ./motutest-20071023-r1 > >> : > >> No MOTU firewire audio interfaces found > >> reverb tmp # ./motutest-20071023-r1 > >> : > >> No MOTU firewire audio interfaces found > > > > Hmm, ok. Did you get the runaway loop errors in the dmesg output when using > > the modified motutest? > > No. What I got from dmesg this time around was in the snippit below. The > dmesg notes stopped when motutest exited, which makes sense. > > ohci1394: fw-host0: isochronous cycle too long > ohci1394: fw-host0: isochronous cycle too long > ohci1394: fw-host0: isochronous cycle too long > ohci1394: fw-host0: isochronous cycle too long > ohci1394: fw-host0: isochronous cycle too long > ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission > printk: 3633 messages suppressed. > ohci1394: fw-host0: isochronous cycle too long There seems to be something very odd going on with the iso streaming here. The "cycle too long" messages cannot be due to anything in the motutest iso handlers because they were not active in the modified version. The "cycle too long" messages are emitted by the kernel when too much time elapses between the reception of "cycle start" packets (they essentially come from the OHCI hardware via an interrupt). If this is to be believed it would indicate that whichever node has become the IRM (Isosynchronous Resource Manager) on the firewire bus is not doing its job and is not broadcasting cycle start packets. Precisely why this would be happening is not clear to me. All the other MOTU interfaces are IRM-capable, become the IRM during bus arbitration and transmit cycle-start as required by the standard, so its hard to see why things would be any different for the 8pre. Without a sniffer it's difficult to prove that this is what is happening because the cycle-start packets are async packets. However, it would be helpful if you could fire up gscanbus, select the MOTU interface and see if "IRM-capable" is mentioned anywhere in the device's capabilities. What firewire card are you using for these tests again? I'm also at a loss to explain how the 8pre's iso output is turned off when the write to the iso control register is flagged as failing. Ok, here's another test. Take the modified motutest source and find the lines which start with motufw_reg_write(motus, 0x0b00, ... These are the writes to the streaming control register. There should be two relevant calls - one before the usleep(100000) call, and one after. Comment these two out, recompile and rerun motutest. Use dumpiso to see if any iso data is dumped while this new motutest variant is running. Regards jonathan |
From: Justin M. S. <str...@cl...> - 2007-11-03 19:36:27
|
Sorry for the extended absence - I had a recording gig come up that I had to get turned around pretty quickly. > There seems to be something very odd going on with the iso streaming here. > The "cycle too long" messages cannot be due to anything in the motutest iso > handlers because they were not active in the modified version. The "cycle > too long" messages are emitted by the kernel when too much time elapses > between the reception of "cycle start" packets (they essentially come from > the OHCI hardware via an interrupt). If this is to be believed it would > indicate that whichever node has become the IRM (Isosynchronous Resource > Manager) on the firewire bus is not doing its job and is not broadcasting > cycle start packets. Precisely why this would be happening is not clear to > me. All the other MOTU interfaces are IRM-capable, become the IRM during > bus arbitration and transmit cycle-start as required by the standard, so its > hard to see why things would be any different for the 8pre. > > Without a sniffer it's difficult to prove that this is what is happening > because the cycle-start packets are async packets. However, it would be > helpful if you could fire up gscanbus, select the MOTU interface and see if > "IRM-capable" is mentioned anywhere in the device's capabilities. gscanbus output follows. I don't see any mention of IRM anywhere. SelfID Info ----------- Physical ID: 0 Link active: Yes Gap Count: 63 PHY Speed: S400 PHY Delay: <=144ns IRM Capable: No Power Class: -1W Port 0: Connected to parent node Port 1: Not connected Init. reset: No CSR ROM Info ------------ GUID: 0x0001F2000007E919 Node Capabilities: 0x000083C0 Vendor ID: 0x000001F2 Unit Spec ID: 0x000001F2 Unit SW Version: 0x0000000F Model ID: 0x00100800 Nr. Textual Leafes: 0 Vendor: Unknown Textual Leafes: AV/C Subunits ------------- N/A > What firewire card are you using for these tests again? This is the built-in Firewire 400 port on my Dell Latitude D820 laptop. lspci doesn't have much to say about it... 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Unknown device 00f7 (rev 02) > I'm also at a loss to explain how the 8pre's iso output is turned off when > the write to the iso control register is flagged as failing. > > Ok, here's another test. Take the modified motutest source and find the > lines which start with > > motufw_reg_write(motus, 0x0b00, ... > > These are the writes to the streaming control register. There should be two > relevant calls - one before the usleep(100000) call, and one after. Comment > these two out, recompile and rerun motutest. Use dumpiso to see if any iso > data is dumped while this new motutest variant is running. Done. The dumpiso log is here: http://www.cluebyfour.org/downloads/20071103/dumpiso-20071103.log.bz2 jms |
From: Jonathan W. <jw...@ph...> - 2007-11-04 22:41:00
|
Hi Justin > Sorry for the extended absence - I had a recording gig come up that I had > to get turned around pretty quickly. :-) No problem. I get things like that from time to time too. > > Without a sniffer it's difficult to prove that this is what is happening > > because the cycle-start packets are async packets. However, it would be > > helpful if you could fire up gscanbus, select the MOTU interface and see if > > "IRM-capable" is mentioned anywhere in the device's capabilities. > > gscanbus output follows. I don't see any mention of IRM anywhere. It's there under "SelfID Info": > IRM Capable: No This is *really* interesting, because the 828/Traveler interfaces are definitely IRM capable and behave accordingly. I think I'll try to run gscanbus on my Traveler tonight and compare the results to make sure it's not gscanbus getting confused here. Could you run gscanbus again and this time report the properties associated with the firewire device in your PC? Could you also try cat /sys/bus/ieee1394/devices/fw-host0/host_id/bus_options and sent the output to me? If the 8pre is not IRM capable then some other node must take on the IRM responsibility. In this case it should be the PC interface since it's the only other thing on the bus. However, off-hand I'm not sure what the current state of the Linux kernel firewire IRM code is. All this aside, I wonder how the MOTU manages to put streaming data onto the bus without an IRM present on the bus. Maybe it just "does it anyway". > > What firewire card are you using for these tests again? > > This is the built-in Firewire 400 port on my Dell Latitude D820 laptop. > lspci doesn't have much to say about it... > > 03:01.4 FireWire (IEEE 1394): O2 Micro, Inc. Unknown device 00f7 (rev 02) Hmm, O2 Micro Inc. I don't know anything about these cards. Does anyone else have experience or anedotes about this chipset? > > I'm also at a loss to explain how the 8pre's iso output is turned off when > > the write to the iso control register is flagged as failing. > > > > Ok, here's another test. Take the modified motutest source and find the > > lines which start with > > > > motufw_reg_write(motus, 0x0b00, ... > > > > These are the writes to the streaming control register. There should be two > > relevant calls - one before the usleep(100000) call, and one after. Comment > > these two out, recompile and rerun motutest. Use dumpiso to see if any iso > > data is dumped while this new motutest variant is running. > > Done. This is most interesting - the dumpiso output you sent appears to contain data from the MOTU. This means that iso streaming of the 8pre is not controlled in the same way as for other interfaces. Furthermore I can't work out how the MOTU knows when to stop streaming. Without those two lines in the code motutest will exit without writing anything to the interface so the interface has no way of knowing that there's nothing left listening to the iso broadcasts any more. Maybe the streaming occurs whenever the device is in "interface mode". Ok, let's test this idea, could you do the following. 1) Have a newly rebooted machine ready. 2) Run dumpiso to see if there's any traffic coming from the MOTU. Stop dumpiso once this has been determined. 3) Run the modified motutest (the one without the 0x0b00 register writes). 4) Run dumpiso once motutest has exitted and see if any traffic is flowing from the MOTU now. I hope that there's no iso traffic at step 2 but there is some at step 4. This would indicate that streaming is enabled by the device going into "interface" mode. Regards jonathan |