[alsa-devel] DSP2000 Midi In - Not a correct fix??
I think it is time to post my investigations so far... re: Hoontech DSP2000 Midi In non-functional see : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=55 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1161 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1846 I missed a fix patch in March 07 for this as it was put on a later duplicate of the bug report I had contributed to. However I noticed JK closing -> resolved these in Jan 08, so tried the patch: http://hg.alsa-project.org/alsa-kernel/rev/319688a93b6e From my testing, it seems the only part necessary is:- - for (box = 0; box < 4; box++) { + for (box = 0; box < 1; box++) { as it is successful without the rest. However I feel this is not really a correct fix, preventing use of multiple boxes in code that originally allowed it. The code is a little strange and has taken me a while to approximately grasp. What seems to be going wrong is that when a second box is configured (ie box = 1) the function snd_ice1712_stdsp24_box_midi(...) switches the midi input off box[0]. If box[1] has ICE1712_STDSP24_BOX_MIDI1 set in it's config, then midi in and out can work on box[1] instead of box[0], but otherwise it is just stopped on box[0]. After many hours/days of tests I still can't propose a definite way to fix this function to provide correct configuration to all 4 allowed boxes, as I really don't understand why the code does all the gpio writes that it does. Unfortunately I do not have any circuit information either. In some way it seems to be latching some of the configuration data, but not all. Clemens, can you remember anything about this change: http://hg.alsa-project.org/alsa-kernel/rev/a42043505e46 -was it someone else's patch or did you work on this? I am hoping that someone can contribute enough of an idea about this to help formulate a proper fix. Unfortunately, as the bugs are closed, I can not continue the discussions there. Alan
On Tue, 29 Jan 2008, Alan Horstmann wrote:
I think it is time to post my investigations so far...
re: Hoontech DSP2000 Midi In non-functional
see : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=55 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1161 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1846
I missed a fix patch in March 07 for this as it was put on a later duplicate of the bug report I had contributed to. However I noticed JK closing -> resolved these in Jan 08, so tried the patch:
http://hg.alsa-project.org/alsa-kernel/rev/319688a93b6e
From my testing, it seems the only part necessary is:-
- for (box = 0; box < 4; box++) { + for (box = 0; box < 1; box++) {
as it is successful without the rest.
However I feel this is not really a correct fix, preventing use of multiple boxes in code that originally allowed it. The code is a little strange and
Do you have configuration with mutiple boxes? If yes, we can continue to work on a proper fix. Othewise, I would just keep a working configuration for single box only. Jaroslav ----- Jaroslav Kysela <perex@perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
On Tuesday 29 January 2008 11:09, Jaroslav Kysela wrote:
On Tue, 29 Jan 2008, Alan Horstmann wrote:
re: Hoontech DSP2000 Midi In non-functional
see : https://bugtrack.alsa-project.org/alsa-bug/view.php?id=55 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1161 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1846
From my testing, it seems the only part necessary is:-
- for (box = 0; box < 4; box++) { + for (box = 0; box < 1; box++) {
as it is successful without the rest.
However I feel this is not really a correct fix, preventing use of multiple boxes in code that originally allowed it.
Do you have configuration with mutiple boxes? If yes, we can continue to work on a proper fix. Othewise, I would just keep a working configuration for single box only.
I can understand your sentiment and it is true I have only a single box (which can be set to any of box[0] to [3]), but it seems a regression to prevent correct configuring of audio on multiple boxes (which has worked fine in the past) just because of a problem in the Midi part. The next better step than the patch on 1.0.16rc1 is to only allow midi config on box[0] with if (box == 0) in front of snd_ice1712_stdsp24_box_midi(..) However, things have moved on here, in that I do now have a proposed alternative. One step on from the above approach is to call this function only if ICE1712_STDSP24_BOX_MIDI1 is set for that particular box, rather than setting the parameter 'activate'. This approach does create a complete and effective solution, which I have tested here, being able (using the boxconfigs) to set channels and Midi In on any box designated 0-3, and Midi out 1 & 2 are active for all boxes once set on any. Soon I will put this together into a patch for review, so that there is at least something definite to discuss. And On Tuesday 29 January 2008 11:25, Clemens Ladisch wrote:
Alan Horstmann wrote:
Clemens, can you remember anything about this change:
http://hg.alsa-project.org/alsa-kernel/rev/a42043505e46
-was it someone else's patch or did you work on this?
That change is based on the Windows driver source code (which I no longer have) and some guesswork; I never had the hardware.
Thanks Clemens, that is useful to know. Alan
On Tuesday 29 January 2008 23:22, Alan Horstmann wrote:
However, things have moved on here, in that I do now have a proposed alternative. One step on from the above approach is to call this function only if ICE1712_STDSP24_BOX_MIDI1 is set for that particular box, rather than setting the parameter 'activate'. This approach does create a complete and effective solution, which I have tested here, being able (using the boxconfigs) to set channels and Midi In on any box designated 0-3, and Midi out 1 & 2 are active for all boxes once set on any.
Soon I will put this together into a patch for review, so that there is at least something definite to discuss.
I have now generated this patch, together with a fair amount of testing various configurations, and it is attached. The original MIDI-IN non-functioning is caused because when snd_ice1712_stdsp24_box_midi(..) is called with the 3rd parameter 'activate' set to 0, it messes up any previously midi-configured boxes. Thus the zero configs of [1],[2],[3] in the standard code un-set the active midi config of [0] since they happen afterwards. This patch ensures the function is only called to activate a config and not to set it off. As a result configs can be set for any of [0] to [3] successfully. The various bits are clearly not operating as would be expected. If _MIDI2 is not set, midi out2 still functions, but midi in1 (on first 401 uart) does not. However, no other box can use this , as only one can be the midi source. And, _MIDI1 actually enables input on the second 401 uart. Therfore there really is no value in the separate _MIDI2 config and function. It would be more logical to combine in a single midi config function (it was like this in Alsa 1.0.1, but changed sometime later). I have included some explanitary text in the code patch which attempts to give some idea of the config issues. However, without extensive re-working (which it seems no-one has an appetite for), this patch fixes the problem without reducing functionality in the way that January's applied patch does. The box can be set-up as any of [0] to [3]. It might be worth re-opening the 3 related bugs and seeing if the others involved can confirm this patch, as I cannot now add it to them as an alternative. In addition, name strings are included for the mpu_401 devices so they have unique names. Regards Alan AHhoontech.c-midiIn-boxes.diff Fixes the problems with Midi In on Hoontech/STA dsp24 cards, for example with DSP2000 box, without restricting the box configurations available. Also adds mpu_401 name strings. Signed-off-by: Alan Horstmann <gineera@aspect135.co.uk>
At Tue, 5 Feb 2008 14:47:30 +0000, Alan Horstmann wrote:
On Tuesday 29 January 2008 23:22, Alan Horstmann wrote:
However, things have moved on here, in that I do now have a proposed alternative. One step on from the above approach is to call this function only if ICE1712_STDSP24_BOX_MIDI1 is set for that particular box, rather than setting the parameter 'activate'. This approach does create a complete and effective solution, which I have tested here, being able (using the boxconfigs) to set channels and Midi In on any box designated 0-3, and Midi out 1 & 2 are active for all boxes once set on any.
Soon I will put this together into a patch for review, so that there is at least something definite to discuss.
I have now generated this patch, together with a fair amount of testing various configurations, and it is attached.
The original MIDI-IN non-functioning is caused because when snd_ice1712_stdsp24_box_midi(..) is called with the 3rd parameter 'activate' set to 0, it messes up any previously midi-configured boxes. Thus the zero configs of [1],[2],[3] in the standard code un-set the active midi config of [0] since they happen afterwards. This patch ensures the function is only called to activate a config and not to set it off. As a result configs can be set for any of [0] to [3] successfully.
The various bits are clearly not operating as would be expected. If _MIDI2 is not set, midi out2 still functions, but midi in1 (on first 401 uart) does not. However, no other box can use this , as only one can be the midi source. And, _MIDI1 actually enables input on the second 401 uart. Therfore there really is no value in the separate _MIDI2 config and function. It would be more logical to combine in a single midi config function (it was like this in Alsa 1.0.1, but changed sometime later).
I have included some explanitary text in the code patch which attempts to give some idea of the config issues.
However, without extensive re-working (which it seems no-one has an appetite for), this patch fixes the problem without reducing functionality in the way that January's applied patch does. The box can be set-up as any of [0] to [3]. It might be worth re-opening the 3 related bugs and seeing if the others involved can confirm this patch, as I cannot now add it to them as an alternative.
In addition, name strings are included for the mpu_401 devices so they have unique names.
Regards Alan
AHhoontech.c-midiIn-boxes.diff
Fixes the problems with Midi In on Hoontech/STA dsp24 cards, for example with DSP2000 box, without restricting the box configurations available. Also adds mpu_401 name strings.
Signed-off-by: Alan Horstmann <gineera@aspect135.co.uk>
Applied to HG tree now. Thanks. Takashi
Alan Horstmann wrote:
Clemens, can you remember anything about this change:
http://hg.alsa-project.org/alsa-kernel/rev/a42043505e46
-was it someone else's patch or did you work on this?
That change is based on the Windows driver source code (which I no longer have) and some guesswork; I never had the hardware. Regards, Clemens
participants (4)
-
Alan Horstmann -
Clemens Ladisch -
Jaroslav Kysela -
Takashi Iwai