Could you send me an example of how you recalculated the register
offset from scan-devreg to page, port and register parameters used by
firewire-phy-command from the jujuutils ? I really cannot figure out
how it is recalculated and jujuutils seem not recognize register
offset as e.g. 0xfffff0000004.
2013/8/1 Darren Anderson <darrena092@...>:
> That was a great idea, well done!
> You could use Clemens' JujuUtils https://code.google.com/p/jujuutils/
> There's a tool in that package which allows you to read and write data to
> the firewire bus. I used it a lot when I was trying to reverse engineer the
> M-Audio ProjectMix (now shelved indefinitely thanks to work... big project,
> not much free time).
> A good starting point would be to set the registers to their changed values,
> and try to stream audio.
> Even if you couldn't figure out what each register does, you could always
> just make a script that sets them before starting FFADO and Jack.
> On 1 August 2013 17:23, Tomasz T <t.tajmajer@...> wrote:
>> Dear Jonathan and Darren,
>> I wanted to use the "scan-devreg" tool to see if there are any changes
>> in the registers when I reboot the device.
>> I've changed the vendor ID to make it working. Also i've changed the
>> address range from 0x000 to 0xF00 (but apparently it ends at 0x700)
>> This is the diff that I've got:
>> $ diff fwsolo_reg_mixer_ok.dump fwsolo_reg_mixer_mute.dump
>> < 0x0200 is E49E649F
>> < 0x0204 is 000002F2
>> > 0x0200 is E0F143D7
>> > 0x0204 is 00000070
>> < 0x066c is 00000001
>> < 0x0670 is 20000013
>> < 0x0674 is 00000000
>> < 0x0678 is 00000001
>> < 0x067c is 00000000
>> < 0x0680 is 20202028
>> < 0x0684 is 00000001
>> < 0x0688 is 1000A9D8
>> < 0x068c is 00000002
>> < 0x0690 is 20202028
>> < 0x0694 is 1000BB10
>> < 0x0698 is 1000BACC
>> < 0x069c is 00000000
>> < 0x06a0 is 00000000
>> < 0x06a4 is 00002020
>> < 0x06a8 is 00000000
>> > 0x066c is 32323232
>> > 0x0670 is 32323232
>> > 0x0674 is 32323232
>> > 0x0678 is 32323232
>> > 0x067c is 32323232
>> > 0x0680 is 32323232
>> > 0x0684 is 32323232
>> > 0x0688 is 32323232
>> > 0x068c is 32323232
>> > 0x0690 is 32323232
>> > 0x0694 is 32323232
>> > 0x0698 is 32323232
>> > 0x069c is 32323232
>> > 0x06a0 is 32323232
>> > 0x06a4 is 32323232
>> > 0x06a8 is 32323232
>> < 0x06c8 is 0000000C
>> > 0x06c8 is 00000027
>> < 0x06ec is 00000000
>> < 0x06f0 is 60000013
>> > 0x06ec is 32323232
>> > 0x06f0 is 00000003
>> I've atached both dumps and the result of ffado-test discover, thought
>> it could be useful.
>> As you can see, there is a piece of memory which after reboot is
>> filled with ..323232.. and which is set with some data by the original
>> I think it will be hard to identify what are the functions of each
>> register, but if I set all of them to the values given, then in result
>> the mixer will be unmuted (at least there is a chance for that)
>> Is there a tool for setting values to the registers ?
>> 2013/7/29 Jonathan Woithe <jwoithe@...>:
>> > Hi Tomasz and Darren
>> >> 2013/7/28 Darren Anderson <darrena092@...>:
>> >> > I would imagine that the windows driver is sending some sort of
>> >> > command
>> >> > to unmute the device before streaming audio.
>> > Either that or it's more extensive than that: there could be a need to
>> > send
>> > complete routing information. Given the type of device that it is, my
>> > guess
>> > is somewhere between the two: that the outputs of the device are
>> > initially
>> > muted and some form of "volume" must be set up (rather than simply
>> > hitting
>> > an unmute switch).
>> >> > If you could download http://perisoft.net/bushound/ (the free
>> >> > version)
>> >> > and use it to log the firewire packets through a power cycle of the
>> >> > interface, then post it here, it may be of some help.
>> > Yes, this may help. However, keep in mind that the free version will
>> > only
>> > capture a relatively small number of bytes per packet (8 I think) and a
>> > limited number of packets per session from what I've been told. If a
>> > small
>> > amount of data is involved in the transfer then this might be fine.
>> > However, if large packets or a large number of packets are involved in
>> > the
>> > setup then these limits may prevent important details being displayed.
>> > On Sun, Jul 28, 2013 at 09:24:47PM +0200, Tomasz T wrote:
>> >> I've used bushound to sniff the data as you suggested.
>> >> Three logs are attached, the third should be the most useful (I wasn't
>> >> sure which phase should I record, but I assume that OUT is the most
>> >> interesting in this case).
>> > I don't know the finer details of the BeBoB protocol (which this device
>> > utilises) but I would guess that you are correct: the most interesting
>> > detail at this point is the data that is sent to the device. Looking at
>> > the
>> > data provided, the commands being sent to the interface are typically 12
>> > or
>> > 16 bytes (presumedly standard sizes for AVC commands sent to the command
>> > register at 0x0b00). Bushound is only reporting the first 8 which, from
>> > the
>> > look of things are mostly concerned with addressing and the like. I
>> > expect
>> > that most of the information related to setting up the device will be in
>> > the
>> > additional bytes which you can't see.
>> >> Do you have any specs for m-audio FW interfaces, describing how the
>> >> mixer settings are controlled, or is it all reverse engineered ?
>> > With BeBoB devices I believe there is some rudimentary device control
>> > available via AVC commands. However, as far as I know most device
>> > manufacturers implement their own mixer/routing/control methods using
>> > vendor-specific extensions. In the latter case, controlling the device
>> > almost always requires some form of protocol analysis because the
>> > manufacturers typically do not share the programming information with
>> > us.
>> > If you need to dig further, you might like to take a look at a talk I
>> > did on
>> > this subject at Linux.conf.au in 2011 - "Playing with fire: protocol
>> > analysis techniques for the Firewire bus". The video can be found at
>> > http://blip.tv/linuxconfau/playing-with-fire-protocol-analysis-techniques-for-the-firewire-bus-4711189
>> > Slides are still available from here:
>> > http://www.atrad.com.au/~jwoithe/lca2011/lca2011_firewire_analysis_talk.pdf
>> > Regards
>> > jonathan
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> FFADO-devel mailing list