Menu
▾
▴
Re: [FFADO-devel] Call for testing: ALSA driver for Fireworks/BeBoB based devices
|
From: Michael M. <mih...@ya...> - 2014-01-07 12:14:21
|
Hi Takashi,
> It seams to me FW1814 has strict timing diagram.
> I'll check with bus analyser one more time how long delays
> in Windows driver for FCP transactions.
>That's nice.
I have checked timing digram for FW 1814
1. Driver polls for meter data every 100 ms
2. Any FCP transaction (except 'lock pll' and 'set sampling rate')
happens in less then 100 ms
3. Any regular read/write happens at any time (e.g. mixer controls)
4. The most interesting part: set sampling rate. Here is the part of the
log with timings
46 ffc1 ffff f000 0b00 8 OUT 00 ff 18 00 90 03 ff
ff ........ 2.8ms 80.1.0
15:06:58.773 mafw
46 0000 ffff f000 0d00 8 IN 0f ff 18 00 90 03 ff
ff ........ 106ms 81.1.0
15:06:58.883 mafw
46 0000 ffff f000 0d00 8 IN 09 ff 18 00 90 03 ff
ff ........ 132ms 82.1.0
15:06:59.013 mafw
this reply usualy arrives after about 150 ms
46 ffc1 ffff f000 0b00 8 OUT 00 ff 19 00 90 03 ff
ff ........ 1.4ms 83.1.0
15:06:59.013 mafw
46 0000 ffff f000 0d00 8 IN 0f ff 19 00 90 03 ff
ff ........ 91ms 84.1.0
15:06:59.103 mafw
46 0000 ffff f000 0d00 8 IN 09 ff 19 00 90 03 ff
ff ........ 332ms 85.1.0
15:06:59.443 mafw
as you can see reply to FCP request arrived in 332 ms. and the next
access to the device happens only aftet 1 sec!!!
46 ffc1 ffc7 0060 0000 84 IN 00 00 00 00 00 05 00 01
00 1a 00 1b 00 1a 00 1a ................ 1.0sc 86.1.0
15:07:00.493 mafw
00 18 00 18 00 00 00 00
00 00 00 00 00 00 00 00 ................ 86.1.16
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ................ 86.1.32
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ................ 86.1.48
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 ................ 86.1.64
00 00 03 01
.... 86.1.80
So I guess we need a special function for FW 1814 to deal with these 2
FCP transactions. I would actually implement the whole driver as event
driven state machine.
In the loop check the queue of requests and if there is no any then poll
meter. And delay any pending request for 1 sec after changing sampling rate.
>I have a reason not to do it.
>I design snd-bebob not to interrupt FFADO streaming function as much
as possible. If snd-bebob keep plugs open, FFADO always failed to start
streaming after the user uses ALSA application.
But why would I need FFADO installed if my audio card is supported by
your driver? The reason may be that FFADO already has mixer implemented
and probably more stable now, but how about future?
> And I design snd-bebob to handle all devices based on DMxxxx/BeBoB. If
> we want to implement something special for FW1814 and ProjectMix I/O,
> I think it good to develop two driver modules, like snd-bebob and
> snd-maudio (or something).
>
> But currently I avoid the cost to maintain these two drivers.
yes, the separate module may be better. Unfortunately I'll be travelling
to customer's site for next 4 months so will not be able to help in
development :(
>
> > Another observation is access to meter data. Currently FW
> transaction is issues
> > for every access to #meter file.
> > Should this data be cached? Windows driver polls for data every 100 ms
> > in separate thread (synchronized with streaming?).
>
> My intent to implement #meter node is for debugging purpose.
> So currently I have no idea to use it for application in user-land.
>
> If you need the information, it's better to implement it in user-land
> application.
I guess #meter node will be very helpful for the one who will implement
mixer GUI for particular card(s). I'm not going to change my FW 1814 to
anything else sine it is good enough for my needs and I'd love to
implement mixer GUI which will work in conjunction with ALSA driver.
Regards,
Michael
|