From: Takashi S. <o-t...@sa...> - 2013-10-23 10:17:54
|
Hi all, This seris of patch is a solution for #360. 'Make echo audiofire 8 and audiofire 12 work with recent firmwares' http://subversion.ffado.org/ticket/360 As long as the attached debug information, there are two issues. 1. EfcPolledValuesCmd causes assertion related to in/out channel 2. EfcGetClock command return invalid sampling rate/clock id Fortunately I borrow AudioFire12 and check them. Yes, there is still a problem. Then I modprobe my snd-fireworks, there is no problem. I test them with firmware version 5.5/5.8. The large differences between FFADO and my snd-fireworks is EFC command. In FFADO, it's based on FCP command. But in my snd-fireworks, it's not based on FCP (command to 0xecc000000000, response to 0xecc080000000). I check these two commands (EfcPolledValuesCmd/EfcGetClockCmd over FCP) with jujuutils, AudioFire12 with firmware version 5.5/5.8. Then I realized that these command is lack of confidence. Sometimes failed, sometimes return invalid data. It's a hard for me to implement EFC (not over FCP) in FFADO so this time I hope to add some workaround. # but actually there is no need to update firmware because with 5.5 or later, AudioFire12 reduce its support for sampling frequency up to 96.0kHz. ----- 0001-buffer_over_run_preventsion.patch EfcPolledValuesCmd over FCP often return invalid data. When the number of channels is invalid, assertion abort process. This patch remove this assertion and add prevention from buffer over run. If the command return invalid data, the process is not aborted and continue to work. ----- 0002-add_workaround_against_get_clock_cmd.patch EfcGetClockCmd over FCP is often failed or return invalid data. This commit add retry for doEfcOverFCP(). When the trials are completely failed, for sampling rate operation, a fallback to 'input/output plug signal format' command is executed. This command seems to be supported by all models. But the driver can't know current clock source via 'plug signal format' command. This commit add 'm_current_clock' member to keep the id. This member is updated by setClock(). When getClock() is faled even if this member is not set, fallback to internal clock. ----- 0003-hide_spdif_mode.patch AudioFire12 has no digital I/O. Regards Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-23 13:24:09
|
Hi Takashi On Wed, Oct 23, 2013 at 07:17:38PM +0900, Takashi Sakamoto wrote: > This seris of patch is a solution for #360. > > 'Make echo audiofire 8 and audiofire 12 work with recent firmwares' > http://subversion.ffado.org/ticket/360 > > As long as the attached debug information, there are two issues. > 1. EfcPolledValuesCmd causes assertion related to in/out channel > 2. EfcGetClock command return invalid sampling rate/clock id > : > It's a hard for me to implement EFC (not over FCP) in FFADO so this > time I hope to add some workaround. I take it from this that the "full" fix for the problem is to implement these two commands in FFADO using EFC rather than FCP. However, for the moment you have implemented a workaround which manages to make things work without having to code the new functionality. Is this right? > but actually there is no need to update firmware because with 5.5 > or later, AudioFire12 reduce its support for sampling frequency up > to 96.0kHz. That sounds odd - any idea why they did this? I know that FFADO limits DICE devices to 96 kHz, but that was due to us not supporting the transfer mode used by DICE when 4x modes were selected. Anyway, I take it that with this series of patches it's possible to use FFADO with AF8 and AF12 interfaces equipped with firmware greater than 4.8. This is certainly good news. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-24 10:13:44
|
Hi Jonathan, > I take it from this that the "full" fix for the problem is to > implement these two commands in FFADO using EFC rather than FCP. > However, for the moment you have implemented a workaround which > manages to make things work without having to code the new > functionality. Is this right? Right. > That sounds odd - any idea why they did this? I know that FFADO > limits DICE devices to 96 kHz, but that was due to us not supporting > the transfer mode used by DICE when 4x modes were selected. It's not due to FFADO. As a quick glance of Echo's readme for Windows drivers, it clearly describes to lose a support for 192kHz at firmware version 5.8. The firmware can return its capability as a response to a certain command. As long as I got it, 5.5 is a start to lose it (I test it with Windows 8). So I believe many users may stay on 4.8. At 4.8, EFC over AVC seems to work well. In this reason, I won't spend much time to add new functionality. Anyway we should document this somewhere, maybe this page. http://www.ffado.org/?q=node/71 Regards Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-28 23:45:39
|
Hi Takashi On Thu, Oct 24, 2013 at 07:13:30PM +0900, Takashi Sakamoto wrote: > > I take it from this that the "full" fix for the problem is to > > implement these two commands in FFADO using EFC rather than FCP. > > However, for the moment you have implemented a workaround which > > manages to make things work without having to code the new > > functionality. Is this right? > > Right. This is great news - thanks for doing this. > > That sounds odd - any idea why they did this? I know that FFADO > > limits DICE devices to 96 kHz, but that was due to us not supporting > > the transfer mode used by DICE when 4x modes were selected. > > It's not due to FFADO. > > As a quick glance of Echo's readme for Windows drivers, it clearly > describes to lose a support for 192kHz at firmware version 5.8. That's really quite odd. I wonder why they (Echo) did that. At least we know for sure that it's not something we did. :-) > So I believe many users may stay on 4.8. At 4.8, EFC over AVC seems > to work well. Yes - firmware 4.8 is the last firmware known to work with FFADO prior to your patch. > In this reason, I won't spend much time to add new functionality. > Anyway we should document this somewhere, maybe this page. > http://www.ffado.org/?q=node/71 I agree - some updates are required as per your later emails. I will get to those messages soon. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-25 12:29:11
|
Hi all, For these 3 patches, I want to merge this weekend. So please inform your critisism to me till tomorrow if you have. Thanks Takashi Sakamoto (Oct 23 2013 19:17), Takashi Sakamoto wrote: > Hi all, > > This seris of patch is a solution for #360. > > 'Make echo audiofire 8 and audiofire 12 work with recent firmwares' > http://subversion.ffado.org/ticket/360 > > As long as the attached debug information, there are two issues. > 1. EfcPolledValuesCmd causes assertion related to in/out channel > 2. EfcGetClock command return invalid sampling rate/clock id > > Fortunately I borrow AudioFire12 and check them. Yes, there is still a > problem. Then I modprobe my snd-fireworks, there is no problem. I test > them with firmware version 5.5/5.8. > > The large differences between FFADO and my snd-fireworks is EFC command. > In FFADO, it's based on FCP command. But in my snd-fireworks, it's not > based on FCP (command to 0xecc000000000, response to 0xecc080000000). > > I check these two commands (EfcPolledValuesCmd/EfcGetClockCmd over FCP) > with jujuutils, AudioFire12 with firmware version 5.5/5.8. Then I > realized that these command is lack of confidence. Sometimes failed, > sometimes return invalid data. > > It's a hard for me to implement EFC (not over FCP) in FFADO so this time > I hope to add some workaround. > > # but actually there is no need to update firmware because with 5.5 or > later, AudioFire12 reduce its support for sampling frequency up to 96.0kHz. > > ----- > 0001-buffer_over_run_preventsion.patch > EfcPolledValuesCmd over FCP often return invalid data. When the number > of channels is invalid, assertion abort process. This patch remove this > assertion and add prevention from buffer over run. > If the command return invalid data, the process is not aborted and > continue to work. > > ----- > 0002-add_workaround_against_get_clock_cmd.patch > EfcGetClockCmd over FCP is often failed or return invalid data. This > commit add retry for doEfcOverFCP(). > > When the trials are completely failed, for sampling rate operation, a > fallback to 'input/output plug signal format' command is executed. This > command seems to be supported by all models. > > But the driver can't know current clock source via 'plug signal format' > command. This commit add 'm_current_clock' member to keep the id. This > member is updated by setClock(). When getClock() is faled even if this > member is not set, fallback to internal clock. > > ----- > 0003-hide_spdif_mode.patch > AudioFire12 has no digital I/O. > > > Regards > Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-26 01:45:22
|
Hi Takashi On Fri, Oct 25, 2013 at 09:29:03PM +0900, Takashi Sakamoto wrote: > Hi all, > > For these 3 patches, I want to merge this weekend. So please inform your > critisism to me till tomorrow if you have. Again, I don't see any immediate problem with these. If they provide a workaround for ticket #360 then I think they can only be a good thing. Like the M-Audio patches I can't personally test these since I don't have a suitable device. However, you obviously have tested them and if they work I see no reason not to merge. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-28 04:20:54
|
(Oct 26 2013 10:45), Jonathan Woithe wrote: > Again, I don't see any immediate problem with these. If they provide > a workaround for ticket #360 then I think they can only be a good > thing. Like the M-Audio patches I can't personally test these since > I don't have a suitable device. However, you obviously have tested >them and if they work I see no reason not to merge. Thanks. I've committed them. For users, please inform me if there are any regression. Takashi Sakamoto |
From: Takashi S. <o-t...@sa...> - 2013-10-28 04:35:14
|
Jonathan, Related to these patches, I have a need to add some comments to a device support database in ffado.org. - Add a entry for Echo AudioFirePre8 is full support (maybe full, actually community support) - in a page for AudioFire12, - Add a comment 'firmware version 5.5 or later losts 192.0kHz support' - Add a comment 'With firmware version 5.5 or later, FFADO may also work by r2451/2452' Can I request them to you? Thanks Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-29 10:44:29
|
Hi Takashi On Mon, Oct 28, 2013 at 01:35:05PM +0900, Takashi Sakamoto wrote: > - Add a entry for Echo AudioFirePre8 is full support (maybe full, > actually community support) The support level depends on what the current situation is with this device. Do you have a Pre8 interface? Even if you do I expect that this was not provided by Focusrite and if so "community support" would be the most appropriate. I'll set it to this for now; it can always be changed if the situation is not as I understand it to be. Note that if you do not personally have a Pre8 then the support level should probably be "Reported to work". Both "Full" and "Community" support levels require that a FFADO developer has direct access to the device. > - in a page for AudioFire12, > - Add a comment 'firmware version 5.5 or later losts 192.0kHz support' > - Add a comment 'With firmware version 5.5 or later, FFADO may also > work by r2451/2452' This is done for both the AF12 and AF8. Please feel free to suggest adjustments if I haven't quite got the details correct. Regards jonathan |
From: Takashi S. <o-t...@sa...> - 2013-10-29 15:17:11
|
Hi Jonathan, > Do you have a Pre8 interface? Yes, I have. > Even if you do I expect that this was not provided by Focusrite and > if so "community support" would be the most appropriate. I'll set it > to this for now; it can always be changed if the situation is not as > I understand it to be. Echo Audio sale them, not Focusrite. I think Peter Palmer owns some resources which Echo Audio gave. But I don't have. My development is heavily based on reverse-engineering, mainly by much packet dumps. It's OK that the status of AudioFirePre8 is 'community support'. > This is done for both the AF12 and AF8. Please feel free to suggest > adjustments if I haven't quite got the details correct. Thanks a lot. Takashi Sakamoto |
From: Jonathan W. <jw...@ju...> - 2013-10-29 22:48:28
|
Hi Takashi > > Do you have a Pre8 interface? > Yes, I have. Great - thanks for confirming. > > > Even if you do I expect that this was not provided by Focusrite and > > if so "community support" would be the most appropriate. I'll set it > > to this for now; it can always be changed if the situation is not as > > I understand it to be. > > Echo Audio sale them, not Focusrite. Yes, sorry, that was my slip. I was dealing with a number of different things last night when I wrote this and "Focusrite" got written instead of "Echo". > My development is heavily based on reverse-engineering, mainly by much > packet dumps. Sometimes it's the only way. Pieter did sent me the name of a contact at Echo a little while ago. I'll dig it out and send it to you. > It's OK that the status of AudioFirePre8 is 'community support'. I think given the circumstances that is probably the best option at present. Regards jonathan |