From: Takashi S. <o-t...@sa...> - 2013-10-22 11:35:45
Attachments:
0013-obsolete_maudio_build_option.patch
|
Hi all, I'm sorry but this patch should be applied after appling my previous series of patch. FFADO has ENABLE_MAUDIO build option but this option is needless because of two points: 1. As long as FFADO developer confirmed, there is no devices for which M-Audio developed its own chipset. BeBoB or Dice chipset are used for all of M-Audio's models. 2. maudio_avdevice class has no functionality. I confirm that scons build is success and debian package can be generated successfully after applying this patch (here I should 'these' instread of 'this'). ----- 0013-obsolete_maudio_build_option.patch [FFADO/MAudio] obsolete ENABLE_MAUDIO build option and remove related files As long as FFADO developers confirmed, MAudio devices use BeBoB chipset or Dice chipset. This commit obsolete ENABLE_MAUDIO build option and maudio_avdevice class because it's no meaning. The resources related to Firewire 410 and Firewire Audiophile are going to be moved to under /src/bebob/maudio/. Regards Takashi Sakamoto |
From: Takashi S. <o-t...@sa...> - 2013-10-25 12:28:04
|
Hi all, For these 13 patches, I want to merge this weekend. So please inform your critisism to me till tomorrow if you have. Thanks Takashi Sakamoto (Oct 22 2013 20:35), Takashi Sakamoto wrote: > Hi all, > > I'm sorry but this patch should be applied after appling my previous > series of patch. > > FFADO has ENABLE_MAUDIO build option but this option is needless because > of two points: > 1. As long as FFADO developer confirmed, there is no devices for which > M-Audio developed its own chipset. BeBoB or Dice chipset are used for > all of M-Audio's models. > 2. maudio_avdevice class has no functionality. > > I confirm that scons build is success and debian package can be > generated successfully after applying this patch (here I should 'these' > instread of 'this'). > > ----- > 0013-obsolete_maudio_build_option.patch > [FFADO/MAudio] obsolete ENABLE_MAUDIO build option and remove related files > As long as FFADO developers confirmed, MAudio devices use BeBoB chipset > or Dice > chipset. This commit obsolete ENABLE_MAUDIO build option and maudio_avdevice > class because it's no meaning. > > The resources related to Firewire 410 and Firewire Audiophile are going > to be > moved to under /src/bebob/maudio/. > > > Regards > > Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-26 01:43:17
|
Hi Takashi On Fri, Oct 25, 2013 at 09:27:52PM +0900, Takashi Sakamoto wrote: > For these 13 patches, I want to merge this weekend. So please inform > your critisism to me till tomorrow if you have. I don't have any M-Audio devices so I can't test these. At first glance the approach appears to be fine so I don't have any objection to their merge at this point. Even if there are bugs, the functionality provided by these far exceeds what we have at present so I think pursuing them in trunk is the best way forward. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-28 04:17:25
|
Hi Jonathan, > I don't have any M-Audio devices so I can't test these. At first > glance the approach appears to be fine so I don't have any objection > to their merge at this point. Even if there are bugs, the > functionality provided by these far exceeds what we have at present > so I think pursuing them in trunk is the best way forward. Thanks. I've committed them. Takashi Sakamoto |
From: Takashi S. <o-t...@sa...> - 2013-10-28 04:42:58
|
Hi Jonathan, I also have a need to add some comments to device database related to M-Audio/BeBoB devices. - change the status for 'Firewire Solo' as 'community support' and add comment 'firmware version 5058 is preferable' - change the status for 'Firewire Ozonic' as 'community support' and add comment 'firmware version 5058 is preferable' For 'Firewire Audiophile' and 'Firewire 410', we will be able to change its status as 'community support' when implementing the way to load its firmware... Thanks Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-29 11:02:52
|
Hi Takashi > I also have a need to add some comments to device database related > to M-Audio/BeBoB devices. > - change the status for 'Firewire Solo' as 'community support' and > add comment 'firmware version 5058 is preferable' > - change the status for 'Firewire Ozonic' as 'community support' and > add comment 'firmware version 5058 is preferable' These are done. I assume that you have both of these devices? It would be good to set you as the developer associated with these devices. It's easiest if you create a user for yourself on the ffado.org website. I can then add you to the list of possible support contacts. I'll just need to know your user name; I expect it'll be "mocchi" as per svn. > For 'Firewire Audiophile' and 'Firewire 410', we will be able to > change its status as 'community support' when implementing the way > to load its firmware... Sounds fair. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-29 15:11:31
|
Hi Jonathan, > These are done. I assume that you have both of these devices? Yes, I have. > It would be good to set you as the developer associated with these > devices. It's easiest if you create a user for yourself on the > ffado.org website. I can then add you to the list of possible > support contacts. I'll just need to know your user name; I expect > it'll be "mocchi" as per svn. Yes. 'Mocchi' is my account name on http://ffado.org. > Sounds fair. |
From: Jonathan W. <jw...@ju...> - 2013-10-29 23:10:10
|
Hi Takahsi > > These are done. I assume that you have both of these devices? > Yes, I have. Thanks for confirming this. > > It would be good to set you as the developer associated with these > > devices. It's easiest if you create a user for yourself on the > > ffado.org website. I can then add you to the list of possible > > support contacts. I'll just need to know your user name; I expect > > it'll be "mocchi" as per svn. > > Yes. 'Mocchi' is my account name on http://ffado.org. Ah, a capital "M". That's why I couldn't track it down last night. Thanks for this - that's all done now. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-29 15:27:05
|
Oops, I pushed the button before finishing... > Sounds fair. I've already implemented in my snd-bebob to send cues for loading firmware. For FFADO, there are one issues which I cannot resolve. When the device receive the cues, it loads firmware from ROM and generate bus reset. Then the device is detected as a new device. I think ffado-dbus-server is the best to send cues. But as long as my understanding, ffado-dbus-server doesn't re-discovery for these devices if the server already running. Thanks Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-29 22:45:11
|
Hi Takashi On Wed, Oct 30, 2013 at 12:26:58AM +0900, Takashi Sakamoto wrote: > I've already implemented in my snd-bebob to send cues for loading > firmware. For FFADO, there are one issues which I cannot resolve. > > When the device receive the cues, it loads firmware from ROM and > generate bus reset. Then the device is detected as a new device. Ok, I guess that's not all that unexpected. > I think ffado-dbus-server is the best to send cues. But as long as > my understanding, ffado-dbus-server doesn't re-discovery for these > devices if the server already running. I assume the firmware cues only need to be sent once per device power cycle. That is, once they've been sent they are not needed until the device is turned off. Is there a way to query the device to find out whether the cues are needed. ffado-dbus-server may not be the best place for the cues because there's no guarantee that a user will have this running before attempting to start jackd/ffado. Essentially the cues need to be sent by the first ffado component that runs after the device has been turned on. Looking at the ffado-dbus-server code it does not appear to include a bus reset handler so you would be right I think: ffado-dbus-server won't do device rediscovery after a bus reset. Getting this to work in general would need a bit of thought because you would also have to work out how the bus reset implications could be communicated to any ffado-mixer which happened to be running at the time. As I understand it, the cues needed for these particular devices amount to a small number of async transactions. I therefore wonder whether it wouldn't be easier to implement the firmware cue functionality as a standalone utility. After identifying the necessary devices from ConfigRom and determining that a cue needs to be sent it could send the necessary cues and then exit. If no applicable devices were found (or a cue does not need to be sent) it would simply exit. This would avoid having to concern ffado-dbus-server (and all other ffado components) with bus resets in response to firmware loads. To implement the functionality some of the support libraries could be used, but it might be easier to code the necessary transactions using libraw1394 direct, or even the native juju API. The utility could conceivably be called via a udev "add" rule so users would not even need to be aware of it. Regards jonathan |